Inter-Inter Cluster SIP Trunking and MoH

[leighharrison]

Hi all,

I have a cusotmer with a setup that runs as follows:-

SIPGW -> CM11 -> CM7A and

SIPGW -> CM11 -> CM7B

All links betweek SIPGW and CM's are SIP.  All handsets are SCCP.

When a call comes in from SIPGW for a phone registered with CM7A, all calling works fine and putting a user on hold gets MoH just fine.

When a call comes in from SIPGW (the same one) for a phone registered with CM7B, all calling works fine, but putting a user on hold gives back silence, resuming the call works fine.

What we have been able to diagnose is that when a call comes in on CM7A, the MoH source is an resource on CM7A.  When CM7B puts a user on hold, it is CM11 that offers the MoH resource.

All SIP trunk config is identical on both CM7A and CM7B.  Where else should we be looking?

Best, Leigh

[Chris Deren]

make sure the MRGL/MRG assigned to the SIP trunk on the 7B cluster (ingress) is correct with proper MOH server listed. MOH server from 7B will be used if a phone on this cluster presses hold button, and the source file from the phone placing the call on hold will be played.

Are you using Multicast or Unicast MOH?  

[leighharrison]

Hi Chris, thanks for the reply,

A bit more info:-

o We're using unicast MoH.

o There's a different SIPGW (let's call him SIPGWB) from a different vendor, also going into our V11 and we get 100% hit rate on this one for both rining and MoH on boht 7A and 7B CUCM's.

o The MRG/L on 7B is the same for both SIPGW's (as it's the V11 SIP trunk in that we traverse).

I read that if a call comes in via V11 through to 7B, that the phone on 7B putting the user on hold would invoke a resource on the V11 cluster to play the MoH?

(https://supportforums.cisco.com/t5/collaboration-voice-and-video/inter-cluster-music-on-hold-moh/ta-p/3162896)

From this, I'm expecting that V11 who takes the initial call, should be providing the MoH service which makes me a little perplexed as to which cluster should be providing the service and which is, what are your thoughts?

 Best, Leigh

[leighharrison]

Slight update:-

It appears that I was wrong about the 7A cluster offering the MoH resource, after reading through one of the ACK messages:-

User-Agent: Cisco-CUCM11.5
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence, kpml
Session-ID: cecb8d1d30c42e337476fb3ab4580348;remote=4999bce908fdb9a69add082ab4580347
Content-Type: application/sdp
Content-Length: 240

v=0
o=CiscoSystemsCCM-SIP 4580347 4 IN IP4 10.156.102.52
s=SIP Call
c=IN IP4 172.16.184.10
b=TIAS:64000
b=AS:64
t=0 0
m=audio 26750 RTP/AVP 8 101
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

The device in the "c=IN IP4 172.16.184.10" is a hardware gateway the looks to be transcoding..

Best, Leigh

[leighharrison]

Hi all,

After more testing, it appears that the non-working MoH is streamed from an transcoder.  I can see the session here:-

67390413   34057233     xcode recvonly g711a   39466 0     0.0.0.0
67390413   34057232     xcode sendrecv g711a   39702 54102 172.16.221.215

67390413   -          657509     N/A     N/A        rfc2833_pthru     transmsp  All RTPSPI Callegs      N/A                     N/A                       N/A
                      -          -          -

67390413   34057233   657510     g711a   20         rfc2833_pthru     rtpspi    (340115,657509)          N/A                     N/A                       0
                      42730497   16777216   -

67390413   -          657509     N/A     N/A        pthru_report      transmsp  All RTPSPI Callegs      N/A                     N/A                       N/A
                      -          -          -

67390413   34057232   657508     g711a   20         pthru_report      rtpspi    (340114,657509)          N/A                     N/A                       184
                      42730497   16777216   -

what circumstances would cause the CM to invoke a transcoder to go from g711a to g711a?

Best, Leigh

[Ayodeji Okanlawon]

You should check the device pool your MOH server is assigned to, what is the region relationship between MOH servers, your phones and the codec advertised for MOH.

To dig further  on why xcoding is happening, you can attach cucm logs and we will see why..but you should look at the above..

[Chris Deren]

Transrating, make sure your packetization sizes are consistent end to end.