cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

204
Views
0
Helpful
10
Replies
Highlighted
Enthusiast

Can you apply a filter to a PCM capture?

I have a very busy gateway so a PCM capture would fill up very quickly and since the calls that I'm looking for are sporadic I would like to narrow the capture down to only calls going to a specific phone and wait for one of the problem calls to come through to that phone.  Is it possible to set up a PCM capture to only capture conversations going to a specific IP?  

Everyone's tags (1)
10 REPLIES 10
Hall of Fame Master

What are you using for the

What are you using for the capture? Where is it connected or running on?

Enthusiast

It would be running on a 4431

It would be running on a 4431 ISR router that's MGCP controlled by CUCM 11.0 and has 3 PRIs to the telco.  

Hall of Fame Master

To my understanding the

To my understanding the packet capture built into the router is not meant to be running at all times, it is meant to collect traces when troubleshooting due to the CPU stress it would put on the router.  To collect traces all the time you'd want to have a network sniffer on your network monitoring the switch port that the router is connected to.

Enthusiast

We have Wireshark sniffing

We have Wireshark sniffing the router's interface but we think it's possible that the issue is happening inside the gateway.  If the gateway is causing the issue (and it's only in the outbound (to the PRIs) direction, Wireshark won't see it so we were hoping to get the PCM captures to capture what the gateway is sending out.  

Hall of Fame Master

If you suspect the issue to

If you suspect the issue to be PRI related, then packet capture will not provide anything as there are no packets on TDM interfaces such as PRI. Have you looked at debug q921 and q931? How about controller errors? What is the issue?

Enthusiast

The controller interfaces and

The controller interfaces and serial interfaces are clean.  I would say it's a PRI issue except that it's isolated to a certain set of people an nobody else who uses the same PRI gateway.   I won't go into all the details because it's a long story but here is the 10,000 ft view:

The issue is that some inbound callers hear loud beeping in their ear when trying to speak to agents.  The agents don't hear the beeping at all, only the callers.  The callers only hear the beeping when they speak.  If they are silent, no beeping.  It only happens to a small fraction of calls and if the agents calls the person back (outbound call), there is never any beeping.  


The issue only happens to a specific team of UCCX users.  That would point to UCCX except that the only time the issue occurs is once the caller and agent are speaking to each other which means a direct RTP between the agent phone and the PRI gateway.  UCCX is essentially out of the loop at that point.  I've had UCCX TAC look at debugs of bad calls and they said there was nothing unusual.  I've also had the CUCM team look at CUCM logs of the same calls and those didn't yield anything out of the ordinary as far as call control.  

That would narrow it down to possibly some kind of switch issue where that team of agents is located (same campus, different VLAN) but nobody else who uses the same switch/VLAN and isn't a UCCX person on that team has the issue so that make a switch.  

None of the other UCCX teams have that issue.  

It's as if every possible point of failure has something suggesting that it can't be the source of the issue.

Wireshark captures of the agent's phone don't show the beeping, so I don't believe it's being sourced from the agents' phones.  Working on getting captures from the gateway to see if the beeping exists before the call hits the interface on the voice gateway.  If it shows up there, something is wrong on the network.  But if it doesn't I need the PCM captures of a bad call to verify that the gateway isn't producing the beep and sending it out the PRI.  

I wish I had a way to SPAN the PRIs themselves to something but we don't have any kind of recording software in place.  That way I could see if the beep existed as it leaves the gateway but before it technically hits the telco.  

Hall of Fame Master

This is an odd one.

This is an odd one.

Can this be replicated by calling the agents directly on their DIDs (if they have DIDs if not I would assign one fore testing)

How many users have reported this? Have those users ever connected to other agents/phones and not experienced the issue? What I am getting to here is, perhaps it is the other side, handful of callers always calling to the same skill group, etc?

Have you been personally able to replicate it?

VIP Advisor

Hi,

Hi,

You can use ACL based captures to narrow down the traffic to single phone (you need to locate static IP for this phone from your DHCP server). Here is an example (you can copy the pcap file to external machine to use wireshark for analysis).


access-list 123 permit udp any any range 16384 32767
!
ip traffic-export profile CUBE_PCAP mode capture
  bidirectional
  incoming access-list 123
  outgoing access-list 123
!
interface GigabitEthernet0/0.34
 ip traffic-export apply CUBE_PCAP size 5242880
!
traffic-export interface g0/0.34 start
traffic-export interface g0/0.34 stop
traffic-export interface g0/0.34 copy

Enthusiast

So I would set it up like you

So I would set it up like you have above but add IP permits for the IP address of the phone?

VIP Advisor

Yes, you can modify the acl

Yes, you can modify the acl based on your requirement (ip and port)

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards