Jabber call statistics

[Essam Butt]

Hello,

we are facing one-way audio issue, so would love to understand what these statistics mean.

Can anyone help interpret these?

Thanks

[Roger Kallberg]

You don’t receive any traffic and it looks like there is no codec negotiated on the receiving part of the call.

 

[Essam Butt]

Thanks for the reply.

But from the traces, I can see that g711u is negotiated:

v=0
o=CiscoSystemsCCM-SIP 5109996 1 IN IP4 130.x.x.x
s=SIP Call
c=IN IP4 130.x.x.x
b=TIAS:64000
b=AS:64
t=0 0
a=cisco-mari:v1
a=cisco-mari-rate
m=audio 19670 RTP/AVP 0 101
a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 What else could be the reason for one-way audio?

[b.winter]

Have you ever thought about, that something is blocking the traffic in one of directions? Firewalls tend to do that.
Successful codec negotiation has nothing to do with the packet traffic itself. A codec cannot influence if a packet is dropped somewhere or not, just because it's not related to each other.

[Essam Butt]

Hi, Thanks for your reply.

Actually, that was our initial guess. We did check our firewalls but we could only see SIP packets (which were allowed) but couldn't find any RTP packets hitting. We then check our routing but as per the ACLs, all traffic is allowed to pass from our CUBE to CUCM.

We couldn't find any error in SIP traces, so not sure what else to check.

[b.winter]

Per default, RTP packets aren't flowing between CUBE and CUCM, or CUCM and the endpoint. So it's normal, that you don't see them in the FW with a filter of CUBE <--> CUCM.

RTP packets are flowing directly between the endpoints. (e.g. Phone <--> Phone, CUBE <--> Phone, ...). CUCM isn't involved in the RTP stream (per default).

Get the IP's of the Jabber and the other endpoint and check the routing / FW in that path.

SIP Traces won't give you and clue, when having problems about media. That's why they are called SIP traces and not RTP traces. Just because SIP is working, doesn't mean RTP is working.

[Scott Leport]

Hi,

It would be helpful if you could describe the call flow which relates to the one-way voice issue. From the info you've supplied, it's a call being made from Jabber, but where is it you're calling to? Is it another site on the same CUCM or is it on a different CUCM cluster? Is it happening on calls to the PSTN? If it's the former, can you have the person at the remote site call you? If so, what are the results? Also, if it is on-net to a different site or CUCM cluster, what role does the CUBE play in all of this? 

As already mentioned, RTP is formed between the endpoints. The only time CUCM would be used in RTP is if you had the Media Termination Point option checked on your SIP trunk settings. If you're not seeing RTP packets in your firewall traffic logs filtering on your CUCM IP, that doesn't sound like what's happening here. 

Commonly, the cause of one-way audio is RTP port ranges being blocked on the firewall, IP routing / reachability issues or NAT.

Start checking on these items first. 

[Essam Butt]

Thank you all for your replies. They all were really helpful in resolving this issue.

As I was told, our FW was not advertising specific routes, hence the RTP packets could not reach or even be seen by our FW.