WireShark RTP Player

Troubleshoot RTP issues with WireShark when using Jabber or IP Communicator

This was an interesting one that I wanted to document. We have our agents and supervisors on either VDI Jabber or Windows Jabber or CIPC and we could not get silent monitoring to work. When the supervisor activated it everything looks correct, but there was no audio for the supervisor while the agent and caller had no issues. Supervisor could then barge in to the call and audio would work just fine. Here are the steps we took to troubleshoot this.

  1. Get the IP addresses of the agent and supervisor device. Then get a packet capture of both end points while performing silent monitoring.
  2. Using this filter get all the packets coming from the other device to your computer: ip.addr == {other parties IP}. You should see a good bit of UDP packets. At this point if you don’t see any packets coming from the other endpoint you know that more than likely the network or far end device configuration is at fault as your device didn’t send or receive any RTP.
Wireshark Packet Capture

Wireshark Packet Capture

3. Click click on any of the packets Decode As… Set Current to RTP.

WireShark Decode Packets

WireShark Decode Packets

4. All your previous UDP packets should now be RTP packets.

WireShark Decoded Packets as RTP

WireShark Decoded Packets as RTP

5. Go to Telephony > RTP Streams and Analyze the stream that is detected. You will then be able to Play Streams to confirm you get the expected audio.

WireShark RTP Stream Analysis

WireShark RTP Stream Analysis

6. Confirm audio stream is correct.

WireShark RTP Player

WireShark RTP Player

At this point we’ve confirmed our device is getting RTP, but our soft phone isn’t playing it. So a likely culprit could be the Windows firewall. Using your favorite text editor go to c:\Windows\System32\LogFiles\Firewall and open domainfw.log and publicfw.log. What you want to look for is the IP of the other device and see if you see any drops.

2020-01-01 12:03:48 DROP UDP {RemoteIP} {LocalIP} 17488 24576 200 – – – – – – – RECEIVE

If you look at the port this was received on you’ll notice that it is the RTP range Cisco recommends to have open. So at this point you can disable the firewall, which I don’t recommend, or create a new firewall rule and add UDP ports 16384-32767 as allowed.

~david

CTIOS Error 10125

PeripheralErrorCode:10125 AgentID:1000 UniqueObjectID:agent.5000.1000
     MessageID:eControlFailureConf MessageType:eSetAgentStateRequest
     ErrorMessage:IPCC Error [10125]You have attempted to log into an invalid
     instrument.  If you think it is correct there could be a configuration error.
      Otherwise, check the number and try again. FilterTarget:agent.5000.1000

I recently ran into this error and for the life of me could not figure out what was wrong.  So, the first thing I did was make sure it was happening on more than one PC, check.  Next, checked if it was happening with more than one phone, check.  Next, check if it happens with both PGsā€¦ this is where I noticed that I could login to one PG, but not to the other.  Which then lead me to check the configuration of both PGs and found that the PG configuration for the PG where the login was failing had an agent extension of 7 digits instead of 10 digits.  Thus why CTIOS was rejecting my login to a phone with an extension with 10 digits.

Presto!

~david

Cisco Unified CallManager… err Communications Manager

So, lately I’ve been playing around with CUCM (yes, that’s the new name) 5.x. First, the OS installation is very sleek and works like a champ in VMWare. Something which was never very easy with Windows 2000 as the underlying OS. Finally, upgrading is very easy to do and it seems to work great too. Here is a screen shot of an upgrade from 5.1.1 to 6.0.1. So far so good.

~david

CUCM 5.1.1