[koomags]

I would just like to add my 2 cents. Voice quality is not dictated by bandwidth alone, there are other connection characteristics that affect quality, i.e. jitter and packet loss. Some other things to consider are if the provider put some more devices that are used to control traffic (packet shapers) which also affect the delivery of your voice packets. To have decent quality for voip, you will need the following:

adequate bandwidth - a 128kbps (UL) link if connected to a properly designed network will work as fine as someone with a 2048 kbps. (GSM codec is 16 kbps, not sure about other codecs, but it will definitely not be over 64k)

jitter - is the variation is delay of arrival of voice packets. voice is sampled at 20ms samples, jitter should be in the order of 10% or around 2ms if you want near perfect speech quality. Using the ping command will give you a rough idea of the quality you can expect. (the ping RT time will not determine the quality of your link, but it will dictate the delay from the time you stop talking and the other person on the line will answer. What will affect voice quality is the difference in the delays of the packets. so if you have a 800 ms ping time, it will take 800ms x 2 or 1.9 s for you to hear the first work that the other person will say in reply to you. but if it is a rock solid 800 ms delay, than your quality will be very good.

packet loss - it is a known fact that some packets get lost when on the internet, this is not a big problem for data transfer where TCP/IP could just request for a retransmission of that packet. but when carrying voice, anything lost, is lost forever, that fraction of speech is considered gone and any retransmission will be meaningless since the time it was meant to be converted back to sound would have passed. (i.e. muting you experience when you have a bad signal on your mobile phone)

There are of course some other factors that might affect the quality (provider settings), but these are some of the most obvious variables to consider. some providers might have also optimized their data network to provide very efficient performance for data, (giving you decent web browsing, email, ftp etc service), but ending up with lousy voip service.

So that link from china i presume if you ping from the voip gateway in US will probably give a very stable ping delay time, and low.. or no packet loss.

[chandave]

mberlant really hit the nail on the head for the better quality of BV user in China calling US numbers.

When you are in China, calling through BV to a US number, the traffic does stay in the Internet until it reaches BV in the US. From there, the audio would be passed to BV's termination CLEC. Most of the time, there's no codec conversion except at the terminating CLEC. Therefore, a G711u encoded audio from BV user in China going to a US number would be G711u all the way to the PSTN.

But, calling from the US via BV to China would most likely be different. A person in the US using G711u for audio encoding would route their audio to BV. If it's not a BV number, BV would most likely convert it to TDM and send the audio through it's International Carrier to China. The International Carrier might actually use VOIP with a low bandwidth codec (G.729) to try and squeeze alot of calls through their cheap bulk IP pipe instead of sending TDM through circuits. The International Carrier would then convert it from the low bandwidth codec back to TDM and send it to the ILEC in China for final termination.

I have first hand experience with International Carriers that use VOIP with low bandwidth codecs. I use G711a to my VSP and my VSP converts it to TDM for my International Carrier. The International Carrier squeezes the audio with a low bandwidth codec and sends it though their trans-pacific fiber. From there, it's converted back to TDM for transport within the US. The sound quality is bad to be very diplomatic.

If I use BV/Stanaphone/Callpacket with G711u then the quality is much better (even with RTTs of 250ms) since it's G711u all the way to the US. I have a little latency but I don't have to worry about clipped audio or a Mr. Roboto voice.

See ya...

d.c.

[youthintl]

Hi there. Can you guys use BV in Shanghai?I

[mberlant]

What kind of network do you have in your new location? Are you able to get into the Info page? Is your SPA able to pick up an IP address from your network's DHCP server?

[fortissimo]

someone said China ISP (may be just some) blocking port 5060 , I don't know details, but friend who went to Shanghai with a Broadvox Direct, got it working w/o problems. I didn't ask if he switched the port or not.

[mberlant]

Originally Posted by fortissimo

... I didn't ask if he switched the port or not.

Switching your own listening port won't solve this problem if it exists. In fact, chances are pretty good that your client-side NAT router is already assigning you a different listening port. The most common way this happens is when two different SIP clients behind the same router each wants to listen on Port 5060. The first one through the router gets 5060 and the next one is assigned a different port by the router.

If you actually encounter a location that blocks Port 5060 you would need to convince your VoIP service provider to stop listening on Port 5060 and start listening on another port. Since Port 5060 is the global standard for SIP service Registrations, the chances of this solution being viable are not very good.