BelledonneCommunications
Linphone hangs up call on voip.ms server after 30 seconds
Good afternoon!
I am having an issue with linphone connected to voip.ms lines. When a call comes in through our IVR to call queue, after about 30 seconds from accepting the call, it drops. This can be reproduced every single time. We would expect it to not drop for no reason like this, and i'm not sure if it's voip.ms doing this or linphone.
- Device: Google Pixel 7
- OS: Android 14
- Version of the App: 5.2.5
- Version of the SDK: 5.3.47
- Where you did got it from: Play store
Logs: https://www.linphone.org:444//tmp/665bb8c0a31e3_9942b6fb4eba868b1ec3.gz
Hi,
Call is being terminated because no ACK is being received for the SIP transaction:
2024-06-01 19:11:35:415 [org.linphone/belle-sip] ERROR Dialog [0x7abc4f8bf0] was not ACK'd within T1*64 seconds.
2024-06-01 19:11:35:415 [org.linphone/belle-sip] ERROR Dialog [0x7abc4f8bf0] it is going to be terminated automatically.
But ACK is being received, but because the TO-tag isn't in the message, it is ignored:
2024-06-01 19:11:34:970 [org.linphone/belle-sip] MESSAGE channel [0x7c5ab1ae10]: received [647] new bytes from [TCP://chicago3.voip.ms:5060]:
ACK sip:98.220.213.22:58282;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 208.100.60.10:5060;branch=z9hG4bK2594c868;rport
Max-Forwards: 70
From: "MAV N 8327689413" <sip:[email protected]>;tag=as3525d834
To: <sip:[email protected]:58282;pn-prid=enbEN_lISHuxrF1b6XdH8Q:APA91bHKF0Qg7aMeSJrcpOqqFeZkfgcILM5GEY8CDcNtG2fM7A1p-tR079XfFwmli_-tdpDc5yifbl9ccdLEx0lcmi3efx0mTOR3k6jwjRk6vCdKSibogyMBBrBwnF9ivRzA346TS6Dz;pn-provider=fcm;pn-param=251776523448;pn-silent
Contact: <sip:[email protected]:5060;transport=TCP>
Call-ID: [email protected]:5060
CSeq: 102 ACK
User-Agent: voip.ms
Content-Length: 0
2024-06-01 19:11:34:999 [org.linphone/belle-sip] MESSAGE channel [0x7c5ab1ae10] [647] bytes parsed
2024-06-01 19:11:34:999 [org.linphone/liblinphone] WARNING Receiving ACK without to-tag but no know dialog here, ignoring
@smorlat Do you know what has to be done here?
Cheers,
Just wanted to follow up on this again, this is making the app completely unusable.
I'm having this issue as well, I just downloaded Linphone for the first time today. Seems to be a problem with inbound calls only, outbound calls are working fine. I opened a ticket with VoIP.ms.
Same probem here, with linphone-android-release-6.0.0-alpha.1494+e664e1802.apk.
TLS/SRTP is enabled.
The To: in INVITE is very long - >280 char. In the ACK it's truncated to 255 char. In the logs, ortp complains that the To string is too long. The source code ortp/src/rtcp.c has a comment saying rfc3550 limits the text to 255 char.
I haven't used Wireshark to see where the to is being truncated (before send by linphone, or on receipt at VoIP.ms),
Can the pn-prid in the To be shortened, especially for TLS/SRTP connections?
This issue can be resolved by disabling "Allow push notifications" in the Linphone app for the voip.ms account. This setting can be found from the account page, then "Manage the profile" for the voip.ms account, then under Other actions open "Account settings". Push notifications are not supported by voip.ms, thus disabling them has no detrimental effect.
I do not intend to dig further to determine where the To text sent back in the in the ACK gets truncated (it might be a linphone bug, it might be a voip.ms bug).
Maybe related to the invalid ACK, maybe not. When both SRTP and Push notifications are enabled, the cname included in the RTCP packet is too long and violates RFC3550 limit of 255 octets. For example: 2024-12-19 12:43:24:165 [org.linphone/ortp] WARNING Cname [sip:[email protected]:56678;pn-prid=cz89pd0QTFKwGXudKaLx5Z:APA91bGvVd42C6AgHDbuEOFN_O14tvCwY1puZgen-9B7fYYoT1Kw48z0A4ZxIh1_q7L-BFS5GFcelbij9_meCyz6EacJaoZHVNu03L09kZcuZqfkIEZOR2opPy9_Sz0-eG4eWkcSGOLh;pn-provider=fcm;pn-param=251776523448;pn-silent=1;pn-timeout=0;transport=tls] too long for session [0xb4000078a4e44a00]
This issue can be resolved by disabling "Allow push notifications" in the Linphone app for the voip.ms account.
Thank you so very much, this is spot on!
Glad I could help out. Thanks to Belledonne for posting all their source code!