Bump. I'd like to get some kind of response to this. And I suppose
Bram over there on the linphone-users ML also is waiting for one still.
On 29/10/15 12:42, Henrik Pauli wrote:
There was an email to Linphone-users a few weeks ago,
https://lists.nongnu.org/archive/html/linphone-users/2015-10/msg00012.html
and we've run into the same issue. A belle-sip Linphone will refuse
OK responses for REGISTER requests (but, by the way, gladly accept
Unauthorized responses) from hosts that differ from the channel we
expect, while this was not the case with eXosip Linphone.
The issue is peculiar. On one hand, I guess it would be nice if the
server played nice (in our case a fairly old Asterisk, not sure if a
newer one is any better), and if it knows of the IP address and port
combo in the request, it would use it rather than some other default
address & port that's valid for the same interface. On the other
hand, Linphone is doing something terribly wrong here and I can't
quite put my finger on it.
For one, the already mentioned bit about Unauthorized being accepted
(regardless of the bad IP/port combo) and belle-sip just moves on
with the registration by using password.
– Either it should be consistent and refuse in this case as well,
– Or it should accept and remember that responses come from that
IP/port combo and then continue to accept that later in the SIP
conversation.
Instead it just ignores this change until after the passworded
register message, and then it gets surprised about an unknown inbound
message, creates a new channel for it, and then...
The most useless thing happens, it seems:
It tries to compare the channels nonexistent address to our public
address. I think it could bail out way earlier on knowing that it's
a new channel.
Apparently the SIP RFC also doesn't mandate that responses come from
the same address as where the request was sent to.
_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers