[SR-Users] Issues with keepalive_timeout
Daniel-Constantin Mierla
miconda at gmail.com
Thu Feb 20 00:28:00 CET 2014
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
> <miconda at 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
>>> <miconda at 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: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
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at 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
More information about the sr-users
mailing list