What are the recommended settings to successfully implement VoIP over 3G/4G data connection? Assume we are talking about using Polycom phones, and the 3G/4G data connection comes from a Cradlepoint router that is plugged in with AC power and has high gain antennas. The device will be stationary, so we will not have to worry about tower handoffs breaking the connection. This will be for fixed wireless aiming at a cell tower. I assume packet loss will be a big concern as we have no control or QoS abilities. Plus, the speed fluctuates so much. I have read to use G.729 codec, and TCP for signaling to bypass firewalls. Besides that, what other settings are recommended? Changes in MTU? Changes in voice payload ms? Is there a better codec to use? Header compression?
I would suggest getting a static IP from the carrier. The Carrier Grade NAT that US mobile providers use could make stationary phones lose registration without it. On LTE, you'll be fine with almost any codec that you want. I typically use ulaw and g722 over 4G LTE with no problems. If you are doing it over a 3G connection, stick with g729. TCP isn't mandatory, I use UDP signaling and don't have issues on T-Mobile, Sprint, or Verizon LTE. I have not tried AT&T LTE and VoIP. I would suggest talking with the carrier you chose to see what their session timeout value is. You'll want to set your registration time lower than this to keep the Internet session up. You may be able to even set the session refresh rate in the cradlepoint itself. I have not used them though. Good luck and report back! ~Jared On Thu, Jul 24, 2014 at 7:54 PM, Colton Conor <colton.conor at gmail.com> wrote:
What are the recommended settings to successfully implement VoIP over 3G/4G data connection? Assume we are talking about using Polycom phones, and the 3G/4G data connection comes from a Cradlepoint router that is plugged in with AC power and has high gain antennas. The device will be stationary, so we will not have to worry about tower handoffs breaking the connection. This will be for fixed wireless aiming at a cell tower. I assume packet loss will be a big concern as we have no control or QoS abilities. Plus, the speed fluctuates so much.
I have read to use G.729 codec, and TCP for signaling to bypass firewalls. Besides that, what other settings are recommended? Changes in MTU? Changes in voice payload ms? Is there a better codec to use? Header compression?
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://puck.nether.net/pipermail/voiceops/attachments/20140725/65b37464/att...>
+1 on using TCP for traversing many layers of NAT of varying quality + getting around the infantile thumb-sucking that passes for ALG-"assisted" NAT traversal. -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906
Alright notes taken so far is to obtain a static IP with the wireless carrier to avoid their Carrier Grade NAT. We already paid $500 to get static IPs from Verizon, so we are good to go there. In addition use TCP for SIP. I believe we already use TCP for the SIP signaling as we use the TCPpreferred setting on the Polycom VVX line, and our service provider supports TCP with their Acme Packet / Broadsoft setup. Just the signaling is TCP right? The RTP media is still UPD I assume? Of course we would like to use a wideband codec, but I have heard narrowband codecs work better due to less data traffic (which as you know data is expensive on wireless). Looks like G.729 and iLBC are the most supported narrowband codecs today. What are the thoughts about both of these codecs? Which is better? I assume the session border controller or softswitch would transcode the call to G.711 to send it out over the PSTN, so do either of these codecs transcode or sound better when converted to G.711? Are there any other codecs besides these two? I assume we are going to be dealing with alot of packet loss whether its going to 3G or 4G. We are also going to be dealing with high latency on 3G. Since we have no control over both of these issues, what other recommendations do you have? I have heard changing the ptime can help, and certain codes have different ptime settings. I have also read about trying to keep the MTU size down, and using SIP header compression helps. I don't know much about this. Any more advice would be appreciated. On Fri, Jul 25, 2014 at 2:50 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
+1 on using TCP for traversing many layers of NAT of varying quality + getting around the infantile thumb-sucking that passes for ALG-"assisted" NAT traversal.
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 7/27/14 11:14 AM, Colton Conor wrote:
I assume we are going to be dealing with alot of packet loss whether its going to 3G or 4G. We are also going to be dealing with high latency on 3G. Since we have no control over both of these issues, what other recommendations do you have? I have heard changing the ptime can help, and certain codes have different ptime settings. I have also read about trying to keep the MTU size down, and using SIP header compression helps. I don't know much about this.
MTU won't matter for the RTP as those are relatively small packets. Yes, keep the RTP over UDP, I don't even think TCP is an option for it. With your SIP over TCP, fragmentation won't be a problem so I'd not worry about the MTU there either. I'd try the standard 20 ms. ptime and see if you have any issues. Nonstandard ptime values can cause trouble if the other side can't negotiate. You'll likely have some latency due to jitter buffers growing as well as the inherent cellular latency. Echo suppression should be enabled. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
participants (5)
-
abalashov＠evaristesys.com -
colton.conor＠gmail.com -
jared＠compuwizz.net -
jay＠west.net -
paul＠timmins.net