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: Code:
INVITE sip:61180050xxxx@us.voxalot.com SIP/2.0 us.voxalot.com then sends a SIP INVITE message like this to sip.pennytel.com: Code:
INVITE sip:61180050xxxx@sip.pennytel.com:5060 SIP/2.0 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. Quote:
|
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. |
Quote:
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
Quote:
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: Quote:
(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
Quote:
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). Quote:
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. |
Quote:
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
Quote:
I'm using the Atcom AT-530 IP Phone, running the latest firmware: Code:
Version: VOIP PHONE V1.5.25.10 Apr 24 2007 16:51:16 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 Code:
INVITE sip:61180050xxxx@us.voxalot.com SIP/2.0 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 Code:
SIP/2.0 100 Trying Code:
SIP/2.0 100 trying -- your call is important to us Code:
SIP/2.0 183 Session Progress 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 Code:
SIP/2.0 200 OK 11.002 221.xx.xx.xx:5060 >> 64.34.173.199:5060 Code:
ACK sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 SIP/2.0 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 Code:
INVITE sip:66xxxx@221.xx.xx.xx:5060 SIP/2.0 My SIP phone accepts the INVITE: 11.601 221.xx.xx.xx:5060 >> 64.34.173.199:5060 Code:
SIP/2.0 200 OK (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 Code:
INVITE sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 SIP/2.0 That's accepted by us.voxalot.com: 13.984 64.34.173.199:5061 >> 221.xx.xx.xx:5060 Code:
SIP/2.0 200 OK 14.296 221.xx.xx.xx:5060 >> 64.34.173.199:5061 Code:
ACK sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 SIP/2.0 Pressing the “Hold” button again resumes the call: 15.752 221.xx.xx.xx:5060 >> 64.34.173.199:5061 Code:
INVITE sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 SIP/2.0 That's accepted by us.voxalot.com: 15.980 64.34.173.199:5061 >> 221.xx.xx.xx:5060 Code:
SIP/2.0 200 OK and then ACKed by my SIP phone: 16.310 221.xx.xx.xx:5060 >> 64.34.173.199:5061 Code:
ACK sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 SIP/2.0 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. |
Quote:
Thanks. . |
MNF seems to work
Quote:
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
Quote:
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.) |
Quote:
. |
anyone could help me with this? :(
Quote:
|
Quote:
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 :(
|
Quote:
. |
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? |
Quote:
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. |
Quote:
|
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! |
Quote:
Curiously, using MySIPSwitch without any STUN server and behind an NAT, I was able to bypass their proxy with no problem. |
Quote:
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. |
Quote:
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? |
All times are GMT. The time now is 10:08 AM. |
Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.