[SIP Beyond VoIP] FW: STUN keep-alive

Tue Jan 17 09:43:59 CET 2012

In this case, from the sipsimple's interface point of view, how do I make it
periodically send that UDP packet to the server? I expect to have some kind
of setting for that but I don't know what it is.

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
.

#
U 192.168.33.166:5060 -> 69.61.11.18:5060
.

These are the UDP packets shown by ngrep. Apparently the client just sends 1
byte at a time and in return the server sends an OPTIONS message.

Regards,
Mihai Richard

On 1/16/12 6:21 PM, "Adrian Georgescu" <ag at ag-projects.com> wrote:

> The nat_traversal module works just fine.
> 
> It looks like you have a SIP ALG router that breaks your SIP traffic. Try to
> disable it, google for 'SIP ALG'.
> 
> Adrian
> 
> On Jan 16, 2012, at 5:17 PM, Mihai Richard wrote:
> 
>> 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
>>> 
>> 
>> 
>> _______________________________________________
>> SIPBeyondVoIP mailing list
>> SIPBeyondVoIP at lists.ag-projects.com
>> http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip
>> 
> 

------ End of Forwarded Message