20 Feb
2014
20 Feb
'14
12:03 a.m.
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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
From: <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-e3072f43-3f5cf55(a)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!
--
Kristian Kielhofner
20 Feb
20 Feb
12:26 a.m.
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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
From: <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-e3072f43-3f5cf55(a)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
12:30 a.m.
Hi Daniel,
modparam("usrloc", "db_mode", 2)
On Wed, Feb 19, 2014 at 5:26 PM, Daniel-Constantin Mierla
<miconda(a)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:
--
Kristian Kielhofner
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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
From: <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-e3072f43-3f5cf55(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:41 a.m.
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(a)gmail.com> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
From: <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-e3072f43-3f5cf55(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:13 a.m.
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(a)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:
--
Kristian Kielhofner
Hi Daniel,
modparam("usrloc", "db_mode", 2)
On Wed, Feb 19, 2014 at 5:26 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
From: <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
To: sip:user372@4.2.2.2:5060;ob.
Call-ID: 8af79586-e3072f43-3f5cf55(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:28 a.m.
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(a)gmail.com> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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(a)gmail.com> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
> To: sip:user372@4.2.2.2:5060;ob.
> Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
> From: <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
> To: sip:user372@4.2.2.2:5060;ob.
> Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
> To: sip:user372@4.2.2.2:5060;ob.
> Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
> To: sip:user372@4.2.2.2:5060;ob.
> Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
> To: sip:user372@4.2.2.2:5060;ob.
> Call-ID: 8af79586-e3072f43-3f5cf55(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:51 a.m.
I do, but only when endpoints are actually behind NAT :).
If I set my nat_bflag manually (in all cases) it behaves as expected.
It seems that with modparam("nathelper", "ping_nated_only", 0) set my
configuration should work without always also setting nat_bflag (as
that is used in various other places currently).
What do you think?
On Wed, Feb 19, 2014 at 6:28 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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:
--
Kristian Kielhofner
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(a)gmail.com> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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(a)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@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-9627292.
>> To: sip:user372@4.2.2.2:5060;ob.
>> Call-ID: 8af79586-93072f43-7c4cf55(a)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(a)4.2.2.1.
>> From:
>> <sip:pinger@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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-b627292.
>> To: sip:user372@4.2.2.2:5060;ob.
>> Call-ID: 8af79586-b3072f43-f35cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-c627292.
>> To: sip:user372@4.2.2.2:5060;ob.
>> Call-ID: 8af79586-c3072f43-b75cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-d627292.
>> To: sip:user372@4.2.2.2:5060;ob.
>> Call-ID: 8af79586-d3072f43-7b5cf55(a)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:pinger@domain.com;tag=uloc-5303810e-7c78-1-2273f0eb-e627292.
>> To: sip:user372@4.2.2.2:5060;ob.
>> Call-ID: 8af79586-e3072f43-3f5cf55(a)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(a)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
2:14 a.m.
Hello Kristian,
On 02/19/2014 06:51 PM, Kristian Kielhofner wrote:
It seems that with modparam("nathelper",
"ping_nated_only", 0) set my
configuration should work without always also setting nat_bflag (as
that is used in various other places currently).
Seemingly, yes. From nh_timer:
rval = ul.get_all_ucontacts(buf, cblen,
(ping_nated_only?ul.nat_flag:0),
((unsigned int)(unsigned
long)timer_idx)*natping_interval+iteration,
natping_processes*natping_interval);
The implication being that if ping_nated_only is < 1, contacts to ping
are not filtered by the usrloc NAT flag. It did strike me as interesting
that the usrloc API field is called 'nat_flag', but the usrloc modparam
is called 'nat_bflag', but usrloc.c clearly reveals that they are one
and the same:
unsigned int nat_flag; /*! nat_flag module parameter */
api->nat_flag = nat_bflag;
And the filter in get_all_mem_ucontacts() does apply the flags argument:
if ((c->cflags & flags) != flags)
continue;
But it seems to me that it might not match if there are any other UL
flags set besides the nat_bflag, e.g.
#define POWPOW (1 << 1)
#define PINGPONG (1 << 2)
int flags = 0;
flags |= PINGPONG;
if((flags & POWPOW) != POWPOW)
printf("Problem?\n");
sasha@tambourine:~$ ./ns
Problem?
Are there other UL contact flags that could be in use here and breaking
this comparison in get_all_mem_ucontacts()?
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
2:16 a.m.
On 02/19/2014 07:14 PM, Alex Balashov wrote:
On 02/19/2014 06:51 PM, Kristian Kielhofner wrote:
if((flags & POWPOW) != POWPOW)
printf("Problem?\n");
sasha@tambourine:~$ ./ns
Problem?
Are there other UL contact flags that could be in use here and breaking
this comparison in get_all_mem_ucontacts()?
Well, scratch that thought. If the 'flags' value being passed to
get_all_mem_ucontacts() is 0, bitwise ANDing with 0 will always yield 0,
even if there are other bits set.
So, that's not it. Hmm.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
2:23 a.m.
Okay, so maybe someone who knows the usrloc code better can correct me
on this, but I get the impression that the part of the code that ages
the contact out if a keepalive reply has not been received is dependent
on nat_bflag being set, regardless of the value of the 'ping_nated_only'
modparam.
Back to get_all_mem_ucontacts():
if ((c->cflags & flags) != flags)
continue;
if(ul_keepalive_timeout>0 && c->last_keepalive>0)
{
if((c->cflags & nat_bflag) != 0 &&
c->sock!=NULL
&& c->sock->proto==PROTO_UDP)
{
if(c->last_keepalive+ul_keepalive_timeout <
tnow)
{
/* set contact as expired in 10s */
if(c->expires > tnow + 10)
c->expires = tnow + 10;
continue;
}
}
}
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
12:15 p.m.
Hello,
I removed the restriction on nat_bflag (in master and 4.1 branches).
Can anyone test to see if all goes fine even for non-natted contacts?
Cheers,
Daniel
On 20/02/14 01:23, Alex Balashov wrote:
Okay, so maybe someone who knows the usrloc code
better can correct me
on this, but I get the impression that the part of the code that ages
the contact out if a keepalive reply has not been received is
dependent on nat_bflag being set, regardless of the value of the
'ping_nated_only' modparam.
Back to get_all_mem_ucontacts():
if ((c->cflags & flags) != flags)
continue;
if(ul_keepalive_timeout>0 && c->last_keepalive>0)
{
if((c->cflags & nat_bflag) != 0 &&
c->sock!=NULL
&& c->sock->proto==PROTO_UDP)
{
if(c->last_keepalive+ul_keepalive_timeout < tnow)
{
/* set contact as expired in 10s */
if(c->expires > tnow + 10)
c->expires = tnow + 10;
continue;
}
}
}
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
1:36 p.m.
Hi Daniel,
I re-tested with your latest commit and it works as expected with my
current configuration (with nat_bflag unset in my case).
Thanks!
On Thu, Feb 20, 2014 at 5:15 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
I removed the restriction on nat_bflag (in master and 4.1 branches).
Can anyone test to see if all goes fine even for non-natted contacts?
Cheers,
Daniel
On 20/02/14 01:23, Alex Balashov wrote:
--
Kristian Kielhofner
Okay, so maybe someone who knows the usrloc code better can correct me on
this, but I get the impression that the part of the code that ages the
contact out if a keepalive reply has not been received is dependent on
nat_bflag being set, regardless of the value of the 'ping_nated_only'
modparam.
Back to get_all_mem_ucontacts():
if ((c->cflags & flags) != flags)
continue;
if(ul_keepalive_timeout>0 && c->last_keepalive>0)
{
if((c->cflags & nat_bflag) != 0 &&
c->sock!=NULL
&& c->sock->proto==PROTO_UDP)
{
if(c->last_keepalive+ul_keepalive_timeout < tnow)
{
/* set contact as expired in 10s */
if(c->expires > tnow + 10)
c->expires = tnow + 10;
continue;
}
}
}
--
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3928
days inactive
3929
days old
11 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Kristian Kielhofner