20 Dec
2005
20 Dec
'05
1:08 p.m.
Hi,
Does OpenSER support sequentially processing the same
reply by several onreply routes, i.e.
route
{
# general case - have all replies processed by
# onreply_route[1]
t_on_reply("1");
if (mycondition)
{
# special case - these replies should be processed
# by onreply_route[1] _and_ by onreply_route[2]
t_on_reply("2");
}
t_relay();
}
onreply_route[1]
{
#
append_hf("P-MyExtraInfo: xyz\r\n");
}
onreply_route[2]
{
# do some extra processing here
}
I did not find any info on this topic in the docs. Imho
the ability to use trigger several onreply_routes for
sequential processing can help extremly in keeping code
clean and readable.
Assume a proxy that is required, e.g., to insert a
new header field into _any_ reply. In addition, some
other replies need some extra handling in the onreply
route. Without the capability to trigger multiple
onreply-routes this leads to many conditionals in either
the main route or in the reply route(s).
Thanks in advance,
--Joachim
20 Dec
20 Dec
1:53 p.m.
Hello,
it is possible to arm only one onreply_route. In the case you use two
times t_on_reply(), the latest is used. To solve your case, the solution
is to set some flags, and based on that to call different routes from
onreply_route.
Cheers,
Daniel
On 12/20/05 14:08, Joachim Fabini wrote:
Hi,
Does OpenSER support sequentially processing the same
reply by several onreply routes, i.e.
route
{
# general case - have all replies processed by
# onreply_route[1]
t_on_reply("1");
if (mycondition)
{
# special case - these replies should be processed
# by onreply_route[1] _and_ by onreply_route[2]
t_on_reply("2");
}
t_relay();
}
onreply_route[1]
{
#
append_hf("P-MyExtraInfo: xyz\r\n");
}
onreply_route[2]
{
# do some extra processing here
}
I did not find any info on this topic in the docs. Imho
the ability to use trigger several onreply_routes for
sequential processing can help extremly in keeping code
clean and readable.
Assume a proxy that is required, e.g., to insert a
new header field into _any_ reply. In addition, some
other replies need some extra handling in the onreply
route. Without the capability to trigger multiple
onreply-routes this leads to many conditionals in either
the main route or in the reply route(s).
Thanks in advance,
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
4:04 p.m.
Hi Daniel,
it is possible to arm only one onreply_route. In the
case you use two
times t_on_reply(), the latest is used.
Ooops, I was expecting this reply. I suggest to document this
in the Openser docs...
To solve your case, the solution
is to set some flags, and based on that to call different routes from
onreply_route.
Of course, it's feasible. BUT: the conditionals/flags in the
main route require duplication of code in the reply_routes -
I'd like to avoid this.
I fully understand that at the moment there are tasks of
higher importance to complete. But at the same time I believe
that in the long run multiple reply-routes can help to
significantly reduce script complexity. What do you think?
Thanks for your reply,
best regards
--Joachim
PS: A sample to illustrate practically what I'm talking
about. Imagine the following scenario: action
block A (possibly consisting of tens of loc) is required
for all replies except for replies on Cancel and Ack.
Action block B for all invites, C for all subscribes.
Currently this requires the following code:
route
{
# Nesting required, otherwise we overwrite our previous
# route setting
if (!((method=="ACK")||(method=="CANCEL")))
{
if (method=="INVITE")
{
t_on_reply("1");
}
else
{
if (method=="SUBSCRIBE")
{
t_on_reply("2");
}
else
{
t_on_reply("3");
}
}
}
# some other processing
t_relay();
}
onreply_route[1]
{
A;
B;
}
onreply_route[2]
{
A;
C;
}
onreply_route[3]
{
A;
}
If several reply-routes can be triggered, the code becomes
the following - imho much more readable and clear:
route
{
# No nesting required
if (!((method=="ACK")||(method=="CANCEL")))
{
t_on_reply("3");
}
if (method=="INVITE")
{
t_on_reply("1");
}
if (method=="SUBSCRIBE")
{
t_on_reply("2");
}
# some other processing
t_relay();
}
onreply_route[1]
{
# we get rid of code duplication A #1
B;
}
onreply_route[2]
{
# we get rid of code duplication A #2
C;
}
onreply_route[3]
{
A;
}
Cheers,
Daniel
On 12/20/05 14:08, Joachim Fabini wrote:
Hi,
Does OpenSER support sequentially processing the same
reply by several onreply routes, i.e.
route
{
# general case - have all replies processed by
# onreply_route[1]
t_on_reply("1");
if (mycondition)
{
# special case - these replies should be processed
# by onreply_route[1] _and_ by onreply_route[2]
t_on_reply("2");
}
t_relay();
}
onreply_route[1]
{
#
append_hf("P-MyExtraInfo: xyz\r\n");
}
onreply_route[2]
{
# do some extra processing here
}
I did not find any info on this topic in the docs. Imho
the ability to use trigger several onreply_routes for
sequential processing can help extremly in keeping code
clean and readable.
Assume a proxy that is required, e.g., to insert a
new header field into _any_ reply. In addition, some
other replies need some extra handling in the onreply
route. Without the capability to trigger multiple
onreply-routes this leads to many conditionals in either
the main route or in the reply route(s).
Thanks in advance,
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
5:42 p.m.
On 12/20/05 17:04, Joachim Fabini wrote:
you can define several route[x] which can be called from different
points of onreply_route. In this way the duplicated code is reduced a lot.
Cheers,
Daniel
Hi Daniel,
it is now in tm readme.
it is possible to arm only one onreply_route. In
the case you use two
times t_on_reply(), the latest is used.
Ooops, I was expecting this reply. I suggest to document this
in the Openser docs...
To solve your case, the solution
is to set some flags, and based on that to call different routes from
onreply_route.
Of course, it's feasible. BUT: the conditionals/flags in the
main route require duplication of code in the reply_routes -
I'd like to avoid this.
I fully understand that at the moment there are tasks of
higher importance to complete. But at the same time I believe
that in the long run multiple reply-routes can help to
significantly reduce script complexity. What do you think?
Thanks for your reply,
best regards
--Joachim
PS: A sample to illustrate practically what I'm talking
about. Imagine the following scenario: action
block A (possibly consisting of tens of loc) is required
for all replies except for replies on Cancel and Ack.
Action block B for all invites, C for all subscribes.
Currently this requires the following code:
route
{
# Nesting required, otherwise we overwrite our previous
# route setting
if (!((method=="ACK")||(method=="CANCEL")))
{
if (method=="INVITE")
{
t_on_reply("1");
}
else
{
if (method=="SUBSCRIBE")
{
t_on_reply("2");
}
else
{
t_on_reply("3");
}
}
}
# some other processing
t_relay();
}
onreply_route[1]
{
A;
B;
}
onreply_route[2]
{
A;
C;
}
onreply_route[3]
{
A;
}
If several reply-routes can be triggered, the code becomes
the following - imho much more readable and clear:
route
{
# No nesting required
if (!((method=="ACK")||(method=="CANCEL")))
{
t_on_reply("3");
}
if (method=="INVITE")
{
t_on_reply("1");
}
if (method=="SUBSCRIBE")
{
t_on_reply("2");
}
# some other processing
t_relay();
}
onreply_route[1]
{
# we get rid of code duplication A #1
B;
}
onreply_route[2]
{
# we get rid of code duplication A #2
C;
}
onreply_route[3]
{
A;
}
Cheers,
Daniel
On 12/20/05 14:08, Joachim Fabini wrote:
> Hi,
>
> Does OpenSER support sequentially processing the same
> reply by several onreply routes, i.e.
>
> route
> {
> # general case - have all replies processed by
> # onreply_route[1]
> t_on_reply("1");
>
> if (mycondition)
> {
> # special case - these replies should be processed
> # by onreply_route[1] _and_ by onreply_route[2]
> t_on_reply("2");
> }
> t_relay();
> }
>
> onreply_route[1]
> {
> #
> append_hf("P-MyExtraInfo: xyz\r\n");
> }
>
> onreply_route[2]
> {
> # do some extra processing here
> }
>
> I did not find any info on this topic in the docs. Imho
> the ability to use trigger several onreply_routes for
> sequential processing can help extremly in keeping code
> clean and readable.
> Assume a proxy that is required, e.g., to insert a
> new header field into _any_ reply. In addition, some
> other replies need some extra handling in the onreply
> route. Without the capability to trigger multiple
> onreply-routes this leads to many conditionals in either
> the main route or in the reply route(s).
>
> Thanks in advance,
> --Joachim
>
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>
5:07 p.m.
Hi Joachim!
You can use a default reply route:
onreply_route {
# default onreply_route
...
}
AFAIK this will be exectued for every response.
regards
klaus
Joachim Fabini wrote:
Hi,
Does OpenSER support sequentially processing the same
reply by several onreply routes, i.e.
route
{
# general case - have all replies processed by
# onreply_route[1]
t_on_reply("1");
if (mycondition)
{
# special case - these replies should be processed
# by onreply_route[1] _and_ by onreply_route[2]
t_on_reply("2");
}
t_relay();
}
onreply_route[1]
{
#
append_hf("P-MyExtraInfo: xyz\r\n");
}
onreply_route[2]
{
# do some extra processing here
}
I did not find any info on this topic in the docs. Imho
the ability to use trigger several onreply_routes for
sequential processing can help extremly in keeping code
clean and readable.
Assume a proxy that is required, e.g., to insert a
new header field into _any_ reply. In addition, some
other replies need some extra handling in the onreply
route. Without the capability to trigger multiple
onreply-routes this leads to many conditionals in either
the main route or in the reply route(s).
Thanks in advance,
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6989
days inactive
6989
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Joachim Fabini -
Klaus Darilion