Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > Voxalot Forums > Voxalot Support

Voxalot Support Support for the Voxalot service.

 
 
Reply
Thread Tools Display Modes
Unread 03-24-2007, 02:37 PM   #1
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default 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
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:6080;branch=z9hG4bK219075768430918035;rport
From: 660xxx <sip:660xxx@us.voxalot.com>;tag=674623933
To: "61180050xxxx" <sip:61180050xxx@us.voxalot.com>
Call-ID: 2272424319-451924324394@xxx.xxx.xxx.xxx
CSeq: 1 INVITE
Contact: <sip:660xxx@xxx.xxx.xxx.xxx:6080>
max-forwards: 70
supported: 100rel
user-agent: Voip Phone 1.0
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 342  

v=0
o=sdp_admin 68861768 17995204 IN IP4 xxx.xxx.xxx.xxx
s=A conversation
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 10070 RTP/AVP 0 4 4 18 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:4 G723high/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

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
Via: SIP/2.0/UDP 64.34.173.199:5061;branch=z9hG4bK44e1d1a8;rport
From: "660xxx" <sip:8886xxxxxx@sip.pennytel.com>;tag=as1ee2c8bc
To: <sip:61180050xxxx@sip.pennytel.com:5060>
Contact: <sip:8886xxxxxx@64.34.173.199:5061>
Call-ID: 0b923187704ffc7e0b5aaa507bacbfca@sip.pennytel.com
CSeq: 102 INVITE
User-Agent: VoXaLot
Max-Forwards: 70
Date: Sat, 24 Mar 2007 10:52:24 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 218

v=0
o=root 18772 18772 IN IP4 64.34.173.199
s=session
c=IN IP4 64.34.173.199
t=0 0
m=audio 15906 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
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.

Quote:
"...or because the destination UAC is not initiating a re-invite."
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?
v164 is offline   Reply With Quote
Unread 05-05-2007, 03:19 AM   #2
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 05-05-2007, 10:24 AM   #3
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default

Quote:
Originally Posted by martin View Post
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.
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.
v164 is offline   Reply With Quote
Unread 05-05-2007, 11:14 AM   #4
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 05-06-2007, 12:36 AM   #5
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 05-13-2007, 11:59 AM   #6
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default voice bypassing VoXaLot

Quote:
Originally Posted by martin View Post
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.
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:

Quote:
The proxy MUST NOT add to, modify, or remove the message body.
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).
v164 is offline   Reply With Quote
Unread 05-13-2007, 05:03 PM   #7
tvox
Junior Member
 
Join Date: May 2007
Posts: 6
Thanks: 0
Thanked 0 Times in 0 Posts
tvox is on a distinguished road
Default

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..
tvox is offline   Reply With Quote
Unread 05-14-2007, 11:55 AM   #8
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 06-23-2007, 09:24 AM   #9
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default RTPproxy for transcoding

Quote:
Originally Posted by martin
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.
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).


Quote:
Originally Posted by v164 View Post
...
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.

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.
v164 is offline   Reply With Quote
Unread 06-23-2007, 12:02 PM   #10
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default

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.
v164 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Voxalot and Sipura/ATA Tutorial: A Comprehensive Walkthrough ctylor Voxalot General 5 04-28-2010 12:52 AM
VoXaLot not working with PBXes (VoXaLot as an extension of PBXes) wilsonhlacerda Voxalot Support 31 12-09-2007 02:30 PM
Which VoXaLot services are B2BUA? v164 Voxalot Support 6 07-23-2007 01:48 PM
SPA3K / Voice Mail Problem BJReplay Voxalot Support 3 07-05-2006 09:09 AM
Newbie - but please be nice Mallycat Voxalot Support 21 04-15-2006 07:50 AM


All times are GMT. The time now is 12:12 PM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.