Re: [Linphone-developers] bug in belle-sip 1.6.3 or linphone 3.12 [not 3.13 like I wrote in error ]

[John Hughes]

On 20/03/2020 12:19, John Hughes wrote:

>       
>       What is happening is that linphone send a SIP REGISTER but when it
>       gets back a SIP OK it refuses to believe that it matches so it
>       resends the SIP REGISTER, rinse and repeat.
>       
>       
>       The problem is that nobody seems to be setting the public_ip
>       field.

Well, no, in fact if I look at a non-truncated log (the previous one had some info lost because it was too big) I can actually see:

message: 2020-03-21 11:56:16:603 channel [0x55eb1f20aef0]: received [524] new bytes from [UDP://::ffff:10.27.128.1:5060]:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.27.128.3:5060;branch=z9hG4bK.5CXyPw09x;received=10.27.128.3;rport=5060
From: <sip:address@hidden>;tag=rhX~XRNPd
To: sip:address@hidden;tag=as01c9e167
Call-ID: YIML2E5zFn
CSeq: 20 REGISTER
Server: Asterisk PBX 13.14.1~dfsg-2+deb9u4
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="49233a97"
Content-Length: 0


message: 2020-03-21 11:56:16:604 channel [0x55eb1f20aef0] [524] bytes parsed
message: 2020-03-21 11:56:16:604 channel [0x55eb1f20aef0]: discovered public ip and port are [10.27.128.3:5060]

So the belle-sip code *has* found the public IP in channel.c

But, later on, when refresher.c gets into the act we have:

message: 2020-03-21 11:56:16:633 channel [0x55eb1f20aef0]: received [550] new bytes from [UDP://::ffff:10.27.128.1:5060]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.27.128.3:5060;branch=z9hG4bK.T7nF3UuPq;received=10.27.128.3;rport=5060
From: <sip:address@hidden>;tag=rhX~XRNPd
To: sip:address@hidden;tag=as01c9e167
Call-ID: YIML2E5zFn
CSeq: 21 REGISTER
Server: Asterisk PBX 13.14.1~dfsg-2+deb9u4
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:john@10.27.128.3;transport=udp>;expires=3600
Date: Sat, 21 Mar 2020 10:56:16 GMT
Content-Length: 0


message: 2020-03-21 11:56:16:634 channel [0x55eb1f20aef0] [550] bytes parsed
message: 2020-03-21 11:56:16:635 Found transaction matching response.
message: 2020-03-21 11:56:16:635 Changing [client] [REGISTER] transaction [0x55eb1f122f40], from state [TRYING] to [COMPLETED]
message: 2020-03-21 11:56:16:635 Refresher [0x55eb1f02f800]: contact address [10.27.128.3:5060] does not match channel address[(null):0] on channel [0x55eb1f1af3e0]

So refresher. doesn't see the correct public_ip value.

Looking at the two messages:

channel.c:

message: 2020-03-21 11:56:16:604 channel [0x55eb1f20aef0]: discovered public ip and port are [10.27.128.3:5060]

refresher.c:

message: 2020-03-21 11:56:16:635 Refresher [0x55eb1f02f800]: contact address [10.27.128.3:5060] does not match channel address[(null):0] on channel [0x55eb1f1af3e0]

We notice that they're not talking about the same channel.  channel.c has set the public_ip on the channel 0x55eb1f20aef0 but refresher.c is checking the channel 0x55eb1f1af3e0.

...f3e0 is the output channel, refresher.c checks that received messages match the public_ip on the output channel.

...aef0 is the input channel, channel.c sets the public_ip on the input channel based on the return from the SIP proxy.

There appears to be nowhere in the code where the public_ip is set on the output channel.  How could we do that anyway?

What is the point of the check in refresher.c?  What can it validate the public ip against?  The only way we can know what the public ip is is from the values received from the remove SIP proxy, and what is the point of checking the value received from the remote sip proxy against itself!