I quickly checked the code and the condition is on nat_bflag, do you set it as well? The config snipped you presented tells about sipping_bflag.

Otherwise I see the last-keepalive is updated. I assume the expire time from the registration is higher than 180 sec.

If all above are ok in your config and environment, I will have to do some tests to see if I can reproduce.

Daniel

On 20/02/14 00:13, Kristian Kielhofner wrote:
Yes, before and after my client stops responding to OPTIONS.  Both
Last-Keepalive and Last-Modified do not change:

Last-Keepalive:: 1392851434
Last-Modified:: 1392851424

On Wed, Feb 19, 2014 at 5:41 PM, Daniel-Constantin Mierla
<mico...@gmail.com> wrote:
Hello,

should be ok -- feature is not enabled for db-only mode.

If you do:

kamctl ul show

is the Last-Keepalive set to a positive value?

Cheers,
Daniel


On 19/02/14 23:30, Kristian Kielhofner wrote:
Hi Daniel,

    modparam("usrloc", "db_mode", 2)

On Wed, Feb 19, 2014 at 5:26 PM, Daniel-Constantin Mierla
<mico...@gmail.com> wrote:
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:pin...@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@4.2.2.2:5060;ob SIP/2.0.
Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
From: sip:pin...@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-93072f43-7c4cf55@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@4.2.2.1.
From: <sip:pin...@domain.com>;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: <sip:user372@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@4.2.2.2:5060;ob SIP/2.0.
Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
From: sip:pin...@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-b3072f43-f35cf55@4.2.2.1.
CSeq: 1 OPTIONS.
Content-Length: 0.
.

U 4.2.2.1:5060 -> 4.2.2.2:5060
OPTIONS sip:user372@4.2.2.2:5060;ob SIP/2.0.
Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
From: sip:pin...@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-c3072f43-b75cf55@4.2.2.1.
CSeq: 1 OPTIONS.
Content-Length: 0.
.

U 4.2.2.1:5060 -> 4.2.2.2:5060
OPTIONS sip:user372@4.2.2.2:5060;ob SIP/2.0.
Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
From: sip:pin...@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-d3072f43-7b5cf55@4.2.2.1.
CSeq: 1 OPTIONS.
Content-Length: 0.
.

U 4.2.2.1:5060 -> 4.2.2.2:5060
OPTIONS sip:user372@4.2.2.2:5060;ob SIP/2.0.
Via: SIP/2.0/UDP 4.2.2.1:5060;branch=0.
From: sip:pin...@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-e3072f43-3f5cf55@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


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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




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


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to