No ringback tone on incoming call via CUC call handler call flow

[layhlaing]

Hi everyone,

I am having no ringback tone issue on incoming calls via CUC call handler in the following environment.

CUCM: 8.6.2.22900-9

CUC: 8.6.2ES44.22900-44

Integration between CUCM and CUC: SIP

End-points: Cisco 9951 SIP, Cisco 7960 SCCP, Cisco 7942 SCCP

VG: Cisco 2921 with E1/PRI with PVDM3-128

Outbound Trunk: ISDN 30 channels

Trunk between VG and CUCM: SIP

Ringback tone is there if calls were made directly to DIDs.

The call handler call flow is as this:

-> 08 9333 7401 -> CFA - voicemail -> CUC CallHandler -> No greetings during BusinessHour, always transfer -> x7404 -> CFNA/CFB -> x7411 -> CFNA/CFB -> x7412 -> CFNA/CFB -> x7413 -> CFNA/CFB -> Mobile

Attached are VG config and debug output of 'debug voice ccapi inout', 'debug isdn q931' and screenshots from RTMT for the following test call:

Calling number: 0467784687

Called number: 0893337401

There was a ring, just once, "180 Ringing" message is there, as you can see in the screenshot 'Analyze Call Diagram*' but it has gone silent after that.

Both SIP trunks between CUCM and CUC have MRG (with active Annunciator) associated and they are  'MTP required' with 'MTP Preferred Originating Codec' of g729/g729a.

The SIP trunk between CUCM and site's VG also has MRG (with active Annunciator) associated and it is not 'MTP required'.

As you can see in the VG config, our codec preference 1 is g711ulaw.

Can someone please advise on how I should approach on this issue to be resolved? Thanks in advance.

Regards,

[layhlaing]

Hi Manish,

Thanks again for your time on this. and sorry for my ignorance but would the ringback tone be initiated as MOH in this?

The packet capture on CUCM server 10.6.130.11 for this particular port 4000 with "utils network capture eth0 file packets count 100000 size all port 4000" gave me followings which is consistent to the previous CUCM trace.

Source - Destination - Source Port - Destination Port

10.6.130.15 - 10.6.130.11 - 18696 - terabase (4000)

Wireshark span monitor session on VG does not have such packet however I wonder why as there should not be any filtering.

I can hear MoH if the call is answered and put on hold.

Enabling MTP required on the SIP trunk between CUCM and VG has given me call dropping issue in the past so I am cautious with that.

Regards,

[Manish Prasad]

but would the ringback tone be initiated as MOH in this? - No because call is answered by CUC callhandler and its not in Ringing/Session Progress stage where you hear ringback tone. If you see the sip message call flow from VG it would be verified.

I can hear MoH if the call is answered and put on hold. - this might be because some other MOH server has been selected in that process ( might be from phone's mrgl or phone's DP mrgl) and it can be confirmed if you can get me debug ccsip message from VG.

Whose IPs are these ? -  10.6.130.15 - 10.6.130.11

[layhlaing]

Thanks again, Manish. Sorry, I have just edited the last post to correct the IP.

I have replicated a similar Call Handler at the site where I can capture packets on VG. I have same issue regardless of ISDN or SIP trunk. 10.6.130.15 is VG and 10.6.130.11 is CUCM. This VG also has the same configuration except from numbering plan as the one that was posted at the beginning.

Phones use DP for MRGL and they are the same in any case anyway.

Regards,

[Manish Prasad]

You need to run packet capture on 10.101.130.10 subscriber server , as from this server stream is going out.

"utils network capture eth0 file packets count 100000 size all port 4000" run this on sub 10.101.130.10 and let  me know the output.

Here we are looking for one way stream (sendonly) , so you might be able to reach 10.101.130.10 from 10.115.2.1 but not from the other way.

[Brian Meade]

Ringback is played by annunicators.

Try restarting IPVMS on all nodes in a maintenance window.

Check "show media streams" on all servers to ensure there are no call leaks.

[Manish Prasad · Accepted solution]

Brian,

Here we aren't taking about ringback tone , the call is in answered state. If you look at the cucm traces you will get to know how call was answered and moh was played.

Here is the time line from the traces...

14:10:44.570 - INVITE sent to CUCM by VG
14:10:44.590 - INVITE relayed to CUC
14:10:44.607 -Received ringing and sent back ringing to VG
14:10:44.704 -OK received from CUC and relayed to VG with media ip as 10.101.1.2

s=SIP Call
c=IN IP4 10.101.1.2
b=TIAS:64000
b=AS:64
t=0 0
m=audio 19258 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000

14:10:44.724 - ACK received from VG.

At this time call is in answered state by call handler within a second, so there is no ringback to the caller.

After looking at call forward message from CUC call handler , CUCM send back Re-Invite with media Inactive to VG to stop the media.

14:10:47.431 - Re-invite relayed to VG with INACTIVE
14:10:47.443 - OK confirmation from VG and media goes Inactive.

After forwarding to a new destination CUCM send Re-Invite to VG to activate the media.

14:10:47.465 - Re-Invite(DO)

14:10:47.487 - OK received from VG

14:10:47.489 - ACK sent back to VG with moh ip and its stream direction

v=0
o=CiscoSystemsCCM-SIP 745685 3 IN IP4 10.101.130.10
s=SIP Call
c=IN IP4 10.101.130.10
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendonly

Now from 14:10:47.489 to 14:10:59.510 moh was played as per the setting on CFNA timeout, once it hit cucm send media-inactive to VG for futher forwarding to CFNA destination.

Call goes through different- different call forward numbers with media active and inactive till it hits end destination number.

Annunciators are not playing any role in this call flow and call is going through moh server which is registered with Subscriber 10.101.130.10.

IPVMS restart can be done but again as per Layhlaing moh media is played when a normal call is put on hold.

"show media streams" can give some output which we are looking for.

[layhlaing]

Thanks very much to both, Manish and Brian. Sorry I could not get back to this as the work has been a bit overwhelming with some issues. One of the recurring issue was 'voicemail being unresponsive'. I have started a discussion about this at https://supportforums.cisco.com/discussion/12224456/voicemail-does-not-respond-cuc-862-and-cucm-862-environment but unfortunately it didn't get any attention. I am not sure if both issues are related. In my understanding, it could be related to number of voicemail ports but not sure how to confirm it.

In this no ringback tone issue, IPVMS has been restarted but I am still not getting ringback tone via CallHandler.

Regards,

[Manish Prasad]

Did you get any output from "show media streams" and "utils network capture eth0" ?