18 Sep
2003
18 Sep
'03
11:37 a.m.
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
18 Sep
18 Sep
2:48 p.m.
On Sep 18, 2003 at 09:37, Jakob Schlyter <jakob(a)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
20 Sep
20 Sep
1:59 a.m.
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
11:01 a.m.
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
1:32 p.m.
On Sat, 20 Sep 2003, Juha Heinanen 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#).
jakob
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. 
21 Sep
21 Sep
2:26 a.m.
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.
3:20 a.m.
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
2:04 a.m.
On 20-09 10:01, Juha Heinanen wrote:
Jakob Schlyter writes:
Yes, that would be possible. Is there any particular case (except the
one mentioned in this thread) you need it for ?
Jan.
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?
11:28 a.m.
Jan Janak writes:
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
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 ?
1:08 p.m.
On Sep 21, 2003 at 00:04, Jan Janak <jan(a)iptel.org> wrote:
On 20-09 10:01, Juha Heinanen wrote:
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
Jakob Schlyter writes:
Yes, that would be possible. Is there any particular case (except the
one mentioned in this thread) you need it for ? 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?
2:07 a.m.
On 19-09 23:59, Jakob Schlyter wrote:
On Thu, 18 Sep 2003, Andrei Pelinescu-Onciul wrote:
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.
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?
7723
days inactive
7726
days old
10 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Jakob Schlyter -
Jan Janak -
Juha Heinanen