VoIP News OnSIP News Developer News

In Depth: Verizon Blocks SIP Traffic Using ALG

by Eric Phipps

As one of the largest mobile broadband carriers in the country, Verizon appears to be intentionally blocking SIP traffic on their 4G LTE network.

Published: July 2, 2013

As one of the largest mobile broadband carriers in the country, the Verizon 4G LTE network is used by a sizable portion of the VoIP population. Unfortunately, it appears that Verizon is intentionally blocking SIP traffic on their 4G LTE network. Verizon is currently operating a network level SIP ALG which blocks 3rd party SIP Registrations at worst, and hinders functionality at best. Our NOC Technicians Eric Phipps and Dave Jodhan sat down to document the ALG in action.

Attempts to use a Samsung Galaxy in mobile hotspot form would find that all SIP registration packets receive a Server Error 500 response back from our servers. Yet our server would never receive the initial registration request, and it didn’t send the response. We rooted a Droid Razr and found that in mobile hotspot form a device could register, but the SIP ALG still overwrote packets intended for our registration servers at sip.onsip.com. Here is what we found through our investigation.

<code>

root@cdma_spyder:/proc/net # netcfg
rmnet1   UP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;                              10.190.163.225/31  0x000000c3 [MAC ADDRESS]
wlan1    UP &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;                               192.168.43.1/24  0x00001043 [MAC ADDRESS]

</code>

All devices that connect to the mobile hotspot receive an IP address in the 192.168.43.X space. So we believe that wlan1 is the wireless lan NIC and that rmnet1, the only other viable NIC, is the endpoint which connects to Verizon’s wireless network.

<code>

root@cdma_spyder:/proc/net # ip route show

default via 10.190.163.226 dev rmnet1
10.190.163.224/31 dev rmnet1  proto kernel  scope link  src 10.190.163.225
10.190.163.226 dev rmnet1  scope link
162.115.235.245 via 10.190.163.226 dev rmnet1
192.168.43.0/24 dev wlan1  proto kernel  scope link  src 192.168.43.1 

</code>

So all traffic eventually routes out from the phone to the Verizon network to 10.190.163.226.

We were able to run Shark for Root, a packet capturing program for Android based on TCPDump, a popular networking tool designed to capture and display packets for use in troubleshooting.

Here is what we found:

The packets coming from the Razr are being manipulated by a SIP ALG somewhere in the network. In many instances, this SIP ALG refuses to allow devices to register at all, which effectively prevents any 3rd Party SIP applications from functioning over the Mobile Broadband Platform. In other instances, it would manipulate the packets yet still allow the devices to register.

Below is a ladder diagram and packet trace:

SIP ladder diagram with OnSIP

Packet 1 Initial Registration Request: As sent by Droid Razr

<code>

REGISTER sip:junctionnetworks.com SIP/2.0
Via: SIP/2.0/UDP 10.179.6.254:33820;rport;branch=z9hG4bKPjHG8bC-2HqJ5ADOFpeCoJtWhXx2ZYcZ9Z
Route: &lt;sip:199.7.173.100;lr&gt;
Max-Forwards: 70
From: &lt;sip:dave@junctionnetworks.com&gt;;tag=hbZRnsoQ6nVA9fUazL7rED39-ZZ6Qy91
To: &lt;sip:dave@junctionnetworks.com&gt;
Call-ID: HF6nQJKnFjMqqZ-YAwffJONxbs6GJwV9
CSeq: 58593 REGISTER
User-Agent: CSipSimple_cdma_spyder-16/r2225
Contact: &lt;sip:dave@10.179.6.254:33820;ob&gt;
Expires: 900
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length:  0

</code>

Packet 2 Initial Registration Request: As received by sip.onsip.com

<code>

