[SR-Users] Issues with keepalive_timeout

[Daniel-Constantin Mierla]

Hello,

quick check -- what is the db_mode for usrloc module?

Cheers,
Daniel

On 19/02/14 23:03, Kristian Kielhofner wrote:
> Hello All,
>
>    I'm trying to use keepalive_timeout with 4.1.1 as described here:
>
> http://lists.sip-router.org/pipermail/sr-users/2012-August/074337.html
>
>    I believe I've followed these configuration steps and those defined
> in the nathelper module.
>
> Here are the relevant portions of my config:
>
> modparam("nathelper", "natping_interval", 60)
> modparam("nathelper", "keepalive_timeout", 180)
> modparam("nathelper", "ping_nated_only", 0)
> modparam("nathelper", "sipping_from", "sip:pinger at domain.com")
> modparam("nathelper", "sipping_method", "OPTIONS")
> modparam("nathelper", "sipping_bflag", 9)
>
> And of course a setting the correct branch flag (verified) during
> REGISTER handling:
>
> setbflag(9);
>
> My goal is to use SIP OPTIONS messages to verify the reachability of
> all of my endpoints (not just NATd ones).  I would just lower my
> re-registration timeout but there are other issues associated with
> that kind of change.
>
> With my current configuration (after a successful registration) a SIP
> OPTIONS message is sent and replied to:
>
> U 4.2.2.1:5060 -> 4.2.2.2:5060
> OPTIONS sip:user372 at 4.2.2.2:5060;ob SIP/2.0.
> Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
> From: sip:pinger at domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
> To: sip:user372 at 4.2.2.2:5060;ob.
> Call-ID: 8af79586-93072f43-7c4cf55 at 4.2.2.1.
> CSeq: 1 OPTIONS.
> Content-Length: 0.
> .
>
> U 4.2.2.2:5060 -> 4.2.2.1:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 4.2.2.1:5060;received=4.2.2.1;branch=0.
> Call-ID: 8af79586-93072f43-7c4cf55 at 4.2.2.1.
> From: <sip:pinger at domain.com>;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
> To: <sip:user372 at 4.2.2.2:5060>;tag=0;ob.
> CSeq: 1 OPTIONS.
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, 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: My_UA.
> Content-Length:  0.
> .
>
> If I kill the registered UA (making it unavailable) Kamailio endlessly
> sends OPTIONS messages, never receives a reply, and never removes the
> registration from usrloc:
>
> U 4.2.2.1:5060 -> 4.2.2.2:5060
> OPTIONS sip:user372 at 4.2.2.2:5060;ob SIP/2.0.
> Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
> From: sip:pinger at domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
> To: sip:user372 at 4.2.2.2:5060;ob.
> Call-ID: 8af79586-b3072f43-f35cf55 at 4.2.2.1.
> CSeq: 1 OPTIONS.
> Content-Length: 0.
> .
>
> U 4.2.2.1:5060 -> 4.2.2.2:5060
> OPTIONS sip:user372 at 4.2.2.2:5060;ob SIP/2.0.
> Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
> From: sip:pinger at domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
> To: sip:user372 at 4.2.2.2:5060;ob.
> Call-ID: 8af79586-c3072f43-b75cf55 at 4.2.2.1.
> CSeq: 1 OPTIONS.
> Content-Length: 0.
> .
>
> U 4.2.2.1:5060 -> 4.2.2.2:5060
> OPTIONS sip:user372 at 4.2.2.2:5060;ob SIP/2.0.
> Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
> From: sip:pinger at domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
> To: sip:user372 at 4.2.2.2:5060;ob.
> Call-ID: 8af79586-d3072f43-7b5cf55 at 4.2.2.1.
> CSeq: 1 OPTIONS.
> Content-Length: 0.
> .
>
> U 4.2.2.1:5060 -> 4.2.2.2:5060
> OPTIONS sip:user372 at 4.2.2.2:5060;ob SIP/2.0.
> Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
> From: sip:pinger at domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
> To: sip:user372 at 4.2.2.2:5060;ob.
> Call-ID: 8af79586-e3072f43-3f5cf55 at 4.2.2.1.
> CSeq: 1 OPTIONS.
> Content-Length: 0.
> .
>
> (and on, and on, and...)
>
> Eventually the registration timeout kicks in, the usrloc entry is
> removed, and Kamailio stops sending OPTIONS to the (long) unreachable
> endpoint.
>
> Is this expected behavior?  What am I doing wrong?
>
> Thanks!
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda