10 Nov
2008
10 Nov
'08
7:06 p.m.
Hello
I am having an issue handling UN-REGISTERs.
This is my config file:
route{
xlog("L_INFO", "mylog: starting_main_logic.\n");
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
xlog("L_INFO","mylog: Too Many Hops.\n");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
xlog("L_INFO","mylog: Message too big.\n");
exit;
};
if (!method=="REGISTER") {
xlog("L_INFO","mylog: Recording Route. Method:
[$rm].\n");
record_route();
}
if (loose_route()) {
# mark routing logic in request
xlog("L_INFO","mylog: Loose Route section. Method:
[$rm].\n");
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (uri==myself) {
if (method=="REGISTER" &&
(!search("expires=0"))) {
xlog("L_INFO","mylog: starting to process
REGISTER.Info: [$au].\n");
if (!www_authorize("", "subscriber")) {
xlog("L_INFO","mylog: REGISTER came without
auth, sending challenge.\n");
www_challenge("", "0");
exit;
};
save("location");
xlog("L_INFO","mylog: save-location
successful.\n");
exit;
} else if (method=="INVITE") {
xlog("L_INFO","mylog: Processing INVITE.\n");
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","mylog: INVITE came without
auth, sending challenge.\n");
proxy_challenge("","0");
exit;
};
consume_credentials();
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
xlog("L_INFO","mylog: lookup-location failed, sending 404
Not Found. Method: [$rm].\n");
exit;
};
append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
route[1] {
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (t_relay()) {
xlog("L_INFO","mylog: Route 1 section. Method
[$rm].");
} else {
sl_reply_error();
xlog("L_INFO","mylog: Route 1 section. T_Relay failed.
Method [$rm].");
};
exit;
}
I added the "&& (!search("expires=0"))" to make sure that only
the REGISTER requests will be processed by the next lines and the AOR will be saved in
those cases.
The X-lite sends "expires=0" in the Contact HF when it is unregistering.
This is how the processing of a REGISTER looks like as per my code:
Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic.
Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting to process
REGISTER.Info: [<null>].
Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: REGISTER came without auth,
sending challenge.
Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic.
Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting to process
REGISTER.Info: [101].
Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: save-location successful.
and when the phone UN-REGISTERs this is what I see:
Nov 10 12:33:17 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic.
Nov 10 12:33:17 sp1094a ../../sbin/kamailio[26069]: mylog: lookup-location failed, sending
404 Not Found. Method: [REGISTER].
My question is, do I need to use the lookup section for REGISTERs and UN-REGISTERs?
If I comment out that part this is how the log looks like:
#if (!lookup("location")) {
# sl_send_reply("404", "Not Found");
# xlog("L_INFO","mylog: lookup-location failed, sending 404
Not Found. Method: [$rm].\n");
# exit;
#};
log:
the 1st part [REGISTER] looks the same
[root@sp1094a kamailio]# tail -f /var/log/kamailio_logs | grep mylog
Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting to process
REGISTER.Info: [<null>].
Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: REGISTER came without auth,
sending challenge.
Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting to process
REGISTER.Info: [101].
Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: save-location successful.
and this is what the log shows when the phone is UN-REGISTERING
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method
[REGISTER].
Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic.
Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Message too big.
[root@sp1094a kamailio]#
Regards
Fabian
_________________________________________________________________
Stay up to date on your PC, the Web, and your mobile phone with Windows Live
http://clk.atdmt.com/MRT/go/119462413/direct/01/
11 Nov
11 Nov
7:41 p.m.
On Monday 10 November 2008, Fabian Borot wrote:
I am having an issue handling UN-REGISTERs.
This is my config file:
route{
[..]
if (uri==myself) {
if (method=="REGISTER" &&
(!search("expires=0"))) {
if (!www_authorize("", "subscriber")) {
www_challenge("", "0");
exit;
};
save("location");
xlog("L_INFO","mylog: save-location
successful.\n");
exit;
}
[..]
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
xlog("L_INFO","mylog: lookup-location failed, sending 404
Not Found. Method: [$rm].\n"); exit;
};
append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
I added the "&& (!search("expires=0"))" to make sure that
only the REGISTER
requests will be processed by the next lines and the AOR will be saved in
those cases. The X-lite sends "expires=0" in the Contact HF when it is
unregistering. This is how the processing of a REGISTER looks like as per
my code:
Hi Fabian,
somehow the search(..) does not match, so the REGISTER case is not used for
unregistrations. My twinkle e.g. uses uppercase at the beginning in certain
cases, you only match for lower case at the moment. But instead of changing
the match i'd just let the registrar handle this in save(). It should work
just fine.
Unregistration requests are then proceeded by the lookup, and of course no
contact is found for this URI. If you comment the lookup block out, you'll
get a loop, as its visible from the log below.
[..]
../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43
sp1094a ../../sbin/kamailio[26203]: mylog: Message too big.
Cheers,
Henning
9:19 p.m.
txs Henning, the search() works, that block only matches REGISTERs, but my point was
whether the lookup() function makes sense or not for handling REGISTERs [ I see it in some
tutorials, I am a beginner to kamailio by the way]
as far as handling UN-REGISTRATIONs, would save() fit there as well? should I do something
special to handle the UN-REGISTRATION or kamailio should know that should remove the AOR
automaticall when it sees the "expires=0" in the Contact HF?
also, I see the loop but do not understand why it happens.
regards
Fabian
From: henning.westerholt(a)1und1.de
To: users(a)lists.kamailio.org
Subject: Re: [Kamailio-Users] question about register
Date: Tue, 11 Nov 2008 18:41:17 +0100
CC: fborot(a)hotmail.com
On Monday 10 November 2008, Fabian Borot wrote:
_________________________________________________________________
Windows Live Hotmail now works up to 70% faster.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…
I am having an issue handling UN-REGISTERs.
This is my config file:
route{
[..]
if (uri==myself) {
if (method=="REGISTER" &&
(!search("expires=0"))) {
if (!www_authorize("", "subscriber")) {
www_challenge("", "0");
exit;
};
save("location");
xlog("L_INFO","mylog: save-location
successful.\n");
exit;
}
[..]
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
xlog("L_INFO","mylog: lookup-location failed, sending 404
Not Found. Method: [$rm].\n"); exit;
};
append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
I added the "&& (!search("expires=0"))" to make sure that
only the REGISTER
requests will be processed by the next lines and the AOR will be saved in
those cases. The X-lite sends "expires=0" in the Contact HF when it is
unregistering. This is how the processing of a REGISTER looks like as per
my code:
Hi Fabian,
somehow the search(..) does not match, so the REGISTER case is not used for
unregistrations. My twinkle e.g. uses uppercase at the beginning in certain
cases, you only match for lower case at the moment. But instead of changing
the match i'd just let the registrar handle this in save(). It should work
just fine.
Unregistration requests are then proceeded by the lookup, and of course no
contact is found for this URI. If you comment the lookup block out, you'll
get a loop, as its visible from the log below.
[..]
../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43
sp1094a ../../sbin/kamailio[26203]: mylog: Message too big.
Cheers,
Henning
12 Nov
12 Nov
10:09 a.m.
On Tue, November 11, 2008 8:19 pm, Fabian Borot wrote:
txs Henning, the search() works, that block only matches REGISTERs, but my
point was whether the lookup() function makes sense or not for handling
REGISTERs [ I see it in some tutorials, I am a beginner to kamailio by the
way]
as far as handling UN-REGISTRATIONs, would save() fit there as well?
should I do something special to handle the UN-REGISTRATION or kamailio
should know that should remove the AOR automaticall when it sees the
"expires=0" in the Contact HF?
also, I see the loop but do not understand why it happens.
Hi Fabian,
using the lookup function makes no sense for REGISTERs. An incoming INVITE
is targeted to some user(a)sip.domain, so you need to do the lookup() to be
able deliver the INVITE to your user. But the REGISTER is targeted to
sip.domain, e.g. your servers, which should just handle them.
The save() does all the work for you, it also handles unregistrations,
error handling related to REGISTERs and so on.You don't need to handle it
specially.
The loop happens as the unregistration is not handled by your save() path
in the config (probably because of the wrong check), so the server try to
forward it. The destination was not changed, so it will end up on your
server again, and again..
I'll later take a look to the docs of the save() function, perhaps this
should be explained a little bit better.
Henning
1:52 p.m.
thank you a lot Henning, your explanation makes perfect sense.
Date: Wed, 12 Nov 2008 09:09:05 +0100
Subject: RE: [Kamailio-Users] question about register
From: henning.westerholt(a)1und1.de
To: fborot(a)hotmail.com
CC: henning.westerholt(a)1und1.de; users(a)lists.kamailio.org
On Tue, November 11, 2008 8:19 pm, Fabian Borot wrote:
_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…
txs Henning, the search() works, that block only matches REGISTERs, but my
point was whether the lookup() function makes sense or not for handling
REGISTERs [ I see it in some tutorials, I am a beginner to kamailio by the
way]
as far as handling UN-REGISTRATIONs, would save() fit there as well?
should I do something special to handle the UN-REGISTRATION or kamailio
should know that should remove the AOR automaticall when it sees the
"expires=0" in the Contact HF?
also, I see the loop but do not understand why it happens.
Hi Fabian,
using the lookup function makes no sense for REGISTERs. An incoming INVITE
is targeted to some user(a)sip.domain, so you need to do the lookup() to be
able deliver the INVITE to your user. But the REGISTER is targeted to
sip.domain, e.g. your servers, which should just handle them.
The save() does all the work for you, it also handles unregistrations,
error handling related to REGISTERs and so on.You don't need to handle it
specially.
The loop happens as the unregistration is not handled by your save() path
in the config (probably because of the wrong check), so the server try to
forward it. The destination was not changed, so it will end up on your
server again, and again..
I'll later take a look to the docs of the save() function, perhaps this
should be explained a little bit better.
Henning
5860
days inactive
5862
days old
4 comments
2 participants
participants (2)
-
Fabian Borot -
Henning Westerholt