MOH & Cube

Answered Question
Feb 21st, 2013

Hi,

Environment is CUCM - H323 - CUBE - ISP

Inbound & outbound calls all work fine however MOH does not work. Have checked that MOH is streaming from CUCM and is Unicast. Have checked all codecs in the Service Parameters for MOH to include G729 and restarted Streaming Service.

Attached is my config (cutdown), debug of CCSIp when triggering MOH and screenshot from CUCM of MOH service parameters.

Any ideas appreciated!

Cheers

Pieter

I have this problem too.
0 votes
Correct Answer by Ayodeji oladipo... about 1 year 1 month ago

Pieter,

I have looked at your attached CUBE traces. I need to see CUCM traces. To invoke MOH over a sip trunk here is what happens

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

From the traces, I can see the first step happened., CUBE sennt an inactive media to the ITSP, that means that CUBE received an inactive media from CUCM..However I dint see CUBE connecting to MOH, probably because it didnt receive instructionf rom CUCM..This is why we need CUCM traces

I also noticed that this is your call flow....

CUCM-----h323------CUBE----SIP----ITSP

I guessed this because I cant see the sip messages on the lge from CUCM..Is this correct. If it is, i will advise you to change this to a full sip setup. Use a sip trunk from CUCM to CUBE instead of h323

Sent:
INVITE sip:0429988277@210.193.202.230:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.11.2.254:5060;branch=z9hG4bK2B8F23F7
From: 0383702460@macquarietelecom.com>;tag=80757F58-2A
To: ;tag=1710219635-1361507764438
Date: Fri, 22 Feb 2013 04:39:48 GMT
Call-ID: A56C235E-7BE011E2-943A9268-86818484@10.11.2.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0010985561-2952093970-0722698241-0168493677
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 103 INVITE
Max-Forwards: 70
Timestamp: 1361507988
Contact:
Expires: 300
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 4195 9232 IN IP4 10.11.2.254
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 19394 RTP/AVP 18 101
c=IN IP4 0.0.0.0---------------------------------------Call is muted (usually because of transfer or hold)
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=inactive-------------------------------------------media is inactive

+++++++Cube received inactive media response back from ITSP..which is expected++++++++

Feb 22 04:39:49: //44838/00A7A0592B13/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.11.2.254:5060;branch=z9hG4bK2B8F23F7
From: 0383702460@macquarietelecom.com>;tag=80757F58-2A
To: ;tag=1710219635-1361507764438
Call-ID: A56C235E-7BE011E2-943A9268-86818484@10.11.2.254
CSeq: 103 INVITE
Timestamp: 1361507988
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported:
Accept: application/media_control+xml,application/sdp
Contact:
Content-Type: application/sdp
Content-Length: 268

v=0
o=BroadWorks 17488194 2 IN IP4 210.193.202.230
s=-
c=IN IP4 210.193.202.230
t=0 0
m=audio 10718 RTP/AVP 18 101
a=inactive
a=ptime:20
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=fmtp:18 annexb=no
a=silenceSupp:off - - - -

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (6 ratings)
Ayodeji oladipo... Fri, 02/22/2013 - 00:25

Pieter,

We had love to h elp out here but there is a problem with CSC website. The files you have attached are showing as 31 bytes...and Queued for virsu scanning..Which means we cant download them.

You can send me an email to deji_ok@hotmail.co.uk

Please include the full CUCM trace for when MOH was attempted along with the CUBE traces..Also the calling and called number

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Terry.Cheema Fri, 02/22/2013 - 02:18

Yeah - I also tried opening few hours back - since then keeps showing queued for virus scanning or blocked.

Terry

Ayodeji oladipo... Fri, 02/22/2013 - 03:18

Terry, How you doing buddy! Hope you are good.. I have sent an email to one of the cummunity managers. Hoepfully it will be resolved soon. 

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Terry.Cheema Fri, 02/22/2013 - 10:55

Very well Deji - hope you are doing good too. Thanks mate - I started noticing this a day or two back - hopefully it will be resolved soon.

Terry

Sent from Cisco Technical Support iPhone App

Correct Answer
Ayodeji oladipo... Fri, 02/22/2013 - 03:26

Pieter,

I have looked at your attached CUBE traces. I need to see CUCM traces. To invoke MOH over a sip trunk here is what happens

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

From the traces, I can see the first step happened., CUBE sennt an inactive media to the ITSP, that means that CUBE received an inactive media from CUCM..However I dint see CUBE connecting to MOH, probably because it didnt receive instructionf rom CUCM..This is why we need CUCM traces

I also noticed that this is your call flow....

CUCM-----h323------CUBE----SIP----ITSP

I guessed this because I cant see the sip messages on the lge from CUCM..Is this correct. If it is, i will advise you to change this to a full sip setup. Use a sip trunk from CUCM to CUBE instead of h323

Sent:
INVITE sip:0429988277@210.193.202.230:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.11.2.254:5060;branch=z9hG4bK2B8F23F7
From: 0383702460@macquarietelecom.com>;tag=80757F58-2A
To: ;tag=1710219635-1361507764438
Date: Fri, 22 Feb 2013 04:39:48 GMT
Call-ID: A56C235E-7BE011E2-943A9268-86818484@10.11.2.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0010985561-2952093970-0722698241-0168493677
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 103 INVITE
Max-Forwards: 70
Timestamp: 1361507988
Contact:
Expires: 300
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 4195 9232 IN IP4 10.11.2.254
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 19394 RTP/AVP 18 101
c=IN IP4 0.0.0.0---------------------------------------Call is muted (usually because of transfer or hold)
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=inactive-------------------------------------------media is inactive

+++++++Cube received inactive media response back from ITSP..which is expected++++++++

Feb 22 04:39:49: //44838/00A7A0592B13/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.11.2.254:5060;branch=z9hG4bK2B8F23F7
From: 0383702460@macquarietelecom.com>;tag=80757F58-2A
To: ;tag=1710219635-1361507764438
Call-ID: A56C235E-7BE011E2-943A9268-86818484@10.11.2.254
CSeq: 103 INVITE
Timestamp: 1361507988
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported:
Accept: application/media_control+xml,application/sdp
Contact:
Content-Type: application/sdp
Content-Length: 268

v=0
o=BroadWorks 17488194 2 IN IP4 210.193.202.230
s=-
c=IN IP4 210.193.202.230
t=0 0
m=audio 10718 RTP/AVP 18 101
a=inactive
a=ptime:20
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=fmtp:18 annexb=no
a=silenceSupp:off - - - -

wrerase.reload Fri, 02/22/2013 - 23:04

Wow! I am humbled by the effort you have put in and your experience. Thank you very much!

Yes you are correct. Reason I have kept it CUCM-h323-cube is for the amount of route patterns associated to the H323 gateway. I did see that this is supported with Cube, so felt it was safe. Would you say totally forget about H323 trunk to Cube or can I still try to get it working. It is still preferred method in y environment.

I will only get onsite again next week to collect the CUCM traces. I will endeavour to get onsite on Tuesday to collect.

Again, thank you!

Pieter

Ayodeji oladipo... Sat, 02/23/2013 - 00:02

Pieter,

From experience it is better to to have an all sip integration where possible. One of the many factors is inter operability, another is troubleshooting. In your scenario we will need to troubleshoot both sip and h323 leg. I am sure it can work, its just not the recommended approach.
To troubleshoot this scenario we will need

1. Debug h225 asn1
2. Debug h245 asn1
3. Debug ccsip messages
4. Cucm SDI traces
5. Cube config

If we had only a sip integration, we won't need the h225,h245 debugs. That's one of the advantages.

You also need to ensure that your cube is assigned a MRGL with the correct MOH MRG.






Sent from Cisco Technical Support Android App

wrerase.reload Tue, 02/26/2013 - 20:37

Thank you very much. I have collected the traces and sent to your inbox.

Look forward to what you find.

Cheers!!!

Ayodeji oladipo... Wed, 02/27/2013 - 11:18

Pieter,

I have looked at the traces and here is what I found...

++++Here we see CUCM selected "MOH_EQT_MEL" for the session+++

11:51:28.091 |MediaResourceCdpc(3273)::resource_rsvp_AllocateMohResourceRes CI=18514284, DeviceName=MOH_EQT_MEL|1,100,17,21533.10^10.11.2.254^Port 50568

+++Here we see the region setting between MOH server and the held and holding party+++

11:51:28.091 |MohDControl - findUnicastSourceGivenSourceNum - Device Name = MOH_EQT_MEL, MohRegion = REG_EQT_MEL, Held Party Region = REG_EQT_MEL, Holding Party Region =REG_EQT_MEL|1,100,17,21533.10^10.11.2.254^Port 50568

+++++++Here we see the unicast audio source to be streamed, its audio source 51+++++++++=


11:51:28.091 |MohDControl - handleMohSuccess - Call Id = 18514284 AudioSourceID = 51 MuticastFlag = 0|1,100,17,21533.10^10.11.2.254^Port 50568

11:51:28.091 |MohDControl - handleUnicastResourceAllocation - Device Name = MOH_EQT_MEL|1,100,17,21533.10^10.11.2.254^Port 50568

++++CUCM says MOH allocate success+++


11:51:28.091 |MohDControl - handleMohSuccess - Sent out Allocate MOH Response CallId=18514284, TransferMode=4, Ip=0, Port=0, CapCount=5, AudioSourceID = 51 MuticastFlag = 0|1,100,17,21533.10^10.11.2.254^Port 50568

