Note: Cisco Unified Communications Manager only uses 24576-32767 although other devices use the full range Real-Time Protocol (RTP), Secure Real-Time Protocol (SRTP) 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.Īnother common issue is that the RTP ports are not open or explicitly blocked, so check the following: Policy-map global_policy class inspection_default * Once you know what's the policy-map then enter the policy-map config: Policy-map global_policy class inspection_default inspect sip 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:ĭisabling SIP / SCCP inspect on Cisco ASA 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. 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 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. If this is a Jabber softphone you can start a call and press Crtl+Shift+s to get the RTP statistics On the other end you should see the same information reversed: 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. 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. * 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. How to check really quick if the phones are sending / receiving RTP (audio). * 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 being misrouted, (by a route recently added / learned, or a VRF or WAN) * RTP traffic is being blocked or consumed by a FireWall, (FW), or another security device. Now, the possible causes for these issues are: * 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. * 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. * 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. * The call agent indicates Phone B that there is an incoming call from Phone A. * The call agent, (CUCM, VCS, CME, or another PBX), receives a request from Phone A indicating that it wants to call Phone B. * OK, so here is a high level description of how this works: 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. So, first of all, you may get reports from end-users about one way or no way audio or maybe "ghost calls". If you are experiencing one-way or no-way / no audio issues, here is what you need to do to fix that easily.Īlso check and bookmark the main page of these 'how to' series which is continuously updated with Unified Collaboration Resources.Ĭnuche's One Stop, Unified Collaboration Tech Resources - Continuously updated.Ī 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.Ī 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.īefore you start thinking about fixing that, you need to understand what is going on, how does it works, and what causes this problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |