|
From: | Peio Rigaux |
Subject: | Re: [Linphone-developers] bug in belle-sip 1.6.3 or linphone 3.12 [not 3.13 like I wrote in error ] |
Date: | Mon, 23 Mar 2020 12:32:18 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
Hello John.
Just a quick response for you.
The last version of Linphone-desktop is quite old (more than 2 years old) and we are now working on a new release. A lot of bugs have been fixed since then.
Could you please test with our last development packages (https://linphone.org/snapshots/macosx/app/) to see if the behaviour is still the same?
Regards,
Peio Rigaux
Junior Software Engineer
Belledonne Communications, the company behind Linphone
Linphone.org
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!
_______________________________________________ Linphone-developers mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/linphone-developers
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |