07-15-2021 04:46 AM - edited 07-15-2021 05:46 AM
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
07-15-2021 05:10 AM
You can upload it by changing the extension to .txt.
ccsip messages will be helpful.
07-15-2021 05:19 AM
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?
07-15-2021 05:25 AM
Upload to any cloud space and share the link.
07-15-2021 05:45 AM - edited 07-15-2021 05:47 AM
I was able to put them both in the original file and have updated the first post.
07-15-2021 09:22 AM - edited 07-16-2021 05:01 AM
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.
07-15-2021 06:19 AM - edited 07-15-2021 07:02 AM
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"
07-16-2021 06:31 AM
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.
07-15-2021 06:59 AM
Pls check similar post may be its helpful.
Pls rate if its “Helpful”. If this answered your question pls click “Accept as Solution”.
07-16-2021 02:03 AM
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
07-16-2021 06:42 AM
07-16-2021 02:31 AM - edited 07-16-2021 02:33 AM
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”.
07-16-2021 06:54 AM
07-16-2021 07:46 AM - edited 07-16-2021 08:44 AM
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.
07-19-2021 09:20 AM
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)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide