Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: SIP protocol based issue for outgoing external calls with Cisco Call Manager (CUCM) #201

Open
Redirion opened this issue Mar 17, 2022 · 1 comment
Labels

Comments

@Redirion
Copy link

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

  • 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 "####

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

@Redirion Redirion added the bug label Mar 17, 2022
@Redirion
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant