06-17-2014 07:21 PM - edited 03-16-2019 11:08 PM
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,
Solved! Go to Solution.
06-18-2014 12:16 AM
Can you attach "debug ccsip message" from the VG.
06-26-2014 01:21 AM
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.
06-18-2014 12:16 AM
Can you attach "debug ccsip message" from the VG.
06-18-2014 10:37 PM
06-19-2014 12:52 AM
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.
06-19-2014 02:20 AM
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,
06-20-2014 02:15 AM
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,
06-20-2014 04:36 AM
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.
06-20-2014 05:32 AM
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,
06-20-2014 05:46 AM
Can you enable early offer from sip profile applied to the trunk between VG and CUCM.
Again collect logs and send across.
06-20-2014 06:32 AM
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,
06-20-2014 08:39 AM
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.
06-21-2014 02:45 AM
06-21-2014 04:49 AM
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.
06-22-2014 11:31 PM
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?
06-23-2014 04:47 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide