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
>
--
Kristian Kielhofner
_______________________________________________
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
