You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cisco Unified Communications Manager (CallManager) also called CUCM is used in the current version 12.5. CUCM is basically responsible for providing the sip service. Linphone is currently being evaluated to be used as a simple SIP client for local calls but also for outgoing calls (to landline, mobile phones).
A regular Wndows laptop is used with the official Linphone Client, latest version, 4.3.2.
General information
Device: Laptop
OS: Windows 10
Version of the App: 4.3.2
Version of the SDK: 5.0.49 according to the logs
Expected behaviour
While internal calls work, both inbound and outbound, for external calls only inbound are working, outbound external calls fail. Outbound calls to e.g. mobile phones should work.
To Reproduce
That will be the hard part, I guess the issue is between Linphone and CUCM. But as it happens on SIP protocol level it should be possible to investigate why Linhpone behaves unexpectedly.
Attached you will find three logs:
linphone1.log is directly taken from the Windows laptop for the Linphone's point of view
LinphoneToCUCMFail.txt alas being from another test day shows exactly what is happening from CUCM points of view
CiscoToCUCMSuccess.txt is a Cisco Phone working fine with external calls, logs taken from CUCM and points of interest are annotated with "####
Cisco Technical Assistance Center was involved to figure it the cause and stated the following:
"The call flow and signaling for working outbound calls are identical to the non-working calls except for the calling devices response to the UPDATE CUCM is sending with the working call sending a 200 OK without an SDP and the non-working call sending a 200 OK with an SDP.
The only way for CUCM not to send the UPDATE to the calling phone would be if we received a 180 Ringing that we could then forward to the phone. Since neither CUCM or even the GW is receiving the 180 Ringing, we are unable to send the same to the device and instead send the UPDATE message. CUCM is working as expected and currently the only option moving forward is to apply a change to the 3rd party device so that it responds to the UPDATE without an SDP."
Is it possible to alter the behaviour of Linphone to not include SDP payload in a 200 OK? Maybe a config line in the rc file? It seems redundant as media negotiation happened just before and matches perfectly: PCMU is requested from CUCM and Linphone tells with the m=audio line that it supports that.
Initially I thought the error could be a codec mismatch as the quit message "Q.850;cause=47" indicates this when googling the issue. But apparently the issue is more that Linphone sends SDP data when it should not. So it appears to be an issue at SIP protocol level.
SDK logs URL
No response
The text was updated successfully, but these errors were encountered:
as a workaround it was possible with help of Cisco TAC to get outbound external calls working by applying a custom SIP Normalization Script. Essentially the offending SDP payload had to be removed entirely.
Can anyone please comment if Linphone is not following SIP protocol here? I feel this should be fixed to avoid the requirement of a workaround in first place. Other systems might also be affected, not just Cisco CUCM.
Context
Cisco Unified Communications Manager (CallManager) also called CUCM is used in the current version 12.5. CUCM is basically responsible for providing the sip service. Linphone is currently being evaluated to be used as a simple SIP client for local calls but also for outgoing calls (to landline, mobile phones).
A regular Wndows laptop is used with the official Linphone Client, latest version, 4.3.2.
General information
Expected behaviour
While internal calls work, both inbound and outbound, for external calls only inbound are working, outbound external calls fail. Outbound calls to e.g. mobile phones should work.
To Reproduce
That will be the hard part, I guess the issue is between Linphone and CUCM. But as it happens on SIP protocol level it should be possible to investigate why Linhpone behaves unexpectedly.
Attached you will find three logs:
linphone1.log is directly taken from the Windows laptop for the Linphone's point of view
LinphoneToCUCMFail.txt alas being from another test day shows exactly what is happening from CUCM points of view
CiscoToCUCMSuccess.txt is a Cisco Phone working fine with external calls, logs taken from CUCM and points of interest are annotated with "####
linphone1.log
CiscoToCUCMSuccess.txt
LinphoneToCUCMFail.txt
"#####" are placed in the .txt files to guide through what is happening
Additional context
Cisco Technical Assistance Center was involved to figure it the cause and stated the following:
"The call flow and signaling for working outbound calls are identical to the non-working calls except for the calling devices response to the UPDATE CUCM is sending with the working call sending a 200 OK without an SDP and the non-working call sending a 200 OK with an SDP.
The only way for CUCM not to send the UPDATE to the calling phone would be if we received a 180 Ringing that we could then forward to the phone. Since neither CUCM or even the GW is receiving the 180 Ringing, we are unable to send the same to the device and instead send the UPDATE message. CUCM is working as expected and currently the only option moving forward is to apply a change to the 3rd party device so that it responds to the UPDATE without an SDP."
Is it possible to alter the behaviour of Linphone to not include SDP payload in a 200 OK? Maybe a config line in the rc file? It seems redundant as media negotiation happened just before and matches perfectly: PCMU is requested from CUCM and Linphone tells with the m=audio line that it supports that.
Initially I thought the error could be a codec mismatch as the quit message "Q.850;cause=47" indicates this when googling the issue. But apparently the issue is more that Linphone sends SDP data when it should not. So it appears to be an issue at SIP protocol level.
SDK logs URL
No response
The text was updated successfully, but these errors were encountered: