02-24-2014 07:05 AM - edited 03-16-2019 09:52 PM
Hi to all
we have no audio between two remote sites where both extensions registered into CUCM version 9.x
Site A use cisco jabber
Site B use ipphone
PATH:
Cisco jabber in Remote site A via ipsec tunnel--> Check Point-----> Site B with cisco ipphones via ipsec tunnel
In the HQ where is located the Check point (also cucm , cups) if the inisiator of the call is in the HQ then everything its ok
Someone from the HQ create a conference between these remote sites and everything its ok
If site A call site B and vise versa then call established succesfully but without audio (RTP)
I believe that the issue related to checkpoint but can you see something from the attached traces
I look into these traces but i didnt see anything useful about this issue
Calling ip (cisco jabber) :192.168.100.23
Called ip (ipphone): 192.168.10.7
Thank you in advance
02-24-2014 07:27 AM
Hi chrysostomos1980,
The best way to troubleshoot one way audio/dead air issues is by taking packet captures at various points on the network.
Take packet captures @
1/ IP Phones at both sites.
2/ Checkpoint
3/ MTPs (if any)
Another way of checking if the phones are behaving fine is to press the '?' button twice when the call is connected. You should see the Tx and Rx stats continuously increasing.
The CUCM traces will only show us the signaling between these endpoints and since the same endpoints work in other call scenarios/internal calls within sites, we can isolate the issue being in the network.
Thanks
Sreekanth
02-24-2014 07:47 AM
Hi and thank you for the reply
Take packet captures @
1/ IP Phones at both sites.
Into the switch of each site?
02-24-2014 08:20 AM
Yes you will need to span the switch port where the phones are connected.
Else you can enable the PC port on the phones and Span to PC port as well. Here's the doc you can refer to.
02-25-2014 04:39 AM
Thank you Sreekanth
I will take the capture and return back with a feedback
02-27-2014 11:47 PM
Hi Sreekanth
I have attached the packet capture
CUCM Ips: 192.168.1.202-203
CUPS: 192.168.1.206
source ip( ipphone): 192.168.10.8
destination ip (jabber): 192.168.100.200
Thank you in advance
02-28-2014 01:33 AM
Hi chrysostomos1980,
I think the jabber IP address is 192.168.100.20. I can see an RTP stream going from the IP Phone to the jabber. There is NO stream coming from the Jabber to the IP Phone side. That means it's being blocked somewhere in between.
"Src addr","Src port","Dst addr","Dst port","SSRC","Payload","Packets","Lost","Max Delta (ms)","Max Jitter (ms)","Mean Jitter (ms)","Pb?"
"192.168.10.8","21328","192.168.100.20","17270","0x1319EC5","g711A","5517","0 (0.0%)","39.79","0.61","0.06",""
You would need to check if there is a firewall or something else in between that is dropping the packets from the Jabber phone.
Thanks
Sree
02-28-2014 01:57 AM
Hi Sreekanth
Yes my mistake.i put one zero more.
The destination ip is 192.168.100.20.
Could you pls advice where do you see the RTP traffic?
Src addr"
,"Src port",
"Dst addr"
,"Dst port","SSRC","Payload","Packets","Lost","Max Delta (ms)","Max Jitter (ms)","Mean Jitter (ms)","Pb?"
"192.168.10.8","21328","192.168.100.20","17270","0x1319EC5","g711A","5517","0 (0.0%)","39.79","0.61","0.06",""
PS:
Customer have a checkpoint in HQ and a check point in the remote destination (192.168.100.20) to establish the vpn..
Do you have something to advice for troubleshooting?
02-28-2014 02:03 AM
1/ You will need to first filter out the packets using the ip.addr==192.168.100.20 filter. This will show you a list of UDP packets. This is actually the RTP.
2/ You will need to right-click on any of the UDP packets and click "Decode As". There will be a popup. Choose RTP as the protocol and "Both" for the traffic sides.
3/ This will decode the UDP packets into RTP. Then go to the top menu bar, where you will see "Telephony" -> "RTP" -> "Show All streams". This will list the stream for you and you will see only one direction.
You can take the packet captures at both checkpoints to see where it could be getting dropped. Maybe there is some rule on checkpoint causing this. Please see if the packets that enter checkpoint VPN on the remote side come out at the checkpoint VPN tunnel on the HQ side.
02-28-2014 02:22 AM
Another (5*) to you
Thank you so much for the detailed explanations about wireshark
PS:
I will not mark for now the discussion as an answered maybe i will need your advice again but you will take another 5 points
02-28-2014 02:31 AM
Thank you chrysostomos1980
You can reach out to me in case you have any other queries regarding this and I will do my best to help you with them.
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