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).
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).
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.
Hello,
On 12/18/12 11:44 AM, Daniel Tryba wrote:
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 :)
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
I'll change the config to suggested method.
18 dec 2012 kl. 11:44 skrev Daniel Tryba daniel@pocos.nl:
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.
Trying to update the docs. Does this apply to all uac_replace functions?
/O
On 12/20/12 10:33 AM, Olle E. Johansson wrote:
18 dec 2012 kl. 11:44 skrev Daniel Tryba daniel@pocos.nl:
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.
Trying to update the docs. Does this apply to all uac_replace functions?
yes.
Daniel
-
Daniel Tryba -
Daniel-Constantin Mierla -
Olle E. Johansson