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

[John Hughes]

This bug is also present in the MacOS version of linphone:

Desktop 4.1.1 Qt5 9.0
Core 3.12.0

downloaded from https://www.linphone.org/technical-corner/linphone?qt-technical_corner=2#qt-technical_corner

Here's an example of a trace showing the bug taken from a Mac:

2020-03-23 11:21:32:914 MESSAGE channel [0x116504000]: message sent to [UDP://masked.masked.com:5060], size: [739] bytes
REGISTER sip:masked.masked.com SIP/2.0
Via: SIP/2.0/UDP 10.27.128.8:5060;branch=z9hG4bK.8NXuheXAi;rport
From: <sip:address@hidden>;tag=hJdbb~3-~
To: sip:address@hidden
CSeq: 267043 REGISTER
Call-ID: 1ZP64IXPKW
Max-Forwards: 70
Supported: replaces, outbound
Accept: application/sdp
Accept: text/plain
Accept: application/vnd.gsma.rcs-ft-http+xml
Contact: <sip:willy@10.27.128.8;transport=udp>;+sip.instance="<urn:uuid:71ab45ef-2815-4c0a-89c1-0b83ce2d1146>"
Expires: 600
User-Agent: Linphone Desktop/4.1.1 (belle-sip/1.6.3)
Authorization:  Digest realm="asterisk", nonce="5e4c4b8b", algorithm=MD5, username="willy",  uri="sip:masked.masked.com", response="d57bd5d0b87ed116b063ddb073eaf88a"


2020-03-23 11:21:32:914 MESSAGE channel [0x11b029000]: ending recv background task with id=[c39c0].
2020-03-23 11:21:32:932 MESSAGE channel [0x11b029000]: starting recv background task with id=[c39c2].
2020-03-23 11:21:32:932 MESSAGE channel [0x11b029000]: received [555] new bytes from [UDP://::ffff:10.27.128.1:5060]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.27.128.8:5060;branch=z9hG4bK.8NXuheXAi;received=10.27.128.8;rport=5060
From: <sip:address@hidden>;tag=hJdbb~3-~
To: sip:address@hidden;tag=as45f2b2c6
Call-ID: 1ZP64IXPKW
CSeq: 267043 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: 600
Contact: <sip:willy@10.27.128.8;transport=udp>;expires=600
Date: Mon, 23 Mar 2020 10:21:32 GMT
Content-Length: 0


2020-03-23 11:21:32:936 MESSAGE channel [0x11b029000] [555] bytes parsed
2020-03-23 11:21:32:936 MESSAGE Found transaction matching response.
2020-03-23 11:21:32:936 MESSAGE Changing [client] [REGISTER] transaction [0x600002ae0a80], from state [TRYING] to [COMPLETED]
2020-03-23 11:21:32:936 MESSAGE Refresher [0x6000027c2470]: contact address [10.27.128.8:5060] does not match channel address[(null):0] on channel [0x116504000]
2020-03-23 11:21:32:936 MESSAGE belle_sip_refresher_start(): refresher [0x6000027c2470] is resubmitting request because contact sent was not correct in original request.

On 21/03/2020 12:16, John Hughes wrote:

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!