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. . |
All times are GMT. The time now is 12:10 AM. |
Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.