[Bug]: On Linux incoming calls are answered by wrong identity

[EnercoopJNE]

Context

We use Linphone desktop on Linux with our own SIP server. Since the update to vers. 5.2.0 the incoming calls are answered via the account identity there is by default when opening the app for the first time, even though the right account is selected. When picking up we don't hear anything, and the person calling still hears ringing. Outgoing calls are OK.

General information

• Device: Laptop
• OS: Debian 12 Bookworm
• Version of the App: 5.2.0
• Version of the SDK: Core 5.3.1

Expected behaviour

The call should be answered by the selected SIP account.

To Reproduce

1. Connect to a SIP account on Linphone desktop 5.2.0 on Linux
2. Call the related number from anywhere
3. Pick up the call in Linphone

Additional context

• Same issue with a fresh install
• No problem on Windows

SDK logs URL

https://clood.enercoop.org/index.php/s/TCRPRY2pJESEwZs

[smorlat]

Hi,

Thanks for your report. I wonder what makes you think that it relates to the picking of a SIP identity among the available accounts. Please elaborate.

What I understand from the logs is that the Asterisk server probably never receives the 200Ok from the Linphone client, and finally cancels the call:

2024-01-08 15:52:34:071 [AppRun.wrapped/belle-sip] MESSAGE channel [0x55a22e859d60]: message sent to [UDP://sip.enercoop.org:5060], size: [931] bytes SIP/2.0 200 Ok Via: SIP/2.0/UDP xxxxxxxx:5060;branch=z9hG4bK48bde437;rport From: "Julien Negros" sip:+3363xxxxx@xxxxxxxx;tag=as1d27b9c9 To: sip:julien.negros@81.249.148.98;transport=udp;tag=gpx9Eih Call-ID: 0fae172a061b5c1457cee636675a30cd@xxxxxxxx:5060 CSeq: 102 INVITE User-Agent: Linphone-Desktop/5.2.0 (ene-natl-pc-474) debian/12 Qt/5.15.2 LinphoneSDK/5.3.1 Supported: replaces, outbound, gruu, path, record-aware Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE Contact: <sip:81.249.148.98;transport=udp>;+org.linphone.specs="lime" Content-Type: application/sdp Content-Length: 270

v=0 o=julien.negros 2747 3320 IN IP6 2a01:cb08:1b2:7c00:7d5f:7c9b:defa:7b58 s=Talk c=IN IP6 2a01:cb08:1b2:7c00:7d5f:7c9b:defa:7b58 t=0 0 m=audio 53678 RTP/AVP 0 110 8 101 a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=rtcp:43066

2024-01-08 15:52:34:230 [AppRun.wrapped/belle-sip] MESSAGE channel [0x55a22e859d60]: received [423] new bytes from [UDP://sip.enercoop.org:5060]: CANCEL sip:julien.negros@81.249.148.98;transport=udp SIP/2.0 Via: SIP/2.0/UDP xxxxxxxx:5060;branch=z9hG4bK48bde437;rport Max-Forwards: 70 From: "Julien Negros" sip:+3363xxxxx@xxxxxxxx;tag=as1d27b9c9 To: sip:julien.negros@81.249.148.98;transport=udp Call-ID: 0fae172a061b5c1457cee636675a30cd@xxxxxxxx:5060 CSeq: 102 CANCEL User-Agent: Asterisk PBX 16.28.0~dfsg-0+deb10u2+eepatch10+1 Content-Length: 0

I recommend to make a wireshark capture on the client machine and the server machine to understand where the 200 Ok goes. Perhaps it simply never reaches the server for some external reason (buggy SIP ALG firewall for example).

Best regards,

Simon

[EnercoopJNE]

Thanks for your quick and thorough reply. I really doubt there is anything wrong with the network since all previous versions of Linphone are working fine within, same for current version on Windows. I don't have any firewall on my OS.

I should have written some details on why I think it is an identity problem indeed. I think it's pretty obvious : I just look at the call history. Incoming calls are not logged in my account like it should (outgoing are), I couldn't find the incoming calls at first but they appeared when I switched identity. For me that would explain this strange issue affecting only incoming calls.

[smorlat]

Hi,

I think the two problems are unrelated. 1) for the connectivity issue, I really advice to perform wireshark capture. The fact that the linphone version change triggers the problem doesn't mean that there is a bug in Linphone. The problem might be in the network and is triggered by some few changes in the SIP 200Ok (for example the presence of an IPv6 address in the c= line ?). The SDP address selection algorithm has indeed been revisited between SDK 5.2 and 5.3. 2) the algorithm to classify an incoming call as belonging to an account also as been revisited to avoid mis-classification. Basically we expect the incoming call to have a To header matching the registered identity. As a fallback solution, if the From has a domain matching the registered identity and the To username is matching the registered identity, we consider it is belonging to the account.

All the user / ip address/ domain have been masked in your log (which I can understand of course), unfortunately this makes impossible to analyse this account selection issue. If you wish, you may send me a full (unmodified) log file, showing registration and incoming call consecutively, to my personal email address simon dot morlat at linphone dot org.

[EnercoopJNE]

You were absolutely right, this is indeed a network issue and only happening (so far) on my home network, I didn't test correctly. I'm emailing both the log and wireshark capture (not taken on the same day but same behavior), thank you very much. I tried to deactivate my ISP firewall but same problem.

[EnercoopJNE]

Same issue with version 5.2.1 unfortunately...

[smorlat]

Hi,

You may send a new log to my personal address if you wish that we analyse this issue.

Best regards,

Simon

[EnercoopJNE]

Hello ! Same problem with 5.2.2, I reset the config but no luck. Did you maybe have the chance to look at the logs ? I'm not the only one affected in my company, but it's working fine with <5.2 versions and >5.2 on Windows... There may be something weird with our Asterisk server ?