[SIP Beyond VoIP] STUN keep-alive

Mon Jan 16 17:17:08 CET 2012

I tried to use the nat_traversal module from the OpenSIPS server but it
doesn't seem to work as expected. NAT bindings are not kept and a ngrep ran
on the server reveals this message

U 2012/01/16 10:18:43.418275 69.61.11.18:5060 -> 69.61.11.18:5060
REGISTER sip:69.61.11.18 SIP/2.0.
Via: SIP/2.0/UDP 69.61.11.18;branch=z9hG4bK06ff.55dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.45dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.35dd34d5.0.
Via: SIP/2.0/UDP 
74.228.12.88:5060;received=74.228.12.88;branch=z9hG4bK-3a253e4d;rport=49155.
From: reneconn11 <sip:reneconn11 at 69.61.11.18>;tag=4b13105c96b7ff53o0.
To: reneconn11 <sip:reneconn11 at 69.61.11.18>.
Call-ID: b3dcc82d-c538c0db at 192.168.1.6.
CSeq: 87929 REGISTER.
Max-Forwards: 67.
Contact: reneconn11 <sip:reneconn11 at 74.228.12.88:5060;nat=yes>;expires=240.
User-Agent: Linksys/PAP2-3.1.9(LSc).
Content-Length: 0.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
Supported: x-sipura.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.

And the message keeps growing like this:

U 2012/01/16 10:18:43.421649 69.61.11.18:5060 -> 69.61.11.18:5060
REGISTER sip:69.61.11.18 SIP/2.0.
Via: SIP/2.0/UDP 69.61.11.18;branch=z9hG4bK06ff.37dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.27dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.17dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.07dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.f6dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.e6dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.d6dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.c6dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.b6dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.a6dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.96dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.86dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.76dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.66dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.56dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.46dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.36dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.26dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.16dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.06dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.f5dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.e5dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.d5dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.c5dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.b5dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.a5dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.95dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.85dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.75dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.65dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.55dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.45dd34d5.0.
Via: SIP/2.0/UDP 
69.61.11.18;rport=5060;received=69.61.11.18;branch=z9hG4bK06ff.35dd34d5.0.
Via: SIP/2.0/UDP 
74.228.12.88:5060;received=74.228.12.88;branch=z9hG4bK-3a253e4d;rport=49155.
From: reneconn11 <sip:reneconn11 at 69.61.11.18>;tag=4b13105c96b7ff53o0.
To: reneconn11 <sip:reneconn11 at 69.61.11.18>.
Call-ID: b3dcc82d-c538c0db at 192.168.1.6.
CSeq: 87929 REGISTER.
Max-Forwards: 37.
Contact: reneconn11 <sip:reneconn11 at 74.228.12.88:5060;nat=yes>;expires=240.
User-Agent: Linksys/PAP2-3.1.9(LSc).
Content-Length: 0.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
Supported: x-sipura.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
P-hint: outbound.
.

Where 69.61.11.18 is the server's ip address. Configurations for keep-alive
are:
modparam("nat_traversal", "keepalive_interval", 90)
modparam("nat_traversal", "keepalive_method", "OPTIONS")
modparam("nat_traversal", "keepalive_from", "sip:keepalive at budtobud.com")

...

if ((method=="REGISTER" || method=="SUBSCRIBE" ||
     (method=="INVITE"&&  !has_totag()))&&  client_nat_test("3"))
{
     nat_keepalive();
}

On the other hand, before using sipsimple, I used pjsip and apparently pjsua
manages to keep the NAT bindings alive by periodically sending a UDP packet
to the opensips server and in turn, the opensips server sends periodically
at a lower rate some OPTIONS messages. Here is part of the ngrep dump:

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
.

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
.

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
.

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
.

#
U 69.61.11.18:5060 -> 192.168.33.166:5060
OPTIONS sip:82.79.96.20:52567 SIP/2.0.
Via: SIP/2.0/UDP 69.61.11.18:5060;branch=0.
From: sip:pinger at budtobud.com;tag=66edd3e2.
To: sip:82.79.96.20:52567.
Call-ID: bb3e1ee4-fc959124-28c at 69.61.11.18.
CSeq: 1 OPTIONS.
Content-Length: 0.
.

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 69.61.11.18:5060;received=69.61.11.18;branch=0.
Call-ID: bb3e1ee4-fc959124-28c at 69.61.11.18.
From: <sip:pinger at budtobud.com>;tag=66edd3e2.
To: <sip:82.79.96.20>;tag=0.
CSeq: 1 OPTIONS.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS.
Accept: application/sdp, application/pidf+xml, application/xpidf+xml,
application/simple-message-summary, message/sipfrag;version=2.0,
application/im-iscomposing+xml, text/plain.
Supported: replaces, 100rel, timer, norefersub.
Allow-Events: presence, message-summary, refer.
User-Agent: PJSUA v1.10.0 Darwin-10.8/i386.
Content-Type: application/sdp.
Content-Length:   478.
.
v=0.
o=- 3535716756 3535716756 IN IP4 192.168.33.166.
s=pjmedia.
c=IN IP4 192.168.33.166.
t=0 0.
m=audio 4000 RTP/AVP 10 98 97 106 3 0 8 10 99 96.
a=rtcp:4001 IN IP4 192.168.33.166.
a=rtpmap:10 L16/44100/2.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:106 iLBC/8000.
a=fmtp:106 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:10 G722/44100/2.
a=rtpmap:99 speex/32000.
a=sendrecv.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
.

My questions now are how do I get sipsimple to send that UDP packet to the
server? And also why does the server apparently send the keep-alive messages
to himslef?

On 1/16/12 1:41 PM, "Luci Stanescu" <luci at cnix.ro> wrote:

> 
> On 16 Jan 2012, at 11:03, Mihai Richard wrote:
> 
>> This might work. Now I'm just asking if there are some other messages that I
>> can send to the server to keep the NAT binding and still not require much
>> processing from the server. If not, I'm going ahead and lowering the
>> registration interval.
> 
> 
> You can try it out to see if this makes it work, but keep in mind there are
> some important preconditions:
>   * the client must a single port for all SIP messages (both sending and
> receiving).
>   * there must be a single entry point IP address, protocol and port to the
> provider network (i.e. if the provider has multiple proxies, this will work
> for receiving incoming calls but other transactions might use another proxy =>
> those binding will likely expire)
> 
> As for the load put on the server, it's true, it's a horrible waste just for
> NAT traversal. You can technically send anything, which should make all NAT
> boxes keep the binding alive. But if you use OpenSIPS, give the nat_traversal
> module a try. It's the best point capable of detecting whether there's a NAT
> box in between the user and the proxy. Can't really think of a simple way a
> client could reliably do it.
> 
> Kind Regards,
> 
> --
> Luci Stanescu
> 