Re: Inbound SIP calls forwarded to mobile phone disconnects after 60 seconds - BYE Q.850;cause=127

Stefan W. · ‎07-15-2021

Hi Team,

i have an issue with inbound calls which are being forwarded and disconnected after 60 seconds.

A call comes in via CUBE, reaches CUCM, gets forwarded by CUCM and leaves via the same CUBE towards the external destination and gets disconnected after 60 seconds. It does not matter if the call gets picked up or not.

On the CUBE i get a BYE with Reason: Q.850;cause=127

Normal outbound calls work fine.

Can you please help me to understand what the reason for this behaviour might be?
To me it looks like some sort of SIP-Timeout that might cause that reaction.

CUBE: Version 16.09.07

CUCM: 11.5.1.21900-40

ccapi inout and ccsip messages debugs are attached

Best Regards

Stefan

Nithin Eluvathingal · ‎07-15-2021

You can upload it by changing the extension to .txt.

ccsip messages will be helpful.

Stefan W. · ‎07-15-2021

I did that and even created a new .txt and just copied the log in there but same issue...

Also gave it a different name but same issue. Might it be an issue with the actual content since it is a Secure SIP-Trunk towards the ITSP and authentication is happening?

Nithin Eluvathingal · ‎07-15-2021

Upload to any cloud space and share the link.

Stefan W. · ‎07-15-2021

I was able to put them both in the original file and have updated the first post.

Nithin Eluvathingal · ‎07-15-2021

Since your issue is only with forwarded calls to mobile , and both incoming and outgoing calls are working with your SIP provider. I would suggest to open ticket with both Cisco TAC and ISP and work together.

You can try the behavior forwarding to another number instead of a mobile number.

Sadav Ansari · ‎07-15-2021

Hi,

Is this forwarded call or conference call ?

Is this issue on that specific number or all?

is outbound call working fine when you dialling that forwarded number ?

Is MTP checked on your SIP trunk ?

As per the logs its showing conference call.

051127: *Jul 15 2021 10:35:43.296: //273103/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
xcoder inserted for preferred features w/ mask 0x0
051128: *Jul 15 2021 10:35:43.296: //273103/3C11FB54B5D7/CCAPI/ccConferenceCreate:
delay media to slow start case, codec negotation is not done

++Conference Id=0x14F, Source Interface=0x7F8B4DC6DC40, Source Call Id=273105,
Destination Call Id=273103, Disposition=0x0, Tag=0x0
051241: *Jul 15 2021 10:36:47.673: //273103/3C11FB54B5D7/CCAPI/cc_generic_bridge_done:
Conference Id=0x14F, Source Interface=0x7F8B4DC6DC40, Source Call Id=273105,
Destination Call Id=273103, Disposition=0x0, Tag=0x0
051242: *Jul 15 2021 10:36:47.673: //273103/3C11FB54B5D7/CCAPI/ccCallDisconnect:
Cause Value=127, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=127)
051243: *Jul 15 2021 10:36:47.673: //273103/3C11FB54B5D7/CCAPI/ccCallDisconnect:
Cause Value=127, Call Entry(Responsed=TRUE, Cause Value=127)
051244: *Jul 15 2021 10:36:47.673: //273105/3C11FB54B5D7/CCAPI/ccCallDisconnect:
Cause Value=127, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
051245: *Jul 15 2021 10:36:47.673: //273105/3C11FB54B5D7/CCAPI/ccCallDisconnect:
Cause Value=127, Call Entry(Responsed=TRUE, Cause Value=127)
051246: *Jul 15 2021 10:36:47.674: //273103/3C11FB54B5D7/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x7F8B4DC6DC40, Tag=0x0, Call Id=273103,
Call Entry(Disconnect Cause=127, Voice Class Cause Code=0, Retry Count=0)
051247: *Jul 15 2021 10:36:47.674: //273103/3C11FB54B5D7/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent

++Not sure but issue suspected from Codec site as coded negotiation is not done as per logs.

Pls rate if its "Helpful". If this answered your question pls click "Accept as Solution"

Stefan W. · ‎07-16-2021

Hi Sadav,

thanks for your reply.

This is only supposed to be a forwarded call to external without any conference and yes, normal calls to that forwarded number work totally fine.

MTP is not checked in the Trunk configuration.

The "delay media to slow start case, codec negotation is not done" happens in the initial setup but when you pickup the call audio works normal until it cuts off after 60 seconds.

Sadav Ansari · ‎07-15-2021

Pls check similar post may be its helpful.

https://community.cisco.com/t5/ip-telephony-and-phones/outbound-calls-dropping-with-cause-code-127/td-p/2643337

Pls rate if its “Helpful”. If this answered your question pls click “Accept as Solution”.

Scott Leport · ‎07-16-2021

Hi,

A copy of your CUBE configuration would be useful if you wouldn't mind sharing it.

As the other guys have said, it looks like a codec negotiation issue of some sort. I can see there are other disconnect cause codes in the ccapi debugs of "47", which usually indicates codec or media negotiation issues.

Do you have the following command enabled on your CUBE?

Voice service voip
 SIP
  early-offer forced

Stefan W. · ‎07-16-2021

Hi Scott,

yes early-offer forced is configured.

Here is a summary of the config.

Sadav Ansari · ‎07-16-2021

Exactly as suggested by Scott there is disconnect cause 47 also there on the log.

40.426: //273104/3C11FB54B5D7/CCAPI/cc_api_call_disconnected:
   Cause Value=47, Interface=0x7F8B4DC6DC40, Call Id=273104
050852: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=47, Retry Count=0)
050853: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/cc_api_event_indication:
   Event=213, Call Id=273104
050854: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/cc_api_event_indication:
   Event Is Sent To Conferenced SPI(s) Directly
050855: *Jul 15 2021 10:35:40.426: //273103/3C11FB54B5D7/CCAPI/ccCallReleaseResources:
   release reserved xcoding resource.
050856: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/ccCallSetAAA_Accounting:
   Accounting=1, Call Id=273104
050857: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/ccCallDisconnect:
   Cause Value=47, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=47)
050858: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/ccCallDisconnect:
   Cause Value=47, Call Entry(Responsed=TRUE, Cause Value=47)
050859: *Jul 15 2021 10:35:40.426: //273104/3C11FB54B5D7/CCAPI/cc_api_call_disconnect_done:
   Disposition=-11, Interface=0x7F8B4DC6DC40, Tag=0x0, Call Id=273104,
   Call Entry(Disconnect Cause=47, Voice Class Cause Code=0, Retry Count=0)

Cause 47 mainly the media negotiation issue.

Pls rate all useful post!!

Pls rate if its “Helpful”. If this answered your question pls click “Accept as Solution”.

Stefan W. · ‎07-16-2021

I noticed yesterday that the CUBE's CFB on the CUCM was not registered and solved that.

Now the logs look slightly different, at least there are no Cause 47 anymore but instead Cause 41.

Scott Leport · ‎07-16-2021

Hello.

Thanks for providing the updated debugs and good work on solving the CFB issue.

Fundamentally, I think you have a dial-peer matching issue. In both debugs I can see that on the inbound call from PSTN to CUBE, the incoming dial-peer is 300, but the matching outgoing dial-peer is 900. The reason that's happening is because your e164 pattern-map (101) configured is +4684024400, which is an exact match. I believe that you want to be matching dial-peer 100, which would send the call to CUCM.

There is also some looping going on as shown below:

055953: *Jul 16 2021 12:12:18.426: //-1/E65BDCEA8635/CCAPI/cc_api_call_setup_ind_common:
Interface=0x7F8B4DC6DC40, Call Info(
Calling Number=sip:+46730290467@bt15694992.siptrunk.tele2.net,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=sip:+4684024400@10.215.64.120:5060(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=0, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=293202
055954: *Jul 16 2021 12:12:18.426: %CALL_CONTROL-6-CALL_LOOP: The incoming call has a global identifier already present in the list of currently handled calls. It is being refused.

055955: *Jul 16 2021 12:12:18.426: //-1/E65BDCEA8635/CCAPI/cc_api_call_setup_ind_common:
SPI Call Setup Request Is Failed

Can you add the number +4684024400 into e164 pattern map 100 and try again please?

You may also try the same test with a different number to go further to validate this.

Stefan W. · ‎07-19-2021

Hi Scott,

thanks for your input.

I changed the pattern-map as requested and now the logs look way better without loops. (Logs attached)

One thing I noticed: when I forward the calls to my private cell phone it works totally fine and there is no disconnect so this might actually be related to the carrier since we have different outcomes with different mobile carriers right now. (working example attached also)