Can't get voice packets to bypass VoXaLot
 

As Martin has confirmed in this thread,

"Which VoXaLot services are B2BUA?"
http://forum.voxalot.com/showthread.php?t=1258

when making SIP calls through VoXaLot, the RTP voice packets for your call can (will?) bypass VoXaLot if your SIP device is correctly configured (ie, use of STUN, etc if behind NAT, and codec settings so that VoXaLot doesn't need to transcode).

Having your voice packets bypass VoXaLot is ideal, because it means you get all the benefits of VoXaLot routing your calls (dial plans, ENUM lookups, speed dial, SIP-code dialing), with no loss of voice quality (ie, no extra latency), so it is worthwhile putting in the effort to ensure your SIP device is setup optimally.

For example, in my situation:

My SIP phone is in Japan,

VoXaLot's SIP server (us.voxalot.com) is in the United States, and

my provider's SIP server (sip.pennytel.com) is in Sydney (Australia).


The SIP INVITE message will transit us.voxalot.com (where the dialed number will be checked against ENUM and dial plans) on the way to sip.pennytel.com, however, ideally, the voice packets will travel direct between my SIP phone and sip.pennytel.com.


However, I regret to say that I have been unable to get us.voxalot.com to stop proxying the voice packets.

My SIP phone is sitting on my public IP address, and to make sure VoXaLot doesn't do "NAT assistance", I have set "Enable symmetric NAT handling" to "No" on the member details page:


"Enable symmetric NAT handling (if unsure, set to "Yes")"
http://www.voxalot.com/action/memberDetails


That leaves the issue of codec settings, codec negotiation, and transcoding.

What I'm seeing is that us.voxalot.com is proxying the voice packets even when both ends of the call are using the same codec, and so far I haven't been able to prevent this.


Basically, I just want to use the G711 ulaw codec with Pennytel. In the Provider Details page, I've entered ulaw as the only codec. In my SIP phone, I can't disable the other codecs, but I can put ulaw at the top of the list.

As an example, for a call to an Australian 1800 number, here is the SIP INVITE message my SIP phone sends to us.voxalot.com:

us.voxalot.com then sends a SIP INVITE message like this to sip.pennytel.com:
The SDP body shows that VoXaLot is asking sip.pennytel.com to send the RTP packets to 64.34.173.199 (ie, us.voxalot.com).

I'm not sure if I properly understand the codec negotiation mechanism when calls are routed through VoXaLot. I would have thought that, provided all of the codecs entered in the "Provider Details" page are offered by the SIP phone in it's SDP body, then VoXaLot would just forward that SDP body on to the provider as is. However, I'm starting to think that maybe VoXaLot starts by always proxying the media (to help ensure that the call can be established reliably), and then relies on the provider to initiate or correctly respond to a SIP "re-INVITE" message to subsequently modify the media stream. If this is the case, then it means that VoXaLot could continue to proxy the voice packets, even when no transcoding is necessary.

Martin's quote made me start thinking this.

Does that mean that having voice packets bypass VoXaLot depends on sip.pennytel.com initiating or supporting a re-INVITE ? And if sip.pennytel.com doesn't support that, then there is no way to get the voice packets to bypass VoXaLot?

I saw your reference to this thread over on Whirlpool . Please accept my apology for not responding sooner.

We have spent the last couple of months re-engineering our core platform to address this very question.

You are 100% right, alot of things must be in place (some we don't have control over) before Voxalot decides to UNPROXY the RTP. The solution we have been working on allows the user to explicitly decided whether or not they want Voxalot to proxy (with the default being "Yes").

Under the new platform, if the user sets this value to "No" Voxalot will do 2 things:

1. It will disable the RTPProxy for the user and
2. Voxalot will initiated the RE_INVITEs rather than relying on the end points to do so.

The good news is the telephony piece is built and currently in test and the user interface that drives these new settings is currently being developed as part of our web-site re-design.

If you are interested v164, we are more than happy to give you access to this new telephony engine to perform your own analysis.

Thanks.

I hope your team can get it to work, Martin, but with these "re-INVITES" in the mix, things are starting to get really complicated.


I'm not an expert on SIP, but I would have thought that RTPproxying would work like this:

- VoXaLot forwards the SDP body, unmodified, to the call destination (VSP, etc).

- If the call destination responds with "488 Not Acceptable Here" (the normal error message if the codecs offered are not OK), VoXaLot would then offer a revised SDP body, referring to VoXaLot's RTP proxy, and containing the codecs that VoXaLot's RTP proxy is prepared to transcode.

In other words, the RTP proxy is only called into service where the alternative would be for the call to fail. I think this is a good backup to have, because some SIP devices only have ulaw, for example, yet someone on a low bandwidth link would have to insist on a lower bandwidth codec.

I feel that using re-INVITES is kind of pushing the boundaries of SIP compatibility, such that some SIP devices will fail to handle it.

Unfortunately it is not quite that simple. As there are 2 lots of credentials involved:

UAC<--1-->Voxalot<--2-->Provider

Two calls must be established. Once the calls are established the re-invites are required.

I will talk with the team on Monday and get back to you.

FYI, member MarkLL reported the same one way audio problem you are having v164 with PennyTel.

He also mentioned that it worked perfectly with SIPME. We also tested with WDP and that works OK.

Seems success will depend on the underlying provider used.

voice bypassing VoXaLot
 

Thanks for that explaination. I can see, looking at the two SIP INVITE messages in the original post, that there are, as you say, two separate phone calls, each with their own (separate) set of credentials.

I've skimmed through RFC 3261 again.

The concept I imagined was the SDP body (the "message body" being carried by SIP) from my SIP phone (user agent client (UAC)) could traverse several SIP proxy servers on the way to the destination user agent server (UAS), and the series of SIP proxies would, through various logic, route the message appropriately, each "hop" taking it "closer" to the destination. A SIP proxy server might re-write the request URI, (and/or modify the SIP message in other ways allowed by the SIP specification), but would not touch the SDP body. In the words of RFC 3261:

It seems that the above concept works fine, except for when authentication for more than one SIP domain is needed (ie, more than one set of credentials are needed). RFC 3261 explains a user agent client authenticating itself (providing credentials) to a SIP proxy (in this context, us.voxalot.com) or a UAS (in this context, the VSP (sip.pennytel.com)), but doesn't seem to provide a way for a SIP proxy (us.voxalot.com) to authenticate itself (provide credentials) to a UAS (sip.pennytel.com).

(I think I had mistakenly assumed that RFC 3261 included authentication between SIP proxies as part of the SIP proxy<->SIP proxy message routing.)

VoXaLot's method of establishing two separate phone calls (in doing so, VoXaLot is acting as a back-to-back user agent (B2BUA)), and then attempting to subsequently modify the media stream with re-INVITE messages is one way (possibly the only way) this can be handled, while still conforming to RFC 3261.

However, I'm not entirely convinced that, in doing this, it is necessary for VoXaLot to create a new SDP body and initially proxy the media, although I concede that changing the current arrangement could involve significant engineering effort for custom programming of Asterisk and/or Openser (or whatever VoXaLot uses).

My idea could be summarised as VoXaLot acting similar to a B2BUA in respect of the SIP part of the SIP messages, but not touching the SDP part (not having anything to do with the message body). This, I understand, would be fully RFC 3261-compliant, since RFC 3261 is about SIP, not SDP. (My understanding is that the authentication / credential details in RFC 3261 are not related to the SDP body).

I am also trying to get my Voip traffic to bypass Voxalot.

I am using Voxalot to register with Tpad..then iam forwarding the call via SIP URI directly to my ATA (ddns setup). Tpad only supports ulaw/alaw hence i have setup my ATA accordingly so that Voxalot doesnt have to do any transcoding. Still i cant get calls to bypass voxalot.

@V164, i think my calls are within Group1 of your definitions, can u shed any light on this issue..? If answer is in the above posts can u pls post it in more simple words..

Thanks v164 for your analysis and well thought out post. We are commited to make this work as best we can while sticking to the RFC guidelines.

I will keep you posted on our progress as we work on through this solution.

Thanks again

RTPproxy for transcoding
 

That explains why VoXaLot passes on the SDP body, unmodified, when the call is destined for a SIP URI (sip code or enum lookup), where there are no credentials required for the next "leg".

In this case, the voice packets bypass VoXaLot from the beginning, however my tests today have shown that, in this situation, the RTP proxy doesn't help when it is needed (for transcoding).



As far as RTP proxying for the purpose of transcoding is concerned, I would think that the availability of transcoding is more important when the call is destined to a SIP URI (ENUM / SIP code lookup) than when the call is going out via a provider. The reason being that, in the case of the provider, we know, in advance, which codecs the provider supports, and the onus is on the provider to do any transcoding if necessary. However, in the case of a SIP URI obtained via ENUM / SIP code lookup, to which your call may be automatically re-directed, it is not known in advance which codecs that endpoint accepts, hence there is a risk that the call may fail due to incompatible codecs.

What I'm trying to achieve, is automatic ENUM lookups on my outgoing calls, and having calls that don't match ENUM going via Pennytel (or other) with no additional latency caused by the voice packets going via VoXaLot.

Once I've got that set up, it will then be a "cookie-cutter" solution that others can copy.


Since at the moment it seems to be impossible to get VoXaLot to stop proxying the media (at least, in the case of sip.pennytel.com), one solution might be to have my SIP phone try the number via sipbroker.com for the ENUM lookup (sipbroker.com does not have an RTP proxy). This works fine for the ENUM lookup, however the problem is trying to get the "automatic PSTN fallback" part to work. I get the impression that that only works with particular SIP devices (sipura / linksys, etc). I can't seem to get that to work with my Atcom AT-530, or with the X-Ten lite softphone.

For the time being, I've put a dial rule in my SIP phone's dial plan so I can manually try the number via sipbroker.com.

Testing now with the new Voxalot platform, with "Symmetric NAT Handling" set to No and "Optimize Audio Path" set to Yes, I am curious what are your results, v164 and whether they now meet your expecations? I sympathize a lot with your objectives.

I'll do a thorough test on the weekend.

I tried a preview two weeks ago, and I was able to get my voice to bypass VoXaLot on a call through Pennytel, however I had to manually press the "hold" button on my SIP phone (after the call was answered, and then push it a second time to resume the call) to force it to send ("initiate") a re-INVITE.

I'd be interested to know what happens if you use a different client with the same provider e.g. X-Lite or something.

Also out of curiosity what SIP phone are you using?
.

I'm using the Atcom AT-530.

I'll try also with the X-Lite softphone.

this is working perfectly with my present setup of spa3k but if im out and place a call via pstn+spa3k at home i get only one way audio.they can't hear me.

i can't find the exact part of spa3k config to change to make this work :(

update on RTP voice stream bypass
 

Here are the results:

I'm using the Atcom AT-530 IP Phone, running the latest firmware:
The phone is sitting on my public IP address, 221.xx.xx.xx, and using the standard SIP port 5060 UDP.

My six-digit VoXaLot username is 66xxxx.

Symmetric NAT handling = No
Optimize Audio Path = Yes

VoXaLot dial plan is set to send the call, as is, to sip.pennytel.com, using the ulaw codec only.

The phone number I'm calling is 61180050xxxx.

64.34.173.199 = us.voxalot.com

203.160.6.137 = Pennytel's RTP server for this call

(note: As explained in Latency Effects On Call Quality - Voice over IP - Whirlpool Broadband Forums Pennytel are using several RTP servers, at different IP addresses to sip.pennytel.com (203.160.6.160))

Here is the SIP dialogue, with commentary. Elapsed seconds is shown on the left.

0.000 221.xx.xx.xx:5060 >> 64.34.173.199:5060
us.voxalot.com then challenges for credentials:

0.224 64.34.173.199:5060 >> 221.xx.xx.xx:5060
100 Trying

0.227 64.34.173.199:5060 >> 221.xx.xx.xx:5060
407 Proxy Authentication Required

0.298 221.xx.xx.xx:5060 >> 64.34.173.199:5060
ACK

0.386 221.xx.xx.xx:5060 >> 64.34.173.199:5060
INVITE (with credentials)

0.612 64.34.173.199:5060 >> 221.xx.xx.xx:5060
0.614 64.34.173.199:5060 >> 221.xx.xx.xx:5060
7.700 64.34.173.199:5060 >> 221.xx.xx.xx:5060

From this point, RTP voice packets start flowing, in both directions:

64.34.173.199:14638 <-> 221.xx.xx.xx:10030

The destination phone is ringing, and the RTP voice traffic conveys “call progress” tones (ie, the ringing tone). The RTP traffic is being proxied by us.voxalot.com ( 64.34.173.199 ).

About three seconds later, the phone is answered:

10.555 64.34.173.199:5060 >> 221.xx.xx.xx:5060
The 200 is then acknowledged by my SIP phone:

11.002 221.xx.xx.xx:5060 >> 64.34.173.199:5060


The RTP voice packets continue flowing, in both directions, but now carry the voice for the phone call:

64.34.173.199:14638 <-> 221.xx.xx.xx:10030


If “Optimize Audio Path” is set to “No”, this is the end of the story, and us.voxalot.com continues, as before, to proxy the RTP voice packets for the entire duration of the call.

However, if “Optimize Audio Path” is set to “Yes”, us.voxalot.com sends this packet about 300ms after the call is answered:

11.223 64.34.173.199:5060 >> 221.xx.xx.xx:5060
(note: I received a duplicate of this packet 3ms later. My SIP phone responded to the duplicate, and the duplicate resonse was also ACKed, as below)

My SIP phone accepts the INVITE:

11.601 221.xx.xx.xx:5060 >> 64.34.173.199:5060
and this is then ACKed:

(ACK packet not shown)



The RTP voice packet stream is now modified, to this:

221.xx.xx.xx:10030 -> 203.160.6.137:18446
221.xx.xx.xx:10030 <- 64.34.173.199:14638

My SIP phone now sends the RTP voice packets direct to Pennytel's RTP server ( 203.160.6.137 in this case), however the RTP voice packets from Pennytel continue to come in via us.voxalot.com – an unusual situation, where the round-trip voice path is a triangle.

If I do nothing, this RTP voice packet triangle, with us.voxalot.com proxying half of the RTP voice packet stream, continues for the rest of the call; the RTP voice packet stream is not automatically unproxied completely.


However, if I push the “Hold” button on my SIP phone, it then sends this packet to us.voxalot.com:

(notice the different destination port number)

13.757 221.xx.xx.xx:5060 >> 64.34.173.199:5061

That's accepted by us.voxalot.com:

13.984 64.34.173.199:5061 >> 221.xx.xx.xx:5060
and then ACKed by my SIP phone:

14.296 221.xx.xx.xx:5060 >> 64.34.173.199:5061

Pressing the “Hold” button again resumes the call:


15.752 221.xx.xx.xx:5060 >> 64.34.173.199:5061

That's accepted by us.voxalot.com:

15.980 64.34.173.199:5061 >> 221.xx.xx.xx:5060

and then ACKed by my SIP phone:

16.310 221.xx.xx.xx:5060 >> 64.34.173.199:5061

Having pressed the “Hold” button (twice, at this point, so as to resume the call), the RTP voice packet stream resumes, completely bypassing us.voxalot.com:

221.xx.xx.xx:10030 <-> 203.160.6.137:18446

This continues for the rest of the call.


So to sum up, the new “Optimize Audio Path” option has now made it possible for the RTP voice packets to bypass VoXaLot when using Pennytel, however, for the Atcom AT-530 at least, it requires the manual intervention of the caller (pressing the “Hold” button twice after the call is answered).

Obviously, VoXaLot has done a lot of work to get this far, and it is certainly an improvement, but it's not perfect yet.

Thanks for the detailed post. We would be interested to know what the situation is when a different UAC is used other than the Atcom. Is there any chance that the above analysis could be reperformed with a different client?

Thanks.
.

MNF seems to work
 

The only other SIP devices I have are softphones.

I tried with the X-Lite softphone, but the results were worse. After receiving the re-INVITE, the phone changes to sending the RTP packets direct to Pennytel, and it seems to work, but I get the occasional "ICMP port unavailable" error returned. If I force the X-Lite softphone to send a re-INVITE by putting the call on hold, then resuming, the incoming RTP voice packet stream remains unchanged, and every outgoing packet (direct to Pennytel) is rejected by Pennytel with "ICMP port unavailable". I end up with one-way audio and DTMF not working.

I'll post the SIP trace with commentary later.


Atcom AT-530 + VoXaLot + MNF works

I also tried doing the above test with the Atcom AT-530, but sending the call out via MNF instead of Pennytel. That worked as intended - after the call was answered, us.voxalot.com sent me a re-INVITE (with the SDP referring to MNF's RTP server), the AT-530 replied with 200, with an SDP referencing itself, us.voxalot.com ACKed that, and then straight away the RTP voice packets changed to going direct between me and MNF.

I noticed a small hiccup in the voice during the first half a second. (The number I was calling (an IVR service) answers with "Welcome to..." . The RTP stream was modified in the midst of the word "Welcome", so what I heard was "Wel'to..." (the "come " must have been in transit over the Pacific Ocean when the direct RTP stream arrived)).

That would seem to suggest that it's got something to do with Pennytel.


I also tried the above test with the Atcom AT-530, with Pennytel as before, but using PBXes instead of VoXaLot. The results were the same. PBXes successfully unproxied half of the voice stream (after sending me a re-INVITE), and then the other half was unproxied after I hit the "Hold" button twice.

I also tried:

Atcom AT-530 -> PBXes -> VoXaLot -> Pennytel

and the results were the same (haven't tried the reverse order though).

Thanks
 

Thanks for the confirmation v164. Your results confirm our findings that the optimize audio path does depend on the embedded provider.

We might create a new thread where members can capture and share their results. We may also add a new field the the Voxalot - Global Provider List

Thanks again.
.

Pennytel various tests
 

I've now tried the reverse order:


Atcom AT-530 -> VoXaLot (us.voxalot.com) -> PBXes -> Pennytel

and the results are the same.


I've also tried:

Atcom AT-530 -> VoXaLot (us.voxalot.com) -> PBXes -> VoXaLot( 2nd account ) (au.voxalot.com) -> Pennytel

and the results are also the same (outbound audio automatically unproxied, inbound audio unproxied only after manually pushing the "Hold" button).

(This is with "Optimize Audio Path" / "Audio Bypass" set to "Yes" everywhere).



I suppose this means that sip.pennytel.com is not responding (or not correctly responding) to VoXaLot's re-INVITE.

Is this behaviour allowable according to RFC 3261 (if not, we could reasonably petition Pennytel to fix it), or do we just have to live with it?

(edited: even if it's not required for RFC 3261 conformance, we could probably ask Pennytel to consider it. They seem to be keen to cooperate.)

We are more than happy to assist them in achieving this goal.
.

anyone could help me with this? :(

I'm not a Sipura expert however I will take a stab at a suggestion. Is there some thing like a pass thru setting in this device?

I would hazzard a guess that you need to allow the PSTN interface to pass thru to the VoIP interface.

Hopefully a Sipura expert can add to this.
.

yes.i already using it. i did every concievable thing and everything working beyond my expectations and this is the last remaining missing piece :(

Does *600 provide 2 way audio when you dial in via PSTN?
.

you mean outside/remote pstn? no.

here's what i noticed but remember this problem was caused only when i tried the new feature of bypassing voxalot...the setting to No of "Symmetric NAT Handling"

setting that not working
1.voxalot registered in line 1 and as @gw1
2. dial plan (xx.<:@gw1>) in "pstn line"

but if i use another account as @gw2 with the following setting
1. voxalot still registered in line 1
2. create a second gateway with differrent account and NAT mapping = yes
3. dial plan (xx.<:@gw2>) in "pstn line"
this one works :)

may questions now is...
the setup as i describe as the one working..did i really bypass voxalot proxying or what i did was i end up in the same scenario im avoiding and resulting to the exact same thing as if im not bypassing voxalot?

For the 2nd account setup on gw2 is:

1. The symmetric NAT set to "No"
2. The providers setup within that account have "Optimize Audio Path" set to "Yes"
3. If yes to both 1 and 2 and you dial *600 and get 2 way audio and you make a call via one of the providers setup in step 2 then, yes there is an excellent chance your voice stream is bypassing our servers.
.

I clearly do not know enough about SIP, so excuse the possibly naive question.

I am trying to get an SPA3000 (ATA) on my PSTN line to call an SPA941 (IP phone) on the same subnet, with the ability to fallback to voicemail, on the voxalot account the SPA941 is registered to. I have tried many things.

One way I know I can get this to work (it worked on another VSP) is by having the SPA3000 'hotline' the call via a 2nd voxalot account to the account the SPA941 is registered to.

The problem here is the inefficiency of having all of this voice traffic (between two devices on the same subnet) traversing the net (and it is doubled up, right?).

My question is this : given that I have full control over the router, dns, phone settings etc. is there any setup that would allow the voice traffic to take the short route (directly across my subnet) between the two devices after the call setup has completed?

Thanks for any suggestions.

You can probably do an IP address call. I would assume that your devices both support direct IP calling. The voice traffic then never leaves your network.
However, there is no voicemail fallback in this situation.

The IP Address call that you suggest works fine, but as you say, it is not easy to get voicemail fallback using that technique, hence my search for a new one.

Just curious if anyone has got the reinvites to work properly with their service provider?

I am having similar problems where I have the nasty triangle I am trying to get rid of. I'm using callcentric and perhaps they don't allow reINVITES -- I'm waiting for a response from them to see...

If you HAVE got reINVITES working -- what provider are you using? This will help us all out!

I'm still having problem trying to bypass voxalot proxy. I'm also having this triangle issue. I'm using Outpost Firewall to monitor my network activity and it's showing that incoming data goes directly to my VSP while outgoing data passes through voxalot proxy first.

Curiously, using MySIPSwitch without any STUN server and behind an NAT, I was able to bypass their proxy with no problem.

MySIPSwitch does not handle the media stream. It deals only with SIP Signaling.

I too had the triangle (or three legged) call problem. It happened last year whenever I used VoipDiscount through Voxalot. I have not recently checked for the problem.

What happens if the "Hold" button is NOT pressed at all? I assume the call still go trough with audio NOT bypassing Voxalot. Correct?

So if pressing the "Hold" button twice indeed causes the audio to bypass Voxalot, can such pressing be postponed a few seconds after the call is answered?