<font color="red">2013-06-20 14:16:33.187285
70.192.69.224:8227 -> 199.7.173.100:5060
REGISTER sip:junctionnetworks.com SIP/2.0
Via: SIP/2.0/UDP 70.192.69.224:8227;rport;branch=z9hG4bK+aca90011c180b5631299b7ac9201cf401+s196+1
From: &lt;sip:dave@junctionnetworks.com&gt;;tag=s196+1+51190007+432e0bf
Route: &lt;sip:199.7.173.100;lr&gt;
Max-Forwards: 70
To: &lt;sip:dave@junctionnetworks.com&gt;
Call-ID: HF6nQJKnFjMqqZ-YAwffJONxbs6GJwV9
CSeq: 58593 REGISTER
User-Agent: CSipSimple_cdma_spyder-16/r2225
Contact: &lt;sip:dave@70.192.69.224:8227;ob&gt;
Expires: 900
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0</font color>

</code>

Packet 3 401 Unauthorized Challenge: As sent by sip.onsip.com

<code>

2013-06-20 14:16:33.188234
199.7.173.100:5060 -> 70.192.69.224:8227
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 70.192.69.224:8227;received=70.192.69.224;rport=8227;branch=z9hG4bK+aca90011c180b5631299b7ac9201cf401+s196+1
From: &lt;sip:dave@junctionnetworks.com&gt;;tag=s196+1+51190007+432e0bf
To: &lt;sip:dave@junctionnetworks.com&gt;;tag=9d079adf30be9ee6222f98d845a8175e.398b
Call-ID: HF6nQJKnFjMqqZ-YAwffJONxbs6GJwV9
CSeq: 58593 REGISTER
WWW-Authenticate: Digest realm="jnctn.net", nonce="51c30edf00009e69d24d1f37cd7796083dec52fabf9c2a58", qop="auth"
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0

</code>

Packet 4 401 Unauthorized Challenge: As received by Droid Razr

<code>

<font color="red">SIP/2.0 401 Unauthorized
Warning: 399 sipalg "Unauthorized"
Call-ID: HF6nQJKnFjMqqZ-YAwffJONxbs6GJwV9
CSeq: 58593 REGISTER
From: &lt;sip:dave@junctionnetworks.com&gt;;tag=hbZRnsoQ6nVA9fUazL7rED39-ZZ6Qy91
To: &lt;sip:dave@junctionnetworks.com&gt;;tag=s196+1+51190007+577a6772
Via: SIP/2.0/UDP 10.179.6.254:33820;received=10.179.6.254;rport=33820;branch=z9hG4bKPjHG8bC-2HqJ5ADOFpeCoJtWhXx2ZYcZ9Z
WWW-Authenticate: Digest realm="jnctn.net", nonce="51c30edf00009e69d24d1f37cd7796083dec52fabf9c2a58", qop="auth"
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0</font color>

</code>

Going through the packet you can see several instances where the SIP packets are altered on the Verizon network before they arrive in their new form at our proxy.

A close look at the packets reveals some major rewriting before it reaches our network.

For Packet 1 and Packet 2:

1) the order of the Headers has been changed

2) the Via header has been completely rewritten

<code>

- Via: SIP/2.0/UDP 10.179.6.254:33820;rport;branch=z9hG4bKPjHG8bC-2HqJ5ADOFpeCoJtWhXx2ZYcZ9Z

<font color="red">- Via: SIP/2.0/UDP 70.192.69.224:8227;rport;branch=z9hG4bK+aca90011c180b5631299b7ac9201cf401+s196+1</font color>

</code>

3) the 'tag' parameter on the From header has been rewritten

<code>

- From: &lt;sip:dave@junctionnetworks.com&gt;;tag=hbZRnsoQ6nVA9fUazL7rED39-ZZ6Qy91

<font color="red">- From: &lt;sip:dave@junctionnetworks.com&gt;;tag=s196+1+51190007+432e0bf</font color>

</code>

An ALG has clearly rewritten the entire REGISTER request packet.

For Packet 3 and Packet 4:

1) the order of the Headers has been changed

2) the Via header has been completely rewritten

