X-Lite: some IP calls lose audio ~3secs
 

My X-Lite registers to au.voxalot.com, and passes the echo test. It also calls eg 1-516-687-5089 (supernettel.com) and confirms ENUM. Supernettel also works if called with the Sipbroker prefix *013.

But... some IP calls to eg *266300 (monkeys) and *393612 (NY clock) lose audio after a few seconds. Why?

I've configured X-Lite as follows:

. discover global IP address
. Use STUN stun.voxalot.com:3478
. enable ICE *
. manual port range 5070-5080 ; to avoid conflict with my ATAs *
. send SIP Keep Alives *
. contemporary registration with same Vox ID on my ATA port 5060 *

* apparently makes no difference - still registers with same audio symptoms without enabling these options

I haven't explicitly forwarded any ports thru my NAT router, but why should I. Besides, I don't know what RTP range X-Lite is using (that's STUN's problem).

Try disabling the manual port ranges, and if you haven't already, check "Use rport" as well. With those settings and everything else as you have set above (though I use "stun.xten.com" instead as my STUN server), I cannot duplicate your problem.

I tried that previously, and again just now. I'm still having the problem. I even tried using stun.xten.com with and without the 3478 suffix.

Incidentally, using rport appears to be contrary to the instructions for using STUN with Voxalot as per voipstuff.com.au.

If you'd like to test peering with my X-Lite in the next hour or so, pm me and I'll give you my Vox number. I guess that would ring both X-Lite and my ATA - I'd answer the softphone first.

Here's a possible clue is that my firewall is blocking ICMP from Voxalot: http://support.counterpath.com/posti...e0949121d35386

I don't know anything about ICMP, and I can't see where my WAG54Gv2 blocks it. Anyhow, I tried disabling my router firewall, and/or my Windows firewall. Nothing gives.

Then I tried registering with SIPME. In this case, a call to *266300 doesn't just lose audio, it hangs up. Interestingly the dropout / hangup occurs exactly between "monkeys" and the monkey sounds.

I should mention that VSP calls to PSTN negotiated by Voxalot on X-Lite work fine - eg reasonable latency and continuity to my mobile.

Hi Tslam,
The linksys have an option to disable pings from the WAN ("Block WAN requests" on my RVS4000), The Prompt is not always obvious what it does. Try turning it off. What does the Debug log show?

Hi MarkLL, I tried enabling WAN requests, then disabling the firewall entirely.

The firewall log shows a couple UDP entries associated with negotiating the SIP and RTP traffic, but says nothing about blocking ICMP or any other unexpected packets.

I haven't run a Debug log on X-Lite. Is that possible?

Hi Tslam,

A couple of things I can think of:

1. What Codecs are enabled in x-lite (under options->advanced)

2. Another possibility is a re-invite is not reaching x-lite and the other side is dropping the call. Are you able to confirm that inbound calls to x-lite are working?

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).

Going via a VSP allows VoXaLot to use transcoding. This means that x-lite -> voxalot can use say gsm, and voxalot -> destination (via provider) g711.

I'd be interested to see what happens when you route the call to monkeys via the dial plan with the SIP Broker provider.

I half suspect the transcoding will kick in.