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

[Amit Bagga]

Register multiple auth info with the proxy. 

I hope this helps if the relam is changing from the server side.

One with server ip and the other with server ip and port.

Thank you,
AB

Sent from my iPhone

> On 10-Dec-2015, at 7:40 PM, Henrik Pauli <address@hidden> 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