[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] Linphone keeps sending register messages
From: |
jehan monnier |
Subject: |
Re: [Linphone-developers] Linphone keeps sending register messages |
Date: |
Thu, 14 Apr 2016 18:18:09 +0200 |
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