11-18-2012 10:25 AM - edited 03-16-2019 02:15 PM
Dear All,
Hope you are all doing well,
I need your kind support and advices regarding the below setup,
CM ====>> WAN ======>> SIP server (the call successfully incited and you can hear the voice clearly from IP phone to mobile, but you cannot hear the voice form the mobile to IP phone)
SIP server ======>> WAN ======>> CM (cann't recieve incoming call)
Please Help,
Thanks in advanced,
Ahmed
Solved! Go to Solution.
11-23-2012 12:41 AM
Also, I went through the SDI trace you attached. There are no SIP calls in it. Looks like you didnt get it right :-) Please try with the help of the document I provided. Let me know how it goes.
Regards,
Harmit.
11-18-2012 10:37 AM
Please post a copy of your sh run results.
I am haveing a simular problem. My outbound calls to landlines and mobiles work great. My problem is I cannot get SIP inbound calls to work at all.
11-20-2012 12:23 PM
After lots of digging around, we found a solution (for me).
I am running IOS 15.1-4 and there seems to be a new command in it called TRUSTED IP LIST that is turned on by defualt. I am not sure if the command is new or that is is on by defualt. Anyways, once I added the IP address (it will NOT accept a DNS address), my calls started coming in.
Thanks so much to Soct B at Net Cert Labs.
11-21-2012 08:06 AM
Hi Michael,
Many thanks for your reply,
I'm very happy that al last I found some one has the same setup ,
I found the Trusted IP List at:
System > Service Parameters > Cisco Extension Mobility > Advanced
I add the SIP server IP address to the trusted IP list,
but still I have the same problem that I had one way audio, from IP phone ======>> WAN ====>> SIP ====>> GSM
please advise,
Thanks in advanced,
Ahmed
11-21-2012 08:21 AM
Hi Ahmed,
I think what Michael was referring to was the Toll-Fraud prevention feature is IOS 15.1(2)T onwards:
https://supportforums.cisco.com/docs/DOC-12228
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml
Can you check the same to see if that is causing the issue?
HTH.
Regards,
Harmit.
11-21-2012 09:33 AM
Dear Hrmsing,
Many thanks for your reply,
I need to bring something to your mind that I don't have a voice gateway so where to execute this command in the call manager 8.5 ?
thanks in advanced,
Ahmed,
11-21-2012 09:48 AM
Hi
Where did you connect the ISP modem
Or you have created a sip trunk to the cucm pointed to a sip server and teh cucm is open in the internet
11-22-2012 11:49 PM
Hi Chrysosto,
Many thanks for your reply,
I used the SIP trunk through WAN,
Best Regards,
Ahmed,
11-21-2012 10:08 AM
Hi Ahmed,
Can you please collect the following for on such test call where you experience one way audio:
++ detailed UCM SDI/SDL traces from all nodes in the cluster with SIP Stack and SIP Call Processing boxes checked. Please gather the traces for about 10 minutes.
++ "show network cluster" output from the Pub CLI.
++ Call details such as calling party, called party numbers, timestamp of the test call, IP phone MAC Address and IP address, IP address of the SIP server.
++ IP Phone model, phone load and exact UCM version.
Also, is there a firewall between the IP phone and SIP server? Do you see RX and TX count incrementing when you press ? twice on the IP phone? Did you try doing a trace route from the switch where the IP phone is connected to the far end SIP server and vice versa? Is the path the same for both directions? Are you able to ping both ways?
Please upload this data and I'll review it to see what's going on.
Regards,
Harmit.
11-22-2012 03:01 PM
Dear Hamsing,
I'm really grateful for your reply,
I tried my best for the last day to complete what you ask for,
so please find the information below,
- Regarding the SDI/SDL please find the attached for the Call Manager, I used RTMT real time monitoring tool 8.7,
- admin:show network cluster
10.114.14.10 cm01dc Publisher authenticated
- Calling Party = 9.!
- Called party numbers = all international numbers,
- IP phone MAC address and directory number (F47F35A363E9 / 1045 )
IP phone IP address = 10.114.35.55
- SIP Server IP address: 66.152.187.165 (sip1.catiphone.com)
Phone Type
Product Type: | Cisco 7945 | ||
Device Protocol: | SCCP | ||
Active Load ID | SCCP45.9-1-1SR1S | ||
- UCM version
Cisco Unified CM Administration
System version: 8.5.1.10000-26
- The Trace Route from the CM to SIP server (the SIP is ping able and vise versa)
ping result:
C:\Users\yassin.admin>ping 66.152.187.165
Pinging 66.152.187.165 with 32 bytes of data:
Reply from 66.152.187.165: bytes=32 time=280ms TTL=51
Reply from 66.152.187.165: bytes=32 time=284ms TTL=51
Reply from 66.152.187.165: bytes=32 time=278ms TTL=51
Reply from 66.152.187.165: bytes=32 time=278ms TTL=51
Trace route result,
C:\Users\yassin.admin>tracert -d 66.152.187.165
Tracing route to 66.152.187.165 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.114.14.252
2 <1 ms 13 ms 39 ms 109.224.3.209
3 11 ms 19 ms 7 ms 91.142.63.11
4 9 ms 31 ms 8 ms 192.168.250.2
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * 228 ms 134.222.105.168
9 297 ms 140 ms 148 ms 134.222.225.229
10 201 ms 279 ms 136 ms 134.222.231.178
11 125 ms 212 ms 265 ms 134.222.249.70
12 352 ms 360 ms 346 ms 89.149.185.222
13 274 ms 456 ms 284 ms 173.241.129.46
14 344 ms 467 ms 422 ms 69.27.173.70
15 362 ms 365 ms 317 ms 208.64.231.5
16 294 ms 273 ms 279 ms 66.152.187.165
Trace complete.
The SIP company provide me with trace route from their side to CM,
traceroute to 109.224.3.212 (109.224.3.212), 30 hops max, 40 byte packets
1 66.152.169.1 3.821 ms 3.760 ms 3.955 ms
2 208.64.231.6 0.689 ms 0.677 ms 0.661 ms
3 208.172.38.5 0.360 ms 0.573 ms 0.562 ms
4 208.178.58.221 3.520 ms 3.503 ms 3.480 ms
5 67.16.132.213 0.456 ms 0.432 ms 0.407 ms
6 67.16.165.29 148.261 ms 148.326 ms 148.303 ms
7 67.16.145.242 148.778 ms 166.487 ms 148.736 ms
8 159.63.21.54 270.627 ms 270.612 ms 270.831 ms
9 86.51.2.154 236.312 ms 236.500 ms 236.282 ms
10 * * *
11 80.90.173.162 262.409 ms 261.523 ms 261.673 ms
12 91.142.63.16 261.380 ms 261.280 ms 261.245 ms
13 109.224.3.210 355.736 ms 292.999 ms 288.803 ms
14 109.224.3.212 289.295 ms 286.747 ms 286.262 ms
- Yes we have a firewall, please see my design below:
UCM ======>> Core Switch =====>> Juniper Firewall ====>>> WAN ======>> SIP server
Many thanks in advanced for your great effort,
Message was edited by: ahmed bishry
Message was edited by: ahmed bishry
11-23-2012 12:32 AM
Hi Ahmed,
Thank you for the detailed info. Since you've mentioned Juniper, the following kb article would be worth reviewing:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB18226
Secondly, to troubleshoot this, we need the following:
1> UCM SDI and SDL detailed traces. Here is a link on how to configure the traces on the UCM admin page:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094e89.shtml#calm
Please ensure the default trace parameters are enabled and trace level is set to detailed. Also, ensure you check "Enable SIP Call Processing Trace" and "Enable SIP Stack Trace". Please make sure you disable this once the testing is completed and the logs are gathered as it is resource intensive.
2> Packet Capture from UCM Publisher (since there is only one node). You can SSH into the Publisher and run the following command:
utils network capture file capture count 100000 size all
You can do a Ctrl+C to stop the capture. Collect the same using RTMT.
Note:
++ Both UCM traces and packet capture should be collected for the same test call.
++ First replicate the inbound call failure and gather the calling party number (ANI), called party number (DNIS), timestamp of the test call, IP address and MAC address of the IP phone you are testing with (If it is the same as you provided earlier, you can ignore this)
++ Lastly replicate the one way audio issue for outbound calls with the same details as requested above.
HTH.
Regards,
Harmit.
12-05-2012 10:49 AM
Dear Harmit,
Many thanks for your kind effor,
Please find the last update about this issue,
Problem description
===================
one way audio for external calls.
issue is when the invite is sent from cucm to the sip provider the invite is getting Nat but the SDP information is not getting Natted so we need setup sip inspection on the firewall that will also change the sdp information on the packets that are being sent out .
The ip that is being sent out is a non routable ip for the provider that is the reason why the provider is not able to send the packets to us.
Below is the field that we need to be changed.
ACK sip:009647901900532@66.152.187.165:5060 SIP/2.0
Via: SIP/2.0/UDP 10.114.14.10:5060;branch=z9hG4bK2f4fd5f4e7
From: <>19145957544@10.114.14.10>;tag=12073~a93bc389-307c-4daf-991a-a8dc95023ef6-28565086>
To: <sip:009647901900532@66.152.187.165>;tag=as20078565
Date: Thu, 29 Nov 2012 21:46:09 GMT
Call-ID: 2e256c00-b71d7a1-1a-a0e720a@10.114.14.10
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 234
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.114.14.10
s=SIP Call
c=IN IP4 10.114.14.5
t=0 0
m=audio 24612 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
The highlighted fields tells the provider the ip were it needs to send the ftp packets . Being in a public network the provider will not be able to route it.sip inspection will be able to fix the issue.
Thanks and regards,
11-23-2012 12:41 AM
Also, I went through the SDI trace you attached. There are no SIP calls in it. Looks like you didnt get it right :-) Please try with the help of the document I provided. Let me know how it goes.
Regards,
Harmit.
11-30-2012 01:25 PM
Hi Hamit,
Hope you are doing well,
It was a litel while when we have last conversation, sorry for being late I was sick,
Please find the last attached files contain the SDI and SDL of the call manager,
I'm using the same IP phone to do the tests,
I also used the Juniper Firewall artical and I excute the Command on the Juniper firewall,
But unfortuantly I'm still facing the same issue,
Thanks in advanced,
12-19-2012 01:50 PM
Dear Harmit,
It has been a long time since we talked together regarding thins issue,
I'm happy to inform you that this case has been solved by two actions below:
1- Enable the MTP on the SIP trunk
2- Do an inspection NAT on the juniper firewall,
Many thanks for your great advices
Really I appreciate all your effort and advices,
Ahmed,
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