Types of 'bridges' available.

I think you should offer the optiuon of an external bridge (otherwise know as SIP forward) over an Asterisk Native bridge which appears to be what you are using.

I say this only because you offer the recording option, and these would not work on an external bridge, as the voice packets would not pass through your server at all.

I undestand that you can not use this with all servers or connectionbs, however for those that can use it it results in higher quality calls, and fewer system resourses on your server.

Furthermore , you may wish to consider that people using this service are not running their own Asterisk server and probably know little about Dial plans and other astrisk specific terminology and formats. I suggest you make this more idiot proof or add more definitions to what the options do.

This post has been edited 2 time(s), it was last edited by sup on 18.02.2006 at 23:43.

Improving voice quality

Hi,

thanks for your request. Actually voice quality is sometimes poor if phones & providers are very far away from our server sites, e.g. if they are in America or Asia. We are currently setting up more sites to come closer but still there will remain places out of range for low latencies.

The reason is that all voice packets from the phone pass the PBX before going to the provider. You can measure your latency to our servers by calling the echo test *43.

To solve the problem we offer a new device option called audio bypass. Try enabling it for bypassing the PBX thus transmitting audio directly between phone & provider. We have not enabled it by default because it won't work in all cases.

• Advanced features like call transfer will only work if you set dtmfmode=info and your phone supports it.
  
• Your phone and provider need to support SIP REINVITEs. Most of them do.
  
• There might be problems behind NAT routers.
  

I do not see this option. Where is it exactly?

Improving voice quality

Select an existing extension. When adding a new extension it does not appear because it's an advanced option.

Best regards,
Pascal

I've tried the audio bypass and as you state, it only works sometimes. It looks like you need to add the option to both extensions and to trunks... with lesser taking precedence. For example, if I call out from my sipura 2002 to voxee.com trunk with audio bypass on, it works. If I call out through sipphone.com it fails (no audio). So we need a way to indicate which trunks will work with audio pypass as well as which extensions.

FYI, I'm behind NAT.

DAK

This post has been edited 1 time(s), it was last edited by dke on 20.02.2006 at 23:42.

Improving voice quality

Hi DAK,

thanks to your research I have added the option for trunks as well. It is an AND rule. Only if both extension and provider have it set the audio packets will be bypassed.

Pascal

MAn, you guys are GREAT!

Thanks a lot for a wonderful service!

audio bypass

I was hoping that someone may be able to explain the audio Bypass option a little better.

For intsance, I have an account that canreinvite (yes).

I have tried to take the inbounds from this and route them directly to a Server address that will route them to a PSTN number. I am somewhat confused, as I do not know whether I need the audio Bypass for the trunk or the extension or both. It seems that when I use both trunk and extension audio bypass, it clearly does not work. Not only for this but on several other attempts I have made.


with inbounds...
So if the Trunk has audio bypass enabled, and it is off on the extension how then is the call handled?

What if the extension alone has audio bypass enabled on an inbound?



Now for outbounds...
with trunk audio bypass only
with extension audio bypass only

Thanks,

Mark

This post has been edited 1 time(s), it was last edited by sup on 06.03.2006 at 16:16.

Audio bypass seams to be working for me at least on outbound calls (I have not tried inbound). You have to set audio bypass to yes on both the extension and the trunk that is being used.

I have tested calls through my SPA-2002 and with audio bypass on the latency does appear to be much better. Also, the syslog trace from the SPA-2002 does show a rather cryptic line suggesting that it received a new RTP destination/port during call setup.

NAT setup may also affect this. My SPA-2002 is behind a Linksys WRT45G router. On the SPA-2002 all stun/nat settings are disabled. On the WRT54G ports 5060/1 and RTP ports 16384-16482 are forwarded to the SPA-2002. I have had numerous problems trying to enable stun/nat settings on the SPA-2002 and have found that it works fine without them.

DAK

This post has been edited 1 time(s), it was last edited by dke on 06.03.2006 at 17:36.

I should add that while the RTP destination for audio is changing, the codec does not. Even though I have a preference for G729, the connection remains at G711.

DAK