++++Here we see the MOH counter increased by 1...this is a sign that MOH device was succesfully allocated+++++

11:51:28.091 |MRM::updateMohCounter devName=MOH_EQT_MEL, countChange=1|1,100,17,21533.10^10.11.2.254^Port 50568

++++Here CUCM sends a start media transmission for MOH to the CUBE+++++

11:51:28.183 |MohDControl - stationOutputStartMediaTransmission tcpPID = [1.100.9.41051] myIP: fd020b0a (10.11.2.253)|1,100,17,21533.16^10.11.2.254^Port 50568
11:51:28.183 |MohDControl - RemoteIpAddr: fe020b0a (10.11.2.254) RemoteRtpPortNumber: 29350 msecPacketSize: 20 compressionType: 11|1,100,17,21533.16^10.11.2.254^Port 50568

So everything looks okay from CUCM....So why is it  not working...Lets look at what we see in IPVMS traces

At 11:51:28 the same time that CUCM sends a start media transmission for MOH stream, we get this error from the CMOHMgr process on the IPVMS...."Fixed Audio Source Melbourne Live failed to start"

11:51:28.816 |   CMOHMgr::PlayStream (12,51,0) Fixed Audio Source Melbourne Live failed to start

So here is our Culprit..Looks like there is a problem with the fixed audio source.....Can you try another audio source and see if that works

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

wrerase.reload Wed, 02/27/2013 - 21:04

Thank you, good find!

I did ask them to chnage and advise but they say it is still a problem. I will go onsite tomorrow to address and collect more traces to see if this is the case.

Regards

Pieter

wrerase.reload Mon, 03/04/2013 - 00:30

Hi Aokanlaon,

Have you had a moment to have a look at my lastest traces yet?

Thanks

Pieter

Ayodeji oladipo... Mon, 03/04/2013 - 04:32

Pieter,

I am sorry I havent had time to look at it. I have been so busy! Hopefully I can look at it tonight..sorry again

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Ayodeji oladipo... Mon, 03/04/2013 - 09:13

Pieter,

Ok I had a look and unfortunately the log for IPVmS service stops at 11:17

CUCM sends a start media transmission for MOH at 11:23..So I cant see what happened on the server..

11:23:43.296 |MohDControl - stationOutputStartMediaTransmission tcpPID = [1.100.9.51468] myIP: fd020b0a (10.11.2.253)|1,100,17,23601.16^10.11.2.254^Port 57560

11:23:43.296 |MohDControl - RemoteIpAddr: fe020b0a (10.11.2.254) RemoteRtpPortNumber: 19542 msecPacketSize: 20 compressionType: 11|1,100,17,23601.16^10.11.2.254^Port 57560

However I see a lot of errors on the IPVMS component of CUCM

10:52:02.441 |   [MTP][10.11.2.253]CTTCPSocket::HandleWrite *ERROR* EMPTY in TCP Write
10:52:02.441 |   [CFB][10.11.2.253]CTTCPSocket::HandleWrite *ERROR* EMPTY in TCP Write
10:52:02.441 |   [MOH][10.11.2.253]CTTCPSocket::HandleWrite *ERROR* EMPTY in TCP Write
10:52:02.445 |   [ANN][10.11.2.253]CTTCPSocket::HandleWrite *ERROR* EMPTY in TCP Write

kMOHTFTPGoRequestFailed - Transfer of MOH source file to working path failed. Error Description:Error getting MOH source file File Name:Windows XP Aanmelden.g729.wav

Can you look download the logs again and see if you get any entry for 11:23. Its important to see what happens there.

The Audio source file CUCM is trying to use is "2"

Do you know if MOH works between IP phones. Do you get MOH when you do an internal call with this file?

wrerase.reload Mon, 03/04/2013 - 15:40

Thanks Aokanlawon,

I did enable debugging for the IPVMS service but it did not write to the log file. I tried several times including restarting the service. I saw the errors but they are referring to files that are not in the MOH list. I have no idea where these come from. Look sto be internal.

The MOH works fine for internal users and uses the same source file for the MOH for users on the PSTN. No 2 is the MOH file we are after.

Regards

Pieter

Ayodeji oladipo... Mon, 03/04/2013 - 22:19
Pieter,

Thanks for the update. I have done further research and this is definitely a problem on CUCM side...

The two stages for playing MOH on h323 call

1. CUCM sends a closelogical channel to the existing call

2. cucm sends a open logical channel ACK with the ip address of CUCM-MOH server and port (usually 4000)

In this case CUCM is sending "empty capabiilities"

