SIP trunk providers emitting RTP packets containing wrong number of samples
My company (a SIP equipment manufacturer) has noticed a sudden flurry of problems related to RTP streams containing some packets with the wrong number of samples (different from what was negotiated). Our equipment negotiates 20ms packets, we're seeing the emission of a few 5ms packets with MARK bit set, before the 20ms packets start flowing. I theorized that some vendor's SBC or Media Gateway has released software that causes this. It has erupted at multiple customers. I thought there was no commonality of carrier or trunk provider, but today I heard a report that T-Mobile is definitely implicated and reproducible. Other sources are possible too. Has anyone else noticed this? Does anyone have a good contact for SIP-related matters at T-Mobile?
On 13/04/2022 21:25, Liudvikas Bukys wrote:
My company (a SIP equipment manufacturer) has noticed a sudden flurry of problems related to RTP streams containing some packets with the wrong number of samples (different from what was negotiated). Our equipment negotiates 20ms packets, we're seeing the emission of a few 5ms packets with?MARK bit set, before the 20ms packets start flowing.? ? I theorized that some vendor's SBC or Media Gateway has released software that causes this.
It has erupted at multiple customers.? I thought there was no commonality of carrier?or trunk provider,?but today I heard a report that T-Mobile is definitely?implicated and reproducible.? Other sources are possible too.
Has anyone else noticed this?
Does anyone have a good contact for SIP-related matters at T-Mobile?
I've seen something similar to this before, this year.? I can't remember exactly when or what.? (I'm usually looking at? PCAPs over somebody's shoulder when they need a second opinion.) It isn't usually a problem, I don't think.?? Worst that happens is the first few RTP packets are dropped at the receiver.? I've always presumed just a bit of a race condition between the SIP part and the RTP part.??? 5ms unusual. -- Tim Bray Huddersfield, GB tim at kooky.org
Hi,
I've seen something similar to this before, this year.? I can't remember exactly when or what.? (I'm usually looking at? PCAPs over somebody's shoulder when they need a second opinion.)
Yeah me too. It showed on a capture troubleshooting a customer problem. One of our guys tracked it down to some strange never heard of pbx that was sending rtp packets to "open" the nat ports during early dialog. Once the device received a real rtp packet it would adjust accordingly. Why on earth they were sending 5ms to start was never investigated, we just kind of shrugged and moved on as it was not creating problems. Brian
Liudvikas- If you can send me a pcap (anonymized) I can run it through our media/decoder/packet tools and probably be able to tell you what is going on. The pcap can contain multiple RTP streams, SIP, etc as long as the stream(s) of interest are in there. -Jeff Quoting Liudvikas Bukys <Liudy at bukys.org>:
My company (a SIP equipment manufacturer) has noticed a sudden flurry of problems related to RTP streams containing some packets with the wrong number of samples (different from what was negotiated).? Our equipment negotiates 20ms packets, we're seeing the emission of a few 5ms packets with?MARK bit set, before the 20ms packets start flowing.? ? I theorized that some vendor's SBC or Media Gateway has released software that causes this. It has erupted at multiple customers.? I thought there was no commonality of carrier?or trunk provider,?but today I heard a report that T-Mobile is definitely?implicated and reproducible.? Other sources are possible too.
? Has anyone else noticed this? ? Does anyone have a good contact for SIP-related matters at T-Mobile?
participants (4)
-
b.turnbow＠twt.it -
jbrower＠signalogic.com -
Liudy＠bukys.org -
tim＠kooky.org