Voxalot / SIP Broker Support Forums - View Single Post - X-Lite: some IP calls lose audio ~3secs

Tslam · 03-05-2007, 12:37 AM

Martin - yes the problem seems to be codec related.

Since I'm only using 264/64 at the moment, I had selected the only available slow codecs GSM and iLBC. As mentioned, monkeys and NY Speaking Clock (for example) lose audio with those codecs.

When I added a and u law, the X-Lite maintained incoming audio. It also maintained outgoing audio on eg echo test, but of course it was unusable with these codecs.

Which begs the question - how to select codecs that will work with slow broadband - only 64k upstream?? Many ppl will only require X-Lite when they're travelling - often in homes and hotel rooms which possibly don't support more than 64k up (assuming they don't block SIP/RTP).

The underlying problem IMO isn't perhaps due to forcing codecs (eg regular VoIP/VSP calls work fine), but rather the negotiation of slow codecs between X-Lite and... sipbroker (which is the agent for eg *266300, *393612).

I found X-Lite's diagnostics. The log shows lots of gibberish, and coincidentally "Warning Audio Not enough data in latency reducer" messages when GSM/iLBC codecs are enabled (but not necessarily applied).

03-05-2007, 12:37 AM	#9
Tslam Junior Member Join Date: Jun 2006 Posts: 29 Thanks: 0 Thanked 0 Times in 0 Posts	Martin - yes the problem seems to be codec related. Since I'm only using 264/64 at the moment, I had selected the only available slow codecs GSM and iLBC. As mentioned, monkeys and NY Speaking Clock (for example) lose audio with those codecs. When I added a and u law, the X-Lite maintained incoming audio. It also maintained outgoing audio on eg echo test, but of course it was unusable with these codecs. Which begs the question - how to select codecs that will work with slow broadband - only 64k upstream?? Many ppl will only require X-Lite when they're travelling - often in homes and hotel rooms which possibly don't support more than 64k up (assuming they don't block SIP/RTP). The underlying problem IMO isn't perhaps due to forcing codecs (eg regular VoIP/VSP calls work fine), but rather the negotiation of slow codecs between X-Lite and... sipbroker (which is the agent for eg 266300, 393612). I found X-Lite's diagnostics. The log shows lots of gibberish, and coincidentally "Warning Audio Not enough data in latency reducer" messages when GSM/iLBC codecs are enabled (but not necessarily applied).