If you are experiencing one-way or no-way / no audio issues, here is what you need to do to fix that easily.
Also check and bookmark the main page of these 'how to' series which is continuously updated with Unified Collaboration Resources.
cnuche's One Stop, Unified Collaboration Tech Resources - Continuously updated.
Now, back to the no audio issues
What is it?
A one-way audio call is when you have a call between 2 phones (internal-internal or internal-external), and one of them cannot hear the other end.
A no-way / no audio call is when you have a call between 2 phones (internal-internal or internal-external), and none of them can hear each other.
How do I fix it?
Before you start thinking about fixing that, you need to understand what is going on, how does it works, and what causes this problem.
So, first of all, you may get reports from end-users about one way or no way audio or maybe "ghost calls".
Sometimes the users even refer to these as "dropped calls" because they get a call, there is no audio and after a few seconds they hear reorder tone, (fast busy), this happens because the caller cannot hear the called phone and it's getting dead air and hang up, or maybe they can hear the other end, but realize that the called phone cannot hear them and hang up.
* OK, so here is a high level description of how this works:
* Phone A calls Phone B.
* The call agent, (CUCM, VCS, CME, or another PBX), receives a request from Phone A indicating that it wants to call Phone B.
* The call agent indicates Phone B that there is an incoming call from Phone A.
* If Phone B picks up the handset or press the speaker button then the call agent will ask both phones for the port they want to use to receive audio and will send that information to the other end.
* At this point you will see that the call is 'connected', (and it is at a signalling level), please notice this is just the phones talking to CUCM or the PBX.
* Then both phones open the audio channel and start transmitting and receiving RTP packets, please notice this Tx and Rx of audio packets (RTP Packets) is a point-to-point communication between the phones, the audio does NOT go through CUCM, (unless there is an MTP or CFB from the server itself involved), in case this is an external call the audio goes directly from the phone to the ingress / egress GW.
Now, the possible causes for these issues are:
* RTP traffic is being blocked or consumed by a FireWall, (FW), or another security device.
* RTP traffic is being misrouted, (by a route recently added / learned, or a VRF or WAN)
* Signalling issues, (call agent is not passing the correct ports or codec, or the communication is tagged as 'send only' or 'receive only')
* RTP traffic is corrupted.
* One side is not transmitting
How to check really quick if the phones are sending / receiving RTP (audio).
* Open the web page for 2 test phones, then click the 'stream 1' link located at the left handed side of the page, and check if the IP address and port match the information on both sides, keep pressing the 'stream 1' link and you will notice that the Tx and Rx stats keep increasing.
- Here you can check the 'Local' and 'Remote' IP addresses, then you see the port, if the information is the same on the other side, ('Local' on one side should correspond to the 'Remote' on the other), then signalling is good.
- You can also check that the codec is the expected codec, if not, change the codec preference list or the available BW on the region.
On the other end you should see the same information reversed:
If this is a Jabber softphone you can start a call and press Crtl+Shift+s to get the RTP statistics
How to identify the most common issues:
- If you see the Tx stats increasing then the phones are transmitting, but you may see the Rx stats not increasing or even on '0' if one end is not hearing anything.
- What that means is that the phone is transmitting, but the other end is not receiving those packets, at this point you can stop looking for a phone system issue, that is a network issue.
-If this is happening with external calls, take a packet capture or PCM capture from the GW to see if you are getting audio from the far end.
Traffic being blocked or consumed by a FW is the most common issue, if the FW is using SIP inspect or SCCP inspect, this can cause this and other issues, in order to prove or discard this please disable SIP or SCCP inspect depending on what you are using, see below:
Disabling SIP / SCCP inspect on Cisco ASA
* First check what's the policy-map:
show run policy-map
* There you should see something like:
policy-map global_policy class inspection_default inspect sip
* Once you know what's the policy-map then enter the policy-map config:
policy-map global_policy class inspection_default
* And finally disable inspect:
no inspect sip
If that clears the issue then you may need to tune SIP inspect, (open a TAC case with the ASA security team), or leave that disabled.
Another common issue is that the RTP ports are not open or explicitly blocked, so check the following:
RTP ports:
16384 - 32767 / UDP
Real-Time Protocol (RTP), Secure Real-Time Protocol (SRTP)
Note: Cisco Unified Communications Manager only uses 24576-32767 although other devices use the full range
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_0_1/sysConfig/CUCM_BK_C733E983_00_cucm-system-configuration-guide/cisco_unified___communications_manager_tcp_and_udp_port_usage.html
If there are no security devices and you see the RTP traffic hitting a router but it is not getting to the other side, the traffic could be misrouted, if there is a VRF involved you may try disabling the VRF, or you can get packet captures of the outgoing interface to check if the traffic leaves the router on the expected interface.
If you are unsure how to get the captures from the router, see this doc:
TAC asked me for captures, now what
If this is traversing a WAN make sure you get a packet capture from the incoming and outgoing interfaces of the router and make sure the size of the incoming packet is less than the specified size for the WAN link, (this can be a problem if there is a mid-call RE-INVITE with a large SDP, that could lead to audio re-negotiation issues).
Finally, if you see the phone is receiving packets but nothing can be heard on the phone you will need to get a packet capture from the phone to further analyse the RTP stream, if the packets have the wrong sequence the phone will not play those, or if Wireshark indicates that the packets are corrupted or malformed the phone might not play them, if the RTP packets are there and you can play them using Wireshark, (G.711 unencrypted), but you cannot hear anything, those most likely are 'blank' or empty packets, that can be generated from a FW that is consuming the packets or an MTP / Xcoder device.
Here is a doc on how to collect a packet capture from the phone:
Collecting a packet capture from a Cisco IP Phone:
https://supportforums.cisco.com/document/44741/collecting-packet-capture-cisco-ip-phone
Random issue.
-If this is a random issue, you will need to setup a SPAN capture on the switch and leave a PC with Wireshark capturing until this can be reproduced, ideally you should setup the Wireshark capture with no filters, (there are filters by default, do not use them), and make sure you set the capture to create a new file every 50 or 100 MB, and get the IPs, MACs, date and time of the test, also indicate the time-zone of the device, as the time will change if you use a PC with another time-zone to check it.
Clear the default Wireshark filters (or do not use them)
Setup Wireshark to create a new file every 50 MB and keep a buffer of 15 files,(after this the files start being overwritten):
What if this is random and no captures were set for the phones that presented the issue?
- You can gather the CCM detailed traces, (those have to be enabled before this happened otherwise that info is already lost).
- On the CCM traces you can check the RTP stats for SIP or SCCP, and check if one of them is not receiving or not sending packets, note that CCM media resources like MTP do not send RTP stats.
So here is what you would be looking for on CCM traces:
This example shows a one-way audio, the call flow is SIP phone calls an SCCP phone
SIP phone relevant info is marked in blue
SCCP phone relevant info is marked in orange
Since CUCM sends the correct IP address and port to each phone, this is not a signaling / CUCM issue.
On the 200 OK for the BYE message the SIP phone sends RTP stats, SCCP phone sends a ConnectionStatisticsRes message.
This shows that the SCCP phone did not received the RTP stream from the SIP phone, this was lost on the network, this turned out to be a FW blocking the stream, this was fix by allowing the traffic on the FW.
But this could have been a FireWall not just blocking the stream but changing the headers info, (SIP and / or SCCP inspection), or it could have been an L3 device mis-routing the traffic from the SIP device, or a WAN / MPLS carrier issue.
What if a phone is not transmitting?
- If you DON'T see a phone transmitting, then get CCM detailed traces or a packet capture from the phone so you can check if the phone is receiving a 'send only' / 'receive only' SDP.