<code>
<p style="margin:0; padding:0;">- Via: SIP/2.0/UDP 70.192.69.224:8227;received=70.192.69.224;rport=8227;branch=z9hG4bK+aca90011c180b5631299b7ac9201cf401+s196+1
<p style="margin:0; padding:0;"><font color="red">- Via: SIP/2.0/UDP 10.179.6.254:33820;received=10.179.6.254;rport=33820;branch=z9hG4bKPjHG8bC-2HqJ5ADOFpeCoJtWhXx2ZYcZ9Z</font color>

</code>

3) the 'tag' parameter on the From header has been rewritten

<code>
<p style="margin:0; padding:0;">- From: &lt;sip:dave@junctionnetworks.com&gt;;tag=s196+1+51190007+432e0bf
<p style="margin:0; padding:0;"><font color="red">- From: &lt;sip:dave@junctionnetworks.com&gt;;tag=hbZRnsoQ6nVA9fUazL7rED39-ZZ6Qy91</font color>

</code>

4) the 'tag' parameter on the To header has been rewritten

<code>
<p style="margin:0; padding:0;">- To: &lt;sip:dave@junctionnetworks.com&gt;;tag=9d079adf30be9ee6222f98d845a8175e.398b
<p style="margin:0; padding:0;"><font color="red">- To: &lt;sip:dave@junctionnetworks.com&gt;;tag=s196+1+51190007+577a6772</font color>

</code>

5) a Warning header has been added

<code>

<font color="red">- Warning: 399 sipalg "Unauthorized"</font color>

</code>

An ALG has clearly rewritten the entire 401 response packet.

In conclusion, Verizon’s mobile broadband has a SIP ALG. For many different devices, the SIP ALG does not even allow 3rd Party registrations through the mobile hotspot network, yet with one device, the Droid Razr, the registrations go through. We could find no commonality in the devices which do not allow registrations as the LTE Router is totally different from the Galaxy SIII and Galaxy Nexus.

Here is a capture from a Macbook Pro attempting to register Bria 3 for OSX using a Nexus to connect the Verizon Mobile Broadband Network

<code>

REGISTER sip:junctionnetworks.com SIP/2.0
Via: SIP/2.0/UDP 192.168.43.252:4146;branch=z9hG4bK-d8754z-bc4391497de56e29-1---d8754z-;rport
Max-Forwards: 70
Contact: &lt;sip:eric.phipps@70.192.78.11:2089;rinstance=2f759981fbdab3bb;transport=udp&gt;
To: "Eric Phipps"&lt;sip:eric.phipps@junctionnetworks.com&gt;
From: "Eric Phipps"&lt;sip:eric.phipps@junctionnetworks.com&gt;;tag=52f83737
Call-ID: ZGJlNzM1NGEwMTNjOTU2NzcxZDhlYTJmMzY2MmQzMzQ
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: Bria 3 release 3.5.1 stamp 69732
Content-Length: 0

SIP/2.0 500 Server Internal Error
Warning: 399 sipalg "Internal Error"
Call-ID: ZGJlNzM1NGEwMTNjOTU2NzcxZDhlYTJmMzY2MmQzMzQ
CSeq: 1 REGISTER
From: "Eric Phipps"&lt;sip:eric.phipps@junctionnetworks.com&gt;;tag=52f83737
To: "Eric Phipps" &lt;sip:eric.phipps@junctionnetworks.com&gt;;tag=s146+1+44760001+62d9510e
Via: SIP/2.0/UDP 192.168.43.252:4146;received=70.192.78.11;rport=2089;branch=z9hG4bK-d8754z-bc4391497de56e29-1---d8754z-
Content-Length: 0

</code>

In this instance the SIP ALG does not even allow the traffic to reach our servers but instead inserts itself into the registration process and blocks the traffic inserting the “Warning: 399 sipalg” message in the response packet. We found this same behaviour through the Verizon 4G LTE router, Galaxy SIII and Nexus phones all using the same configuration.

For these reasons, we do not recommend using Verizon mobile broadband for anyone looking to use the OnSIP hosted PBX platform. We ourselves continue to use AT&T’s mobile broadband for demo purposes.

For more on SIP and tools for SIP developers, click here.