hi,
I'm trying to get the Remote-Party-ID stuff to play with anonymous calls. here is a snipplet of what I'm trying to do:
modparam("auth", "rpid_suffix", ";party=calling;id-type=subscriber;screen=yes")
...
if (is_present_hf("Remote-Party-ID")) { xlog("L_INFO", "Removing existing Remote-Party-ID from %fu\n"); remove_hf("Remote-Party-ID"); }; append_rpid_hf(); if (search("From:.*Anonymous")) { search_append("Remote-Party-ID:.*;screen=yes", ";privacy=on"); } else { search_append("Remote-Party-ID:.*;screen=yes", ";privacy=off"); };
however, this does not seem to work. is the rpid really added to the message at when requested or actually later (at transmit) ?
jakob
On Sep 18, 2003 at 09:37, Jakob Schlyter jakob@rfc.se wrote:
hi,
I'm trying to get the Remote-Party-ID stuff to play with anonymous calls. here is a snipplet of what I'm trying to do:
modparam("auth", "rpid_suffix", ";party=calling;id-type=subscriber;screen=yes")
...
if (is_present_hf("Remote-Party-ID")) { xlog("L_INFO", "Removing existing Remote-Party-ID from %fu\n"); remove_hf("Remote-Party-ID"); }; append_rpid_hf(); if (search("From:.*Anonymous")) { search_append("Remote-Party-ID:.*;screen=yes", ";privacy=on"); } else { search_append("Remote-Party-ID:.*;screen=yes", ";privacy=off"); };
however, this does not seem to work. is the rpid really added to the message at when requested or actually later (at transmit) ?
At transmit. Amost all the stuff that gets added will show up only at transmit time (you will see the original message, one exception is uri processing -- you'll always see the modified uri). The ideea is to keep the original message and a set of diffs to it (struct lump). This "diffs" will be applied only on transmit. This will speed things up quite a bit.
Andrei
On Thu, 18 Sep 2003, Andrei Pelinescu-Onciul wrote:
At transmit. Amost all the stuff that gets added will show up only at transmit time (you will see the original message, one exception is uri processing -- you'll always see the modified uri). The ideea is to keep the original message and a set of diffs to it (struct lump). This "diffs" will be applied only on transmit. This will speed things up quite a bit.
would it make sense to have a sync() function that applies the diffs to the original message?
or, to solve my specific problem, have a append_rpid_hf() that can take an argument specifying what rpid suffix to add.
jakob
Jakob Schlyter writes:
would it make sense to have a sync() function that applies the diffs to the original message?
may there could be a set of textops that operate on the lumps instead of the original message?
or, to solve my specific problem, have a append_rpid_hf() that can take an argument specifying what rpid suffix to add.
that is do is return from radius not just the uri, but also the necessary parameters, e.g. sip:+358441234567@foo.com;privacy=full
in case the user doesn't want the calling number to show up. ser.cfg is thus not involved with this.
-- juha
On Sat, 20 Sep 2003, Juha Heinanen wrote:
or, to solve my specific problem, have a append_rpid_hf() that can take an argument specifying what rpid suffix to add.
that is do is return from radius not just the uri, but also the necessary parameters, e.g. sip:+358441234567@foo.com;privacy=full
in case the user doesn't want the calling number to show up. ser.cfg is thus not involved with this.
there is sometimes a need to set the privacy parameter at runtime, e.g. the user might want to select the level of privacy when the number is dialed (in sweden we do this in the PSTN with a special prefix, #31#).
jakob
On 20-09 11:32, Jakob Schlyter wrote:
there is sometimes a need to set the privacy parameter at runtime, e.g. the user might want to select the level of privacy when the number is dialed (in sweden we do this in the PSTN with a special prefix, #31#).
I made a quick change and turned rpid_prefix and rpid_suffix parameters into parameters of append_rpid_hf function. That will allow you to specify different prefix and suffix in every call to the function from the script.
This will allow you to do something like this:
if (number begins with #31#) { append_rpid_hf("prefix", "suffix with privacy"); } else { append_rpid_hf("prefix", "suffix witout privacy"); };
NOTE: The patch is against the stable release and I didn't test it !
let me know if it works, Jan.
On Sun, 21 Sep 2003, Jan Janak wrote:
I made a quick change and turned rpid_prefix and rpid_suffix parameters into parameters of append_rpid_hf function. That will allow you to specify different prefix and suffix in every call to the function from the script.
yes, this is very useful.
NOTE: The patch is against the stable release and I didn't test it ! let me know if it works, Jan.
works perfectly. I suggest we add this to -current!
I ended up doing something like this:
if (search("From:.*Anonymous")) { append_rpid_hf("<sip:+", "@zettou.net>;party=calling;id-type=subscriber;privacy=on;screen=yes"); } else { append_rpid_hf("<sip:+", "@zettou.net>;party=calling;id-type=subscriber;privacy=off;screen=yes"); };
very nice. thanks!
jakob
On 20-09 10:01, Juha Heinanen wrote:
Jakob Schlyter writes:
would it make sense to have a sync() function that applies the diffs to the original message?
may there could be a set of textops that operate on the lumps instead of the original message?
Yes, that would be possible. Is there any particular case (except the one mentioned in this thread) you need it for ?
Jan.
Jan Janak writes:
may there could be a set of textops that operate on the lumps instead of the original message?
Yes, that would be possible. Is there any particular case (except the one mentioned in this thread) you need it for ?
nothings comes into mind right now, but i remember once thinking above it for some old problem.
what i need now is add new diversion header before existing ones (if any) added earlier by ser.cfg or that exist in the original request. is that possible with current append header functions?
-- juha
On Sep 21, 2003 at 00:04, Jan Janak jan@iptel.org wrote:
On 20-09 10:01, Juha Heinanen wrote:
Jakob Schlyter writes:
would it make sense to have a sync() function that applies the diffs to the original message?
may there could be a set of textops that operate on the lumps instead of the original message?
Yes, that would be possible. Is there any particular case (except the one mentioned in this thread) you need it for ?
No, that would be extremely complicated. You would have to deal with things like "=5060" (the lump added for rport), the conditional lumps, the lumps that get expanded to the send ip address, port or protocol a.s.o. We would end up with a very complicated api. Unless there is a _very_ compelling reason, I don't want to think about this :-) If someone wants to play with the lumps, he should do it from a module (and not from the script). Different lumps cand be identified by their type (e.g via lumps).
Andrei
On 19-09 23:59, Jakob Schlyter wrote:
On Thu, 18 Sep 2003, Andrei Pelinescu-Onciul wrote:
At transmit. Amost all the stuff that gets added will show up only at transmit time (you will see the original message, one exception is uri processing -- you'll always see the modified uri). The ideea is to keep the original message and a set of diffs to it (struct lump). This "diffs" will be applied only on transmit. This will speed things up quite a bit.
would it make sense to have a sync() function that applies the diffs to the original message?
No, that is not possible until you know the socket through which the message will be sent. The reason is that there are so-called "conditional" lumps which say: "Put the IP of the outgoing interface here" but they don't contain the IP. You don't know the IP during the script processing.
One feasible solution is what Juha mentioned, i.e. a set of operations that can modify the diffs.
Jan.
-
Andrei Pelinescu-Onciul -
Jakob Schlyter -
Jan Janak -
Juha Heinanen