Pangolin, a problem with the SIP stack…Solved…

In a previous post, I’ve talked about a large scale VoIP system, so the client decided to use a customized version of Pangolin from PortSIP, but it had a slight problem…

If the user won’t use STUN, he can login to the SBC, but when making a call, it’s one way audio…

If the user uses STUN, he can’t login at all…

However, using the same configuration on eyeBeam, everything works well, registration as well as two-way audio…

So it was clear that there’s something that doesn’t work well with Pangolin, However, working closely with them, we were able to solve the problem…

This is how it’s done…

I jumped right away to dumping the packet flow from everywhere…

The most complete overview comes from the SBC’s side, check this out:

Pangolin – no STUN (Logs in OK):

19:09:56.582651 IP client.public.IP.6481 > server.IP.sip: SIP, length: 731
REGISTER sip:sbc.xxxxx.com SIP/2.0
Via: SIP/2.0/UDP 172.21.6.6:6481;branch=z9hG4bK-d8754z-f93d942a0b22ef0d-1—d8754z-;rport
Max-Forwards: 70
Contact: <sip:7131457@172.21.6.6:6481;rinstance=3921e46b44e39628>
To: <sip:7131457@sbc.xxxxx.com>
From: <sip:7131457@sbc.xxxxx.com>;tag=547be95d
Call-ID: OTZlZTNlZWY1ZDhhMTBmZDM0MDJkYTE5YjgwYzUzOWU.
CSeq: 3 REGISTER
Expires: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
Supported: replaces
User-Agent: XXXXXX v4.0, Build 19032009
Authorization: Digest username="7131457",realm="huawei",nonce="8d39814df21cb41c37acec312a8c96e8",uri="sip:sbc.xxxxx.com",response="110d736e84bb0e280196c45586225674",algorithm=MD5
Content-Length: 0

19:09:56.628787 IP server.IP.sip > client.public.IP.6481: SIP, length: 480
SIP/2.0 401 Unauthorized
From:  <sip:7131457@sbc.xxxxx.com>;tag=547be95d
To:  <sip:7131457@sbc.xxxxx.com>;tag=f565b515
Via: SIP/2.0/UDP 172.21.6.6:6481;branch=z9hG4bK-d8754z-f93d942a0b22ef0d-1—d8754z-;rport=6481;received=client.public.IP
CSeq: 3 REGISTER
Call-ID: OTZlZTNlZWY1ZDhhMTBmZDM0MDJkYTE5YjgwYzUzOWU.
WWW-Authenticate: Digest realm="huawei",
          nonce="7492279b864ef4f0610e5f10268fe85c", domain="sip:huawei.com",
          stale=false, algorithm=MD5
Content-Length: 0

But when trying to make a call it’s one way audio because of this:

19:19:17.221654 IP client.publi.ip.6410 > server.ip.sip: SIP, length: 847
INVITE sip:0018002255345@sbc.xxxxxx.com SIP/2.0
Via: SIP/2.0/UDP 172.21.6.6:6410;branch=z9hG4bK-d8754z-ac0cd4217632096c-1—d8754z-;rport
Max-Forwards: 70
Contact: <sip:7131457@172.21.6.6:6410>
To: <sip:0018002255345@sbc.xxxxxx.com>
From: <sip:7131457@sbc.xxxxxx.com>;tag=292e267a
Call-ID: MjQzOTkxODFhYjYwNWFmZDE1NWZlMmFiZTQ4YTgyYzU.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: XXXXX v4.0, Build 19032009
Content-Length: 286
v=0
o=- 68249598 68249598 IN IP4 172.21.6.6
s=http://www.portsip.com
c=IN IP4 172.21.6.6
t=0 0
m=audio 20318 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=fmtp:101 0-15

So using STUN:

Pangolin – with STUN (doesn’t log in):

16:57:46.084836 IP client.public.ip.5166 > server.public.ip.sip: SIP, length: 556
REGISTER sip:sbc.xxxxxx.com SIP/2.0
Via: SIP/2.0/UDP client.public.ip:5166;branch=z9hG4bK-d8754z-bd5b421537000563-1—d8754z-;rport
Max-Forwards: 70
Contact: <sip:7132580@172.21.6.6:5166;rinstance=2cbedb5e57eff1c6>
To: <sip:7132580@sbc.xxxxxx.com>
From: <sip:7132580@sbc.xxxxxx.com>;tag=225cc801
Call-ID: NTM4ZTMwMWQwZDFlYjIxNThjODQ4YTgwODAxOTY5Mjc.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
Supported: replaces
User-Agent: USmile v4.0, Build 122808
Content-Length: 0

16:57:46.124199 IP server.public.ip.sip-tls > client.public.ip.5166: UDP, length 484
SIP/2.0 401 Unauthorized
From:  <sip:7132580@sbc.xxxxxx.com>;tag=225cc801
To:  <sip:7132580@sbc.xxxxxx.com>;tag=6bf9dfdc
Via: SIP/2.0/UDP client.public.ip:5166;branch=z9hG4bK-d8754z-bd5b421537000563-1—d8754z-;rport=5166;received=client.public.ip
CSeq: 1 REGISTER
Call-ID: NTM4ZTMwMWQwZDFlYjIxNThjODQ4YTgwODAxOTY5Mjc.
WWW-Authenticate: Digest realm="huawei",
          nonce="0ae230f22ff2df6f06239cb556624950", domain="sip:huawei.com",
          stale=false, algorithm=MD5
Content-Length: 0

16:57:46.284900 IP client.public.ip > server.public.ip: ICMP client.public.ip udp port 5166 unreachable, length 520
SIP/2.0 401 Unauthorized
From:  <sip:7132580@sbc.xxxxxx.com>;tag=225cc801
To:  <sip:7132580@sbc.xxxxxx.com>;tag=6bf9dfdc
Via: SIP/2.0/UDP client.public.ip:5166;branch=z9hG4bK-d8754z-bd5b421537000563-1—d8754z-;rport=5166;received=client.public.ip
CSeq: 1 REGISTER
Call-ID: NTM4ZTMwMWQwZDFlYjIxNThjODQ4YTgwODAxOTY5Mjc.
WWW-Authenticate: Digest realm="huawei",
          nonce="0ae230f22ff2df6f06239cb556624950", domain="sip:huawei.com",
          stale=false, algorithm=MD5
Content-Length: 0

Notice the ICMP unreachable sent from my router back to the server, and the SIP reply from the server never makes it back to my machine…

eyeBeam – with STUN (can log in):

19:25:00.944298 IP client.public.ip.60620 > server.ip.sip: SIP, length: 568
REGISTER sip:sbc.xxxxxx.com SIP/2.0
Via: SIP/2.0/UDP 172.21.6.6:60620;branch=z9hG4bK-d87543-8c096666725f0a78-1–d87543-;rport
Max-Forwards: 70
Contact: <sip:7132580@client.public.ip:60620;rinstance=8ff26c1d2819b7d2>
To: "7132580"<sip:7132580@sbc.xxxxxx.com>
From: "7132580"<sip:7132580@sbc.xxxxxx.com>;tag=761c7b15
Call-ID: bf4fae6c9916cc61NDczNTUyOWRhNjQzNDFkZWVmNzE1Nzg1Y2NjODBhYTU.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 0

19:25:00.952486 IP server.ip.sip > client.public.ip.60620: SIP, length: 515
SIP/2.0 401 Unauthorized
From: "7132580" <sip:7132580@sbc.xxxxxx.com>;tag=761c7b15
To: "7132580" <sip:7132580@sbc.xxxxxx.com>;tag=aaefeb14
Via: SIP/2.0/UDP 172.21.6.6:60620;branch=z9hG4bK-d87543-8c096666725f0a78-1–d87543-;rport=60620;received=client.public.ip
CSeq: 1 REGISTER
Call-ID: bf4fae6c9916cc61NDczNTUyOWRhNjQzNDFkZWVmNzE1Nzg1Y2NjODBhYTU.
WWW-Authenticate: Digest realm="huawei",
          nonce="fd3fedf4320172597e4e344cdbb71a8f", domain="sip:huawei.com",
          stale=false, algorithm=MD5
Content-Length: 0

And can make two way audio calls because of this:

19:26:26.514388 IP client.public.ip.60620 > server.ip.sip: SIP, length: 812
INVITE sip:0018002255345@sbc.xxxxxx.com SIP/2.0
Via: SIP/2.0/UDP 172.21.6.6:60620;branch=z9hG4bK-d87543-7b34dd2ff71c1c5b-1–d87543-;rport
Max-Forwards: 70
Contact: <sip:7132580@client.public.ip:60620>
To: "0018002255345"<sip:0018002255345@sbc.xxxxxx.com>
From: "7132580"<sip:7132580@sbc.xxxxxx.com>;tag=5e72e35a
Call-ID: 5115742fbd255055NDczNTUyOWRhNjQzNDFkZWVmNzE1Nzg1Y2NjODBhYTU.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 231
v=0
o=- 2 2 IN IP4 client.public.ip
s=CounterPath eyeBeam 1.5
c=IN IP4 client.public.ip
t=0 0
m=audio 13770 RTP/AVP 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:55520DF4D26E4F079578A10C55CA0985

So, my conclusion was this:

It seems to be a bug in the SIP stack implementation in Pangolin that makes it insert the IP discovered by STUN in the VIA headers in its SIP packets:

Via: SIP/2.0/UDP client.public.ip:5442;branch=z9hG4bK-d8754z-cf6596349410ca56-1---d8754z-;rport=5442;received=client.public.ip

Unlike eyeBeam, which inserts the IP discovered by STUN only in the RTP traffic headers, and keeps the internal IP in the VIA headers:

Via: SIP/2.0/UDP 172.21.6.6:7970;branch=z9hG4bK-d87543-7d24f94ef9211a66-1--d87543-;rport

These headers enable NAT firewalls to properly redirect the incoming UDP packets back to its rightful destination, but when it can't it replies with an ICMP unreachable packet...

This causes the Pangolin registration to fail while configured with STUN, but succeeds with eyeBeam…

Working closely with them, my contact with them was Marc, they have worked on my suggestions, and made Pangolin behave like eyeBeam…

Now Pangolin sends the internal IP in the VIA header, and send the IP discovered by STUN only while make a call in its proper location in the headers…

I must thank the guys in PortSIP for their amazing co-operation…Nowevery thing seems to be working OK, however, we still have some test cases to run and to test the entire system, end-to-end…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: