Re: [Linphone-developers] Linphone keeps sending register messages

[jehan monnier]

Hi Henrik,

It seems that on some circonstances, we have an issue with direct connection to 
SIP servers (I.e without NAT).
This is on my todo list.

Best regards


> Le 14 avr. 2016 à 14:22, Henrik Pauli <address@hidden> a écrit :
> 
> Bumping again, because it would be nice to get some reaction for this...
> 
> On 10/12/15 15:10, Henrik Pauli wrote:
>> 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