Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2098
Views
10
Helpful
12
Replies

Call drops on MOH for external calls.

pbinojgeorge@gmail.com
Level 1
Level 1

‎06-10-2020 07:46 AM

For external calls, the call drops out the issue.

Call flow is 

PSTN>SIP>>CUBE>>>CUCM

Once the call got connected on CUCM user and the user put the call on hold and the call drops out. It is not happening for all the calls. It is happening 2 or 3 times a day.

We took the logs and sent them to the Cisco TAC team. They advised it is because of Service provider and they are dropping the calls( Sending Bye messages).

The service provider advised that we are not offering multiple codecs for MOH. Is there any option to enable Multiple codecs for MOH. I enabled all the codec for MOH under service parameters. Still, we are sending or offering one codec during MOH.

Labels:
0 Helpful
12 Replies 12

TONY SMITH
Spotlight
Spotlight

‎06-11-2020 09:03 AM

Do you have any transcoding resources configured?   Just based on how our systems behave that should get invoked.  For example our normal calls at HQ use G711a, if you put the call on hold a transcoder gets inserted to connect to MOH as G711u.

0 Helpful

pbinojgeorge@gmail.com
Level 1
Level 1
In response to TONY SMITH

‎06-11-2020 07:36 PM

No We don,t have any transcoder resources configured.

Is it possible for configuring for offer multiple codecs on MOH

0 Helpful

Ayodeji Okanlawon
VIP Alumni
VIP Alumni
In response to TONY SMITH

‎06-12-2020 09:44 PM

@TONY SMITH 

Out of curiosity, is there a reason why you didn't advertise only G711a in your moh service parameter to prevent transcoding for when calls are on hold?

Please rate all useful posts
0 Helpful

TONY SMITH
Spotlight
Spotlight
In response to Ayodeji Okanlawon

‎06-13-2020 01:46 AM - edited ‎06-13-2020 01:47 AM

@Ayodeji Okanlawon wrote:

@TONY SMITH 

Out of curiosity, is there a reason why you didn't advertise only G711a in your moh service parameter

The answer's simple, I didn't know that you could.  And in fact I can't find such a service parameter, unless it's well hidden.  All I can find that looks relevant is a generic "G.711 A-law Codec Enabled Required Field" which we have set to "Enabled for all devices" which is default.  Is there a specific MOH codec setting that I haven't found.

It's probably not that important because we need to have transcoding available for other purposes.

0 Helpful

Ayodeji Okanlawon
VIP Alumni
VIP Alumni
In response to TONY SMITH

‎06-13-2020 03:27 AM - edited ‎06-13-2020 03:28 AM

You can select the preferred codec to be used for MOH under the CUCM service parameter > IP Voice Media Streaming App.

The default is G711ulaw which I guess is what you are using. To eliminate the need for xcoding for MOH, choose G711alaw instead..

moh.PNG

 

Please rate all useful posts

pbinojgeorge@gmail.com
Level 1
Level 1
In response to Ayodeji Okanlawon

‎06-13-2020 10:41 PM

@Ayodeji

 

We are advertising multiple codec in Service parameters but it is not offering multiple codecs to Service provider.

0 Helpful

sudaggar
Cisco Employee
Cisco Employee

‎06-11-2020 12:33 PM

Could you please share failed call CUCM traces with calling and called number details.

Regards
0 Helpful

pbinojgeorge@gmail.com
Level 1
Level 1
In response to sudaggar

‎06-11-2020 08:53 PM

Calling number  = 0438 740 709 

Called number  = 08 85803000

 

 

 

 

Preview file
10192 KB
0 Helpful

sudaggar
Cisco Employee
Cisco Employee
In response to pbinojgeorge@gmail.com

‎06-12-2020 01:56 PM

Thanks for sharing CCM traces.

For non working call, after hold is invoked, service provider is sending only G729r8 and G729ar8 codec for media negotiation:

