Voxalot / SIP Broker Support Forums

Voxalot / SIP Broker Support Forums (http://forum.sipbroker.com/index.php)
-   Voxalot Support (http://forum.sipbroker.com/forumdisplay.php?f=4)
-   -   Can't get voice packets to bypass VoXaLot (http://forum.sipbroker.com/showthread.php?t=1304)

ctylor 07-18-2007 12:55 AM

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.

v164 07-18-2007 02:11 PM

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.

martin 07-18-2007 02:20 PM

Quote:

Originally Posted by v164 (Post 10618)
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?
.

v164 07-18-2007 02:42 PM

I'm using the Atcom AT-530.

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

dc2007 07-20-2007 05:52 PM

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.

dc2007 07-21-2007 03:35 AM

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

v164 07-21-2007 08:37 AM

update on RTP voice stream bypass
 
Quote:

Originally Posted by ctylor (Post 10578)
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.

Here are the results:

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
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
Code:

INVITE sip:61180050xxxx@us.voxalot.com SIP/2.0
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK3510204621246528428
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 1 INVITE
Contact: <sip:66xxxx@221.xx.xx.xx:5060>
max-forwards: 70
supported: replaces
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 10015154 26815257 IN IP4 221.xx.xx.xx
s=A conversation
c=IN IP4 221.xx.xx.xx
t=0 0
m=audio 10030 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 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
Code:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK26783172853046725302
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 2 INVITE
Server: OpenSer (1.1.0-notls (i386/linux))
Content-Length: 0
Warning: 392 64.34.173.199:5060 "Noisy feedback tells:  pid=15400 req_src_ip=221.xx.xx.xx req_src_port=5060 in_uri=sip:61180050xxxx@us.voxalot.com out_uri=sip:61180050xxxx@us.voxalot.com via_cnt==1"

0.614 64.34.173.199:5060 >> 221.xx.xx.xx:5060
Code:

SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK26783172853046725302
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 2 INVITE
Server: OpenSer (1.1.0-notls (i386/linux))
Content-Length: 0
Warning: 392 64.34.173.199:5060 "Noisy feedback tells:  pid=15400 req_src_ip=221.xx.xx.xx req_src_port=5060 in_uri=sip:61180050xxxx@us.voxalot.com out_uri=sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 via_cnt==1"

7.700 64.34.173.199:5060 >> 221.xx.xx.xx:5060
Code:

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK26783172853046725302
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 2 INVITE
User-Agent: voxaLot
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061>
Content-Type: application/sdp
Content-Length: 313

v=0
o=root 20078 20078 IN IP4 64.34.173.199
s=session
c=IN IP4 64.34.173.199
t=0 0
m=audio 14638 RTP/AVP 0 8 18 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -


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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK26783172853046725302
Record-Route: <sip:64.34.173.199;lr=on;ftag=190681601>
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 2 INVITE
User-Agent: voxaLot
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061>
Content-Type: application/sdp
Content-Length: 313

v=0
o=root 20078 20079 IN IP4 64.34.173.199
s=session
c=IN IP4 64.34.173.199
t=0 0
m=audio 14638 RTP/AVP 0 8 18 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

The 200 is then acknowledged by my SIP phone:

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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK73351254329964522
Route: <sip:64.34.173.199;lr=on;ftag=190681601>
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 2 ACK
max-forwards: 70
user-agent: Voip Phone 1.0
Content-Length: 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
Record-Route: <sip:64.34.173.199;lr=on;ftag=as58bb87a5>
Via: SIP/2.0/UDP 64.34.173.199;branch=z9hG4bKc521.8e927326.0
Via: SIP/2.0/UDP 64.34.173.199:5061;branch=z9hG4bK18c0f4c1;rport=5061
From: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
To: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
Contact: <sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061>
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 102 INVITE
User-Agent: voxaLot
Max-Forwards: 69
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 218

v=0
o=root 20078 20080 IN IP4 203.166.6.137
s=session
c=IN IP4 203.166.6.137
t=0 0
m=audio 18446 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

(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
Code:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.34.173.199;branch=z9hG4bKc521.8e927326.0
Via: SIP/2.0/UDP 64.34.173.199:5061;branch=z9hG4bK18c0f4c1;rport=5061
Record-Route: <sip:64.34.173.199;lr=on;ftag=as58bb87a5>
From: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
To: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 102 INVITE
Contact: <sip:66xxxx@221.xx.xx.xx:5060>
supported: replaces
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Content-Type: application/sdp
Content-Length: 151

v=0
o=sdp_admin 24790701 24118301 IN IP4 221.xx.xx.xx
s=A conversation
c=IN IP4 221.xx.xx.xx
t=0 0
m=audio 10030 RTP/AVP 0
a=rtpmap:0 PCMU/8000

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
Code:

INVITE sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061 SIP/2.0
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK18436115611157818721
Route: <sip:64.34.173.199;lr=on;ftag=190681601>
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 3 INVITE
Contact: <sip:66xxxx@221.xx.xx.xx:5060>
max-forwards: 70
supported: replaces
user-agent: Voip Phone 1.0
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 337

v=0
o=sdp_admin 10015154 26815258 IN IP4 221.xx.xx.xx
s=A conversation
c=IN IP4 0.0.0.0
t=0 0
m=audio 10030 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=sendonly


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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK18436115611157818721;received=221.xx.xx.xx
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 3 INVITE
User-Agent: voxaLot
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061>
Content-Type: application/sdp
Content-Length: 218

v=0
o=root 20078 20081 IN IP4 203.166.6.137
s=session
c=IN IP4 203.166.6.137
t=0 0
m=audio 18446 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

and then ACKed by my SIP phone:

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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK91992617066638464
Route: <sip:64.34.173.199;lr=on;ftag=190681601>
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 3 ACK
max-forwards: 70
user-agent: Voip Phone 1.0
Content-Length: 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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK1960914432227393180
Route: <sip:64.34.173.199;lr=on;ftag=190681601>
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 4 INVITE
Contact: <sip:66xxxx@221.xx.xx.xx:5060>
max-forwards: 70
supported: replaces
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 10015154 26815259 IN IP4 221.xx.xx.xx
s=A conversation
c=IN IP4 221.xx.xx.xx
t=0 0
m=audio 10030 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


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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK1960914432227393180;received=221.xx.xx.xx
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 4 INVITE
User-Agent: voxaLot
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:*1*66xxxx-00861180050xxxx@64.34.173.199:5061>
Content-Type: application/sdp
Content-Length: 218

v=0
o=root 20078 20082 IN IP4 203.166.6.137
s=session
c=IN IP4 203.166.6.137
t=0 0
m=audio 18446 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -


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
Via: SIP/2.0/UDP 221.xx.xx.xx:5060;branch=z9hG4bK18160206152746116113
Route: <sip:64.34.173.199;lr=on;ftag=190681601>
From: 66xxxx <sip:66xxxx@us.voxalot.com>;tag=190681601
To: "61180050xxxx" <sip:61180050xxxx@us.voxalot.com>;tag=as58bb87a5
Call-ID: 71723394-321421716960@221.xx.xx.xx
CSeq: 4 ACK
max-forwards: 70
user-agent: Voip Phone 1.0
Content-Length: 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.

martin 07-21-2007 09:31 AM

Quote:

Originally Posted by v164 (Post 10709)
however, for the Atcom AT-530 at least, it requires the manual intervention of the caller

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

v164 07-22-2007 01:39 PM

MNF seems to work
 
Quote:

Originally Posted by martin (Post 10710)
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?

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

martin 07-22-2007 01:55 PM

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 07:12 PM.

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