Hi, I have an issue where intermittently I am not receiving audio on incoming calls from a particular VoIP provider. When I analyse the pcap files, I see the RTP stream comes in and the stream is made up of 1200+ packets, but when I decode the stream there is no audio received from the SIP provider. This is the same across codecs and is not limited to one particular codec or caller. One thing that does remain the same though is this only ever happens with calls from customers that are using the same SIP trunk provider - but it is an intermittent issue. My SIP provider is telling me this is a firewall issue on my side, but can that be the case? It is possible that my firewall is removing the audio from the RTP packets sporadically? I cannot see how this can be? Has anyone seen this before and is there any way I can determine what is going on here? My SIP provider has requested I run a pcap from the WAN side but given my setup and the location of the PBX this is going to be a bit of a nightmare. Thank you in advance. Jonathan. asked 24 Feb '16, 10:44  jonathanbaird edited 24 Feb '16, 11:09 |
One Answer:
It sounds weird for several reasons:
Can you publish a capture of the "silent" RTP? A whole call including the SIP messages would be better but I can imagine there may be a privacy issue. answered 24 Feb '16, 11:02  sindy |
Hi,
Thanks very much for your response. I agree with you, I cannot understand how the firewall is stripping the audio at all, but maybe I am overlooking something.
I cannot really publish this unfortunately due to the nature of the business from which the call originated. I have a pcap with 3 calls from the same company on. The first 2 calls we do not receive audio, however on the third call we do.
The fact that this only happens with calls from "SIP Provider A" to calls to us also using "SIP Provider A" surely points to an issue at their side - unless I am misunderstanding this.
Just out of interest, what part of the packet would the firewall have to modify to remove the audio from the RTP packets, would it be the payload?
Jonathan.
There are many things about which an RTP receiver may be (and should be!) sensitive about. So rewriting the payload may be the reason of the issue, but also the timestamps or ssrc may be broken, and it is also enough to change the "payload type number" so that it identifies another codec and the receiver then expects something else than it receives. Due to the nature of the individual codecs, PCMA and PCMU receivers usually translate any incompatible payload into a noise (sometimes a loud one!), while compressing codecs usually translate it into silence.
Actually, even timing may be the reason, most RTP receivers go mad if packets come in bursts rather than in regular intervals as they should.
If you could post about ten received RTP packets of a "good" call and ten of a bad call, and the SDP exchange for both as text (I don't care about calling and called numbers, so the SDP is enough, not the SIP packet carrying it), I might see what is wrong. One packet is not enough, more than ten are not necessary.
Do you know whether the remote (calling) party can hear what your colleagues say, or whether the silence is bi-directional?
When you say you see the RTP packets, where are you capturing it specifically in relation to the firewall? Is it after the firewall saw the packet, or before?
Further, what is the configured logic of the firewall for VoIP? What I mean is, traditionally with VoIP you have the concept of firewall "ALG" or pinholing, where the system looks at SIP packets containing SDP and, based on that content, sets up RTP rules. If that is the case, and this issue is intermittent and following a particular SIP trunk provider, it could be that there is a logic error in the SIP ALG process on the firewall such that selective streams are not getting through. That is something which very much can happen.
@Quadratic, I've got a bit of hands on experience with @jonathanbaird's capture in the meantime.
The affected RTP streams do get through jonathanbaird's firewall normally (so no payload type policing applied) and the local SIP provider sends all RTP streams from just two source IPs which means he does some kind of media proxying. I.e. these two source IPs are not specific for the remote SIP provider which is the only source of the silent RTP streams.
The payload of a silent stream is a "digital silence", i.e. in case of PCMA, all
d5bytes without a single exception, while ssrc, seqno, RTP timestamps and frame timestamps (~ physical timing) are fine. So should jonathanbaird's firewall be guilty, it would have to:be capable of rewriting the payload by a proper silence pattern for a given codec (an odd functionality already), and
either do so intentionally for particular stream sources, but that cannot be the case because from the firewall's perspective, the source of affected and unaffected streams is the same,
or do so by mistake for randomly chosen streams, but that also cannot be the case because only streams coming from a single particular remote SIP provider are ever affected. So the choice would have to be random and systematic simultaneously which doesn't make sense.
So my conclusion is that something is broken at the interconnection path between the two SIP providers.
But I do agree with you that too many ALGs turn out to be headache sources sooner or later :-)
Understood. From that I'd agree, I know of no firewall capable of doing that.