We're investigating audio quality issues in our system; maybe someone can help. We're using Asterisk as a basic PBX, with a single PRI on one side and SIP phones on the other: Sipura SPA-841's. We're experiencing several audio effects which seem to commonly correspond to network failures (packet loss, high jitter, etc manifested as "robot voice", dropouts, periodic buzzing, etc). However, all the network monitoring we're doing on our fully switched, underutilized 100baseT-FD network shows that we have sub-1ms ping times and no jitter to speak of. Looking at the SPA-841's main Status page, I see call status: Line State: Connected Tone: None Encoder: G711u Decoder: G711u Type: Inbound Remote Hold: No Callback: Peer Name: xxxxxxxxxx Peer Phone: xxxxxxxxxx Duration: 00:09:53 Packets Sent: 29545 Packets Recv: 29666 Bytes Sent: 4727360 Bytes Recv: 4746560 Decode Latency: 50 ms Jitter: 0 ms Round Trip Delay: 0 ms Packets Lost: 0 Packet Error: 0 Mapped RTP Port: 16396 >> 0 I have not yet seen Jitter above 2ms, or significant packet loss; round trip delay is always 0. But periodically, "Decode Latency" will spike up to the 150-300ms range. This seems to correspond to audio effects such as a periodic "bzzt" sound in the handset. Does anyone have any familiarity with "decode latency," specifically with Sipura devices? Why would it take 200+ms to decode a 20ms RTP packet? G.711u has existed for over 30 years, how hard could it be? Thanks, Alan Ferrency pair Networks, Inc. alan@pair.com
> Does anyone have any familiarity with "decode latency," specifically > with Sipura devices? Why would it take 200+ms to decode a 20ms RTP > packet? G.711u has existed for over 30 years, how hard could it be?Although I have never seem the decode latency to go above 30 ms on a LAN, it does go up to 80 ms if the Sipura device (phone or ATA) is connected via an Internet link which has jitter. So I don't know for sure, but my understanding is that it's the delay from the arrival of the packet until it's played; this is not due to the actual decoding but probably mostly due to the jitter buffer in the device, which is adjusted dynamically depending on the traffic conditions. More jitter = larger buffer to try to compensate for late packets rather than considering them lost. Anyone correct me if I'm wrong here. Having said that, I don't notice the delay or distorted voice even if the decode latency is as high as 80 ms. Not sure about 200+ ms, but it seems rather high and would imply to me that you have a connectivity issue somewhere on your LAN. --Luki
> Subject: Re: [Asterisk-Users] SPA-841 "Decode Latency"?Luki <lugosoft@gmail.com> wrote:> > Does anyone have any familiarity with "decode latency," specifically > > with Sipura devices? Why would it take 200+ms to decode a 20ms RTP > > packet? G.711u has existed for over 30 years, how hard could it be? > > Although I have never seem the decode latency to go above 30 ms on a > LAN, it does go up to 80 ms if the Sipura device (phone or ATA) is > connected via an Internet link which has jitter. So I don't know for > sure, but my understanding is that it's the delay from the arrival of > the packet until it's played; this is not due to the actual decoding > but probably mostly due to the jitter buffer in the device, which is > adjusted dynamically depending on the traffic conditions. More jitter > = larger buffer to try to compensate for late packets rather than > considering them lost. Anyone correct me if I'm wrong here. > > Having said that, I don't notice the delay or distorted voice even if > the decode latency is as high as 80 ms. Not sure about 200+ ms, but it > seems rather high and would imply to me that you have a connectivity > issue somewhere on your LAN.The explanation of jitter adding to decode latency sounds reasonable. However, as I said before, I have never seen jitter go above 5ms even when our "decode latency" spirals out of control. Our latency is under 1ms, generally. It's 100 base T fully switched, and not highly utilized, with 2 switches between the phone and the PBX. Our current working theory, which we will test "soon", is that this may be caused by periodic high levels of ARP broadcast traffic. I'm not familiar with the hardware of these phones, and for most ethernet devices they should ignore ARP with no performance effects. But if the SPA-841 is set up in such a way that it eats CPU for the phone to discard ARP packets, then this could be a problem for us. I'll keep you posted on what we find. If anyone has any insight into the networking hardware the SPA-841 uses, I'd be interested in that. Thanks, Alan Ferrency pair Networks, Inc. alan@pair.com
> Subject: Re: [Asterisk-Users] SPA-841 "Decode Latency"?"Matias G." <listas_ast@reliable.com.ar> wrote:> > Luki <lugosoft@gmail.com> wrote: > > > >> > Does anyone have any familiarity with "decode latency," specifically > >> > with Sipura devices? Why would it take 200+ms to decode a 20ms RTP > >> > packet? G.711u has existed for over 30 years, how hard could it be?<snip>> > Our current working theory, which we will test "soon", is that this may > > be caused by periodic high levels of ARP broadcast traffic. I'm not > > familiar with the hardware of these phones, and for most ethernet > > devices they should ignore ARP with no performance effects. But if the > > SPA-841 is set up in such a way that it eats CPU for the phone to > > discard ARP packets, then this could be a problem for us. > > > > I'll keep you posted on what we find. If anyone has any insight into the > > networking hardware the SPA-841 uses, I'd be interested in that. > > Alan, > pls keep us informed on wether you find what is going wrong with this > issue... thanks a lot. > > M.Hello, Although we don't have a definitive answer for why we were having the problems we were having, we seem to have solved those problems. Specifically: We have taken portions of our SIP phone network, and completely separated them from the rest of our network. The Asterisk server's second ethernet port is dedicated for use with the SIP phones only, and wiring from there to the phones is used only for phone SIP traffic. Since the network was fully switched before, the only real effect this has is to segment the broadcast domain. In terms of traffic reaching the phones, the phones are no longer seeing any ARP packets (or other broadcast packets, minimal) destined for the rest of the network. This has pretty much 100% solved our sound issues, which manifested themselves as "robot voice", buzzing, and dropout (silence). This is a tremendous relief! Now, we just need to figure out how to deploy two completely parallel networks and wiring, which kind of defeats one of the original purposes of going with VOIP... I haven't specifically checked on the "decode latency" value lately, for a few reasons: - I haven't had any audio issues to mark a good time to check on it. Previously, the decode latency was usually normal, and only rarely "very high", so a random sampling would probably not show me much useful anyway. - Now that the phones are on their own network, it's a lot more difficult to get to the web configuration screen :) This is something I need to work on, but all of our phone configuration is now centrally provisioned so it's not a big deal in practice. Thank you all for your insight, Alan Ferrency pair Networks, Inc. alan@pair.com