H245ASN - TtPid=(23601) -Outgoing #198669 -value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :

    {

      forwardLogicalChannelNumber 1,

      forwardMultiplexAckParameters h2250LogicalChannelAckParameters :

        {

          sessionID 1,

          mediaChannel unicastAddress : iPAddress :

              {

                network '00000000'H,

                tsapIdentifier 0

              },

          mediaControlChannel unicastAddress : iPAddress :

              {

                network '00000000'H,

                tsapIdentifier 1

I see a bug that is for old IOS and explains this behaviour (although you are not usin POTS for PSTN)

CSCdv43814 Bug Deta
ils
VOIP leg MOH stream not played out to POTS leg
Symptoms:
When an ipphone hooked to a Call Manager user places a PSTN caller on hold, the
PSTN caller does not hear the MOH stream even though the stream is delivered to
the IP interface of the router. Here is breakdown of problem :
- Call Manager has an active GW to IP Phone call up.
- The IP Phone places the GW on hold.
- Call Manager then sends an EmptyCapabilitySet to the GW.
- The Call Manager is then connected to MOH.
- The Call Manager sends an OpenLogicalChannel on behalf of the IP Phone,
meanwhile the GW sends an OpenLogicalChannel to the Call Manager.
- The GW sends an OpenLogicalChannelAck to the Call Manager with a valid
RTP address.
- The Call Manager sends an OpenLogicalChannelAck to the GW with
IP=0.0.0.0, Port=0. The reason here is that Call Manager is unable (by
design) to open an in-bound stream on the MOH. So, it just reports back a
null RTP address.
- The GW user doesn't here music.

Conditions :
This is observed on all Cisco Gateway with Cisco IOS rel 12.1(5)YD3 code as
well as on XB branch. This problem is not present in mainline rel Cisco IOS rel
12.2(3).

Workaround:
None if SRST functionality is required. Otherwise use release Cisco IOS
rel 12.2(3)
My suggestions for test purposes)
1. Ensure the h323 gateway has MRGL with Moh server in it
2.on the h323 gateway (select use MTP) (ensure there is MTP in the h323 gateway MRGL)
Test again
Options 2
3. Upgrade your IOS
4. Change h323 gateway to SIP..so that you have a sip to sip call flow
Let me know whic options you had like to try..The first ones look easy enough to try..may be you should give it ago

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

wrerase.reload Wed, 03/06/2013 - 01:48

Thank you again! I will go onsite tomorrow and try some options. I will start with option one and then move to changing the trunk to SIP. The bug matches the symptoms exactly except that we are running ver 15.1. The symptom does not happen with the calls across the pots dial peers, so I will leave the upgrade as a last option.

Will keep you updated.

Regards

Pieter

wrerase.reload Fri, 03/08/2013 - 21:57

Almost there!

I decided to do the SIP trunk fro mthe Call Manager to the CUBE as you recomended. If I dial from internal to external, MOH works however, not in the opposite direction. Dialing from external to internal does not have MOH working. I did add the MTP resource from the IOS to the MRGL of the SIP trunk and selected "use MTP"

Send some debugs to your email account if you have a moment? Would be appreciated

Regards

Pieter

Ayodeji oladipo... Sat, 03/09/2013 - 13:54

Pieter,

I have been travelling, hence the reason for my late response..I was looking at your logs at brussels airport

The failing call is still doing h323 to sip. The call is matching dial-peer 20 voip..which is a h323 dial-peer. You can just remove this dial-peer and leave only dial-peer 21..and it should be fine.

Have you tried MOH with sip to sip configuration without enabling MTP. Please try that and see if it works and let us see if we can remove MTP..Send me the logs once you remove the MTP. You can send the logs directly here (the forum attachment is working now)

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

wrerase.reload Mon, 03/11/2013 - 18:50

Thank you,

It is working now. The challenge was getting this going with the existing h323 environment for testing. I really appreciate your input. This is working using the MTP (which I will play around with to see if it makes any difference). Couldn't remove the dial peer as still required to translate patterns.

In short incase others read this, the golden rule I learned when using SIP trunks to ISP:  Avoid CUCM - H323 - Cube - SIP - ISP. It should be CUCM-SIP-CUBE-SIP-ISP. It just saves a ton of troubleshooting (no matter what the customer wants).

Cheers and thanks for making the support community a place collaborate!

Pieter

Ayodeji oladipo... Tue, 03/12/2013 - 04:06

Pieter,

I am glad I could help. The support forum is the best..we all make it what it is..Make sure you come back..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Actions

Login or Register to take actions

This Discussion

Posted February 21, 2013 at 10:37 PM
Stats:
Replies:21 Avg. Rating:5
Views:1481 Votes:0
Shares:0
Tags: cube, moh
+

Related Content

Discussions Leaderboard

Rank Username Points
1 21,031
2 15,047
3 10,318
4 8,004
5 4,856
Rank Username Points
124
95
93
62
56