Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

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

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,

 

2 ACCEPTED SOLUTIONS

Accepted Solutions

Can you attach "debug ccsip

Can you attach "debug ccsip message" from the VG.

Brian,Here we aren't taking

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.

 

 

22 REPLIES

Can you attach "debug ccsip

Can you attach "debug ccsip message" from the VG.

New Member

Thanks very much for that.

Thanks very much for that. Please find attached output for debug ccsip message from the VG.

 

Regards,

Hi,As per logs moh was played

Hi,

As per logs moh was played by 10.101.130.10 server on port number 4000 when ever phone is keep on ringing until it hits the CFNA timeout.

 

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

 

So i would first check any blocking set on VG with that port number and IP address. Then i will packet capture VG inside interface towards CUCM to check whether the stream was reached at VG or not.

 

Please check these first and let me know.

New Member

Thanks again for that. 10.101

Thanks again for that. 10.101.130.10 is the CUCM subscriber where end-points on that site register. There is no filtering between CUCM and VG but when I try to capture it using an access-list, I have no hits as yet.

 

I will check again in an another way to confirm. Thanks.

 

Regards,

New Member

Hi,More checks have been done

Hi,

More checks have been done to confirm but I could not verify this. Have also done NMap scan but port 4000 was not in open list (both TCP and UDP). Have also check on VG using an access-list but there was no hit at all.

 

Music-on-hold is there though when the test call was put on hold.

 

Would you be able to explain why I am seeing '401 Unauthorized' in CUCM trace for the test call please? I should also mention that both of our CUCM and CUC servers are on dual-stack IPv4 and IPv6 but VG has only IPv4.

 

Thanks again.

Regards,

Can you please send debug

Can you please send debug ccsip message for an inbound call direct to an extension which is forwarded to other extension by CFB/CFNA , where caller hears ringback tone. Just wanted to compare those sip messages.

It may be picking up random port on different - different calls , so sticking to 4000 might not give you any result. What you need to check is the hit from 10.101.130.10 on inbound interface of VG through wireshark.

 

As far as 401 error is concerned we need complete sip message exchange to confirm why this error is generating , you need to set cucm trace to detail level with all the default selection.

 

New Member

Thanks for that. I have done

Thanks for that. I have done a test call as advised - a direct call to an extension which redirect to other extension by CFB/CFNA. Please find attached output of debug ccsip message.

 

Even with this, I just become aware that the ringback seems to go silent (maybe  time out?) after about 5 rings in all five sessions as traced, as in RTMT screenshot.

 

Regards,

Can you enable early offer

Can you enable early offer from sip profile applied to the trunk between VG and CUCM.

 

Again collect logs and send across.

New Member

Thanks very much again. I

Thanks very much again. I have enabled early offer in the SIP profile and the trunk has also been restarted.

 

Please find attached logs. It is a direct call to an extension as last time and the ringback tone went away after about 5 times for five sessions.

 

Regards,

Can you please collect CUCM

Can you please collect CUCM traces of all the nodes for the call going through CUC . Do mention the time of the call.

Thank you.

New Member

Sorry for the delay. Please

Sorry for the delay. Please find attached traces for the last test call. The time of the call was Jun 20 21:14 WAST.

 

Thanks again.

It is a direct call to an

It is a direct call to an extension as last time and the ringback tone went away after about 5 times for five sessions. - As 180 Ringing message sent by CUCM does not contain SDP parameters so its a responsibility of Telco to play ringback tone to the caller. I think you will not hear silence and the ringback will play as per timer set on each dn cfna if you call from an extension to 7404.

 

Now moving back to the main question , this trace is only for the direct call , i need cucm traces for the call which goes through the call handler . I want to look at the moh registered with 10.101.130.10 server and its function.

New Member

Thanks again for your

Thanks again for your assistance.  I have simulated a test call via a test call handler that just has been created.

Calling number: 0467784687
Called number: x7477 (Via Test Call Handler)
Time: 14:10 WAST

 

Please find attached CUCM trace. Early offer support in the SIP profile was disabled as it was giving some issues. Or should I create a specific SIP profile with early offer just for that site?

After looking at ccm traces i

After looking at ccm traces i can tell you that moh was initiated and played by 10.101.130.10 on port number 4000.

 

14:10:47.488 |AnnDControl - RemoteIpAddr: 102730a (10.115.2.1) RemoteRtpPortNumber: 31050 msecPacketSize: 20 compressionType: 4|2,100,230,1.180158^10.115.2.1^*

14:10:47.488 |AnnDControl - star_StationOutputStationStartAnnouncement ConferenceID: 34735431, TCPPid = [2.100.13.709911] myIP: a82650a (10.101.130.10)|2,100,230,1.180158^10.115.2.1

 

You certainly need to scan your network's route path from 10.115.2.1 to 10.101.130.10 on port number 4000. Unless we ain't  sure that stream reached inside interface of VG , we cannot point it to the Telco.

 

Few more test you can do and let me know the behavior.

1. Add MOH server in the MRGL assigned to the SIP trunk.

2. Enable "MTP Required" on the sip trunk between CUCM and VG.

 

You can disable early offer.

New Member

Hi Manish,Thanks again for

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,

 

but would the ringback tone

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

 

   

New Member

Thanks again, Manish. Sorry,

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,

You need to run packet

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.

Ringback is played by

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.

Brian,Here we aren't taking

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.

 

 

New Member

Thanks very much to both,

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,

Did you get any output from

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

869
Views
45
Helpful
22
Replies
CreatePlease login to create content