24354050.001 |12:41:28.147 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 1086 from 192.168.4.250:[5060]:
[5582202,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.30:5060;branch=z9hG4bK4085010b77d6b
From: <sip:885803000@192.168.4.30>;tag=1908548~5850e04e-f054-411b-aec4-2d22d81cec4d-17799041
To: <sip:438740709@renmarkparinga.sa.gov.au>;tag=F5C53D68-ED8
Date: Tue, 19 May 2020 03:11:28 GMT
Call-ID: 3495B5E5-98B511EA-A9618A4F-9719B566@192.168.4.250
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:438740709@192.168.4.250>;party=called;screen=no;privacy=off
Contact: <sip:9100@192.168.4.250:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M7
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Length: 273

v=0
o=CiscoSystemsSIP-GW-UserAgent 9014 8975 IN IP4 192.168.4.250
s=SIP Call
c=IN IP4 192.168.4.250
t=0 0
m=audio 31988 RTP/AVP 18 101
c=IN IP4 192.168.4.250
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20


however in service parameters, there are below option for MOH:

G711ulaw
G711alaw
G729Annex A
wideband

Because of media capability mismatch it is trying to allocate transcoder and "RENMARK_XCODE" allocated and media got negotiated.

24354220.001 |12:41:28.168 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.168.4.250:[5060]:
[5582203,NET]
ACK sip:9100@192.168.4.250:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.30:5060;branch=z9hG4bK4085176f2735
From: <sip:885803000@192.168.4.30>;tag=1908548~5850e04e-f054-411b-aec4-2d22d81cec4d-17799041
To: <sip:438740709@renmarkparinga.sa.gov.au>;tag=F5C53D68-ED8
Date: Tue, 19 May 2020 03:11:28 GMT
Call-ID: 3495B5E5-98B511EA-A9618A4F-9719B566@192.168.4.250
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 205

v=0
o=CiscoSystemsCCM-SIP 1908548 3 IN IP4 192.168.4.30
s=SIP Call
c=IN IP4 192.168.4.250
t=0 0
m=audio 31990 RTP/AVP 18
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no

After call got connected with MOH, disconnect received from service provider after 3 seconds.
24354373.003 |12:41:31.176 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 598 from 192.168.4.250:[5060]:
[5582235,NET]
BYE sip:f4b34bf3-aca6-cc19-e3d4-f5c3b87b6ec8@192.168.4.30:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.250:5060;branch=z9hG4bK7A7C66F
From: <sip:438740709@renmarkparinga.sa.gov.au>;tag=F5C53D68-ED8
To: <sip:885803000@192.168.4.30>;tag=1908548~5850e04e-f054-411b-aec4-2d22d81cec4d-17799041
Date: Tue, 19 May 2020 03:11:28 GMT
Call-ID: 3495B5E5-98B511EA-A9618A4F-9719B566@192.168.4.250
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M7
Max-Forwards: 70
Timestamp: 1589857891
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=1031,OS=20590,PR=1193,OR=23860,PL=0,JI=0,LA=0,DU=24
Content-Length: 0

During this 3 seconds, is there a silence or MOH to calling number?

In order to further troubleshoot this issue, need to compare working and non working call when hold is invoked. As issue is intermittent it can be easily reproducible.

Also, please provide simultaneous below debugs from cube:
debug ccsip messages
debug voice ccapi inout

Regards
0 Helpful

pbinojgeorge@gmail.com
Level 1
Level 1
In response to sudaggar

‎06-13-2020 10:34 PM

Thanks

I am attaching the working calls from cube and cucm .

 

Calling number 0470542587

called number 0885803018

Preview file
80 KB
0 Helpful

pbinojgeorge@gmail.com
Level 1
Level 1
In response to sudaggar

‎06-13-2020 10:36 PM

cucm traces

Preview file
10183 KB
0 Helpful

sudaggar
Cisco Employee
Cisco Employee
In response to pbinojgeorge@gmail.com

‎06-15-2020 06:01 PM

For the working call, CUBE is sending all supported codecs, when hold is invoked:
37674036.001 |14:03:21.670 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 1168 from 192.168.4.250:[5060]:
[8571082,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.30:5060;branch=z9hG4bK64e0e123f37ed
From: <sip:885803018@192.168.4.30>;tag=2921023~5850e04e-f054-411b-aec4-2d22d81cec4d-17812910
To: <sip:470542587@renmarkparinga.sa.gov.au>;tag=7BF55464-1100
Date: Sun, 14 Jun 2020 04:33:21 GMT
Call-ID: F9999C68-AD2E11EA-B8408A4F-9719B566@192.168.4.250
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:470542587@192.168.4.250>;party=called;screen=no;privacy=off
Contact: <sip:3018@192.168.4.250:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M7
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Length: 354

v=0
o=CiscoSystemsSIP-GW-UserAgent 8585 4571 IN IP4 192.168.4.250
s=SIP Call
c=IN IP4 192.168.4.250
t=0 0
m=audio 25908 RTP/AVP 8 0 18 9 101
c=IN IP4 192.168.4.250
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


However, in case of non-working call, CUBE is sending only G729:
24354050.001 |12:41:28.147 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 1086 from 192.168.4.250:[5060]:
[5582202,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.30:5060;branch=z9hG4bK4085010b77d6b
From: <sip:885803000@192.168.4.30>;tag=1908548~5850e04e-f054-411b-aec4-2d22d81cec4d-17799041
To: <sip:438740709@renmarkparinga.sa.gov.au>;tag=F5C53D68-ED8
Date: Tue, 19 May 2020 03:11:28 GMT
Call-ID: 3495B5E5-98B511EA-A9618A4F-9719B566@192.168.4.250
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:438740709@192.168.4.250>;party=called;screen=no;privacy=off
Contact: <sip:9100@192.168.4.250:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M7
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Length: 273

v=0
o=CiscoSystemsSIP-GW-UserAgent 9014 8975 IN IP4 192.168.4.250
s=SIP Call
c=IN IP4 192.168.4.250
t=0 0
m=audio 31988 RTP/AVP 18 101
c=IN IP4 192.168.4.250
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

 

Could you please check all dial-peers on CUBE towards CUCM having same config or is there any discrepancy in any of the dial-peer towards CUCM.

 

Customers Also Viewed These Support Documents