17 Dec
2012
17 Dec
'12
7:29 p.m.
Apparantly it should be simple to mangle the From in request:
http://kamailio.org/docs/modules/stable/modules_k/uac.html#id2525538
The task at hand is use the prefix 131 to suppress callerid for this call:
if($rU=~"^131[0-9]+$")
{
strip(3);
append_hf("Privacy: id\r\n");
uac_replace_from("anonymous","sip:anonymous@anonymous.invalid:$rp");
uac_replace_to("","sip:$rU@$rd");
}
Just before this replace there is an other uac_replace_from to rewrite an
alphanumeric username to the default callerid for that device. If there are 2
uac_replace_from in the path, things go wrong like below. A uac_restore_from()
before the second uac_replace_from doesn't change this behavior.
device calls 1310123456789:
U 10.0.34.226:1300 -> 10.0.35.226:5060
INVITE sip:1310123456789@kamailio.local:5060 SIP/2.0.
From: <sip:anonymous@10.0.3.44:5060>;tag=26e5ce5850.
To: <sip:1310123456789@kamailio.local:5060>.
Kamailio forwards request to dispatcher but fails to properly replace the from
uri:
U 10.0.35.226:5060 -> 10.0.32.36:5060
INVITE sip:+31123456789@kamailio.local:5060 SIP/2.0.
From: "anonymous" <sip:
+31987654321@10.0.3.44:5060sip:anonymous@anonymous.invalid:5060>;tag=26e5ce5850.
To: <sip:0123456789@kamailio.local>.
Even though the debug log suggests it did the proper replacement:
uac [replace.c:265]: value to store is is '<sip:anonymous@10.0.3.44:5060>'
and
len is '30'
uac [replace.c:268]: Storing in FROM-AVP (for use in reply):
'<sip:anonymous@10.0.3.44:5060>' with len '30'
uac [replace.c:324]: uri to replace [sip:anonymous@10.0.3.44:5060]
uac [replace.c:325]: replacement uri is [sip:anonymous@anonymous.invalid:5060]
uac [replace.c:383]: encode
is=<AAAAAAAAAAAAAAAAAABQXkFeV15BQUcUXF5AUWxpZDo1MDYw> len=48
uac [replace.c:265]: value to store is is
'<sip:1310619024127@kamailio.local:5060>' and len is '54'
uac [replace.c:271]: Storing in TO-AVP (for use in reply):
'<sip:1310123456789@kamailio.local:5060>' with len '54'
uac [replace.c:324]: uri to replace [sip:1310123456789@kamailio.local:5060]
uac [replace.c:325]: replacement uri is [sip:0123456789@kamailio.local]
uac [replace.c:383]: encode
is=<AAAAAAEFAAkGAw0BAANxQlYuERJDCRxeHAoXWgYRXRdbAxtNHxwNCgdACxgubmw6NTA2MA-->
len=72
Kamailio version: kamailio 3.3.2 (x86_64/linux)
(the latest stable debian/squeeze package).
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
18 Dec
18 Dec
10:21 a.m.
Hello,
you have to use it only once -- this is due to how the changes are done
to the sip message headers, but also because of adding a special
parameter to record-route header. It is its well known behavior since
more than 10 years ago.
Wait until you know what is the final version of the header that should
be sent out and then change it. Before that, you can keep it in a config
variable that can be overwritten easily.
Cheers,
Daniel
On 12/17/12 6:29 PM, Daniel Tryba wrote:
Apparantly it should be simple to mangle the From in
request:
http://kamailio.org/docs/modules/stable/modules_k/uac.html#id2525538
The task at hand is use the prefix 131 to suppress callerid for this call:
if($rU=~"^131[0-9]+$")
{
strip(3);
append_hf("Privacy: id\r\n");
uac_replace_from("anonymous","sip:anonymous@anonymous.invalid:$rp");
uac_replace_to("","sip:$rU@$rd");
}
Just before this replace there is an other uac_replace_from to rewrite an
alphanumeric username to the default callerid for that device. If there are 2
uac_replace_from in the path, things go wrong like below. A uac_restore_from()
before the second uac_replace_from doesn't change this behavior.
device calls 1310123456789:
U 10.0.34.226:1300 -> 10.0.35.226:5060
INVITE sip:1310123456789@kamailio.local:5060 SIP/2.0.
From: <sip:anonymous@10.0.3.44:5060>;tag=26e5ce5850.
To: <sip:1310123456789@kamailio.local:5060>.
Kamailio forwards request to dispatcher but fails to properly replace the from
uri:
U 10.0.35.226:5060 -> 10.0.32.36:5060
INVITE sip:+31123456789@kamailio.local:5060 SIP/2.0.
From: "anonymous" <sip:
+31987654321@10.0.3.44:5060sip:anonymous@anonymous.invalid:5060>;tag=26e5ce5850.
To: <sip:0123456789@kamailio.local>.
Even though the debug log suggests it did the proper replacement:
uac [replace.c:265]: value to store is is '<sip:anonymous@10.0.3.44:5060>'
and
len is '30'
uac [replace.c:268]: Storing in FROM-AVP (for use in reply):
'<sip:anonymous@10.0.3.44:5060>' with len '30'
uac [replace.c:324]: uri to replace [sip:anonymous@10.0.3.44:5060]
uac [replace.c:325]: replacement uri is [sip:anonymous@anonymous.invalid:5060]
uac [replace.c:383]: encode
is=<AAAAAAAAAAAAAAAAAABQXkFeV15BQUcUXF5AUWxpZDo1MDYw> len=48
uac [replace.c:265]: value to store is is
'<sip:1310619024127@kamailio.local:5060>' and len is '54'
uac [replace.c:271]: Storing in TO-AVP (for use in reply):
'<sip:1310123456789@kamailio.local:5060>' with len '54'
uac [replace.c:324]: uri to replace [sip:1310123456789@kamailio.local:5060]
uac [replace.c:325]: replacement uri is [sip:0123456789@kamailio.local]
uac [replace.c:383]: encode
is=<AAAAAAEFAAkGAw0BAANxQlYuERJDCRxeHAoXWgYRXRdbAxtNHxwNCgdACxgubmw6NTA2MA-->
len=72
Kamailio version: kamailio 3.3.2 (x86_64/linux)
(the latest stable debian/squeeze package).
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
12:44 p.m.
On Tuesday 18 December 2012 09:21:24 Daniel-Constantin Mierla wrote:
you have to use it only once -- this is due to how the
changes are done
to the sip message headers, but also because of adding a special
parameter to record-route header. It is its well known behavior since
more than 10 years ago.
It is so well known that it isn't documented. May I suggest to add this to the
module usage, would have saved me some time wondering what was happening :)
I'll change the config to suggested method.
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
4:01 p.m.
Hello,
On 12/18/12 11:44 AM, Daniel Tryba wrote:
On Tuesday 18 December 2012 09:21:24 Daniel-Constantin
Mierla wrote:
it is
the public secret :-)
Feel free to submit a patch with the improvements you want in the
documentation. Wiki is also open for contributions, there you just need
to create yourself an account and start a tutorial about this behaviour.
Perhaps an entry in FAQ would be good as well.
Cheers,
Daniel
you have to use it only once -- this is due to
how the changes are done
to the sip message headers, but also because of adding a special
parameter to record-route header. It is its well known behavior since
more than 10 years ago.
It is so well known that it isn't documented. May I
suggest to add this to the
module usage, would have saved me some time wondering what was happening :)
I'll change the config to suggested method.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
20 Dec
20 Dec
11:33 a.m.
18 dec 2012 kl. 11:44 skrev Daniel Tryba <daniel(a)pocos.nl>nl>:
On Tuesday 18 December 2012 09:21:24 Daniel-Constantin
Mierla wrote:
Trying to update the docs. Does this apply to all uac_replace functions?
/O
you have to use it only once -- this is due to
how the changes are done
to the sip message headers, but also because of adding a special
parameter to record-route header. It is its well known behavior since
more than 10 years ago.
It is so well known that it isn't documented. May I suggest to add this to the
module usage, would have saved me some time wondering what was happening :)
I'll change the config to suggested method.
12:54 p.m.
On 12/20/12 10:33 AM, Olle E. Johansson wrote:
18 dec 2012 kl. 11:44 skrev Daniel Tryba
<daniel(a)pocos.nl>nl>:
yes.
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On Tuesday 18 December 2012 09:21:24
Daniel-Constantin Mierla wrote:
Trying to update the docs. Does
this apply to all uac_replace functions?
you have to use it only once -- this is due to
how the changes are done
to the sip message headers, but also because of adding a special
parameter to record-route header. It is its well known behavior since
more than 10 years ago.
It is so well known that it isn't documented. May I
suggest to add this to the
module usage, would have saved me some time wondering what was happening :)
I'll change the config to suggested method.
4358
days inactive
4361
days old
5 comments
3 participants
participants (3)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Olle E. Johansson