[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dave Osbourne
Subject: Re: [Linphone-developers] Linphone keeps sending register messages
Date: Fri, 11 Dec 2015 08:20:26 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

So glad someone's bumped this - I'm hoping to try to look at the the code over the holiday period, I have a very reproducable situation for my issue.

I think mine might be a little different though as I see 4 of 5 identities register and then Linphone (re-)sends for the 5th, but this is dropped by an ALG (I think) - or badly rewritten until enough time passes.

Does anyone else seeing this know if the behavious differs with the use of an ALG in the NATgw? (all my experiences are private IP Linphone, public IP asterisk)


On 2015-12-10 14: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, 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]