18 Oct
2005
18 Oct
'05
9 p.m.
Hi again,
Having solved the previous topic using Bogdan's hint
I stumbled straight into a new problem. Is there a
workaround for not being able to use the avp-ops
from onreply_route?
Some details on the reason: We implement the Service-
Route extension according to RFC 3608. The registrar
returns in the 200OK a ServiceRoute header where all
proxies on the (return) path register themselves.
The last proxy (that forwards the 200 OK to the UA) is
supposed to store the ServiceRoute locally. Our plan
was straight-forward: to store the header field's
content via avp-ops from within the onreply_route.
Unfortunately avp-ops are not available in onreply_route -
Bogdan explains the reason why in
<http://www.archivum.info/serdev%40iptel.org/2005-02/msg00274.html>
Is there a specific reason why the access to the avp list
is not synchronized? Performance? Basically, provided a
good description of the implementation and concept, imho
it could be left to users to restrict themselves to have
avpops writes in only in their onreply_routes for a
specific avp pair. Or, provide synchronized avps?
So, does anyone have an idea how we can:
- Store an AVP containing header fields extracted from a
200 OK message
- Retrieve this AVP on incoming invites in order to place
these values into the message (security check and/or
Route enforcement).
Thanks in advance,
best regards
--Joachim
18 Oct
18 Oct
10:29 p.m.
Hi Joachim,
the reason haven't changed: avps doesn't work in on_reply route since
the avp belong to a transaction and the on_reply route execution is not
synchronized and may be done in parallel for same transaction.
For the moment there is no solution to this - synchronizing the on_reply
routes will be quite ugly :-/
But what will be done (there was a discussion with Juha on this topic)
is to add global avps which not being bound to a transaction can be used
inside on_reply route. I guess this will solve your problem....
regards,
bogdan
Joachim Fabini wrote:
Hi again,
Having solved the previous topic using Bogdan's hint
I stumbled straight into a new problem. Is there a
workaround for not being able to use the avp-ops
from onreply_route?
Some details on the reason: We implement the Service-
Route extension according to RFC 3608. The registrar
returns in the 200OK a ServiceRoute header where all
proxies on the (return) path register themselves.
The last proxy (that forwards the 200 OK to the UA) is
supposed to store the ServiceRoute locally. Our plan
was straight-forward: to store the header field's
content via avp-ops from within the onreply_route.
Unfortunately avp-ops are not available in onreply_route -
Bogdan explains the reason why in
<http://www.archivum.info/serdev%40iptel.org/2005-02/msg00274.html>
Is there a specific reason why the access to the avp list
is not synchronized? Performance? Basically, provided a
good description of the implementation and concept, imho
it could be left to users to restrict themselves to have
avpops writes in only in their onreply_routes for a
specific avp pair. Or, provide synchronized avps?
So, does anyone have an idea how we can:
- Store an AVP containing header fields extracted from a
200 OK message
- Retrieve this AVP on incoming invites in order to place
these values into the message (security check and/or
Route enforcement).
Thanks in advance,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
19 Oct
19 Oct
12:06 p.m.
Hi Bogdan,
the reason haven't changed: avps doesn't work
in on_reply route since
the avp belong to a transaction and the on_reply route
execution is not synchronized and may be done in parallel for same
transaction.
For the moment there is no solution to this - synchronizing
the on_reply routes will be quite ugly :-/
Do you see another - even proprietary - very-short-term-workaround
that can provide this functionality (storing avps within onreply_route
in the database that can be later on accessed from the route block
using avp-ops) without extra module coding?
Ugly is not important at all if it works. After all it's just about
prototyping, the final code should be clean... ;))
But what will be done (there was a discussion with
Juha on
this topic) is to add global avps which not being bound to
a transaction can be used inside on_reply route. I guess this
will solve your problem....
Definitely. That's also conceptually closer to what Service-Route
is supposed to do - it's valid for the lifetime of a registration
(although it might be changed by re-registrations) and not just
for one transaction. Any estimate when this will be available?
Thanks for your help,
regards
--Joachim
7:06 p.m.
Hi Joachim,
apply the attached tm.patch - it's trivial change that will synchronize
the execution of on_reply route. And it will be safe to use avpops
functions in on_reply routes. Note that you have to change the module
interface of AVPOPS and add the ONREPLY_ROUTE flag.
regards,
bogdan
PS: if you get a coredump, I'm free of any responsibilities :D
Joachim Fabini wrote:
Hi Bogdan,
Index: modules/tm/t_reply.c
===================================================================
RCS file: /cvsroot/openser/sip-server/modules/tm/t_reply.c,v
retrieving revision 1.16
diff -u -r1.16 t_reply.c
--- modules/tm/t_reply.c 18 Oct 2005 17:42:16 -0000 1.16
+++ modules/tm/t_reply.c 19 Oct 2005 14:56:34 -0000
@@ -1228,6 +1228,9 @@
is_local(t)?"yes":"no");
}
+ /* lock the reply*/
+ LOCK_REPLIES( t );
+
/* processing of on_reply block */
if (t->on_reply) {
/* transfer transaction flag to branch context */
@@ -1249,8 +1252,8 @@
set_avp_list( backup_list );
}
- /* lock the reply*/
- LOCK_REPLIES( t );
+ /* lock the reply
+ LOCK_REPLIES( t );*/
/* mark that the UAC received replies */
uac->flags |= T_UAC_HAS_RECV_REPLY;
the reason haven't changed: avps doesn't
work in on_reply route since
the avp belong to a transaction and the on_reply route
execution is not synchronized and may be done in parallel for same
transaction.
For the moment there is no solution to this - synchronizing
the on_reply routes will be quite ugly :-/
Do you see another - even proprietary - very-short-term-workaround
that can provide this functionality (storing avps within onreply_route
in the database that can be later on accessed from the route block
using avp-ops) without extra module coding?
Ugly is not important at all if it works. After all it's just about
prototyping, the final code should be clean... ;))
But what will be done (there was a discussion with
Juha on
this topic) is to add global avps which not being bound to
a transaction can be used inside on_reply route. I guess this
will solve your problem....
Definitely. That's also conceptually closer to what Service-Route
is supposed to do - it's valid for the lifetime of a registration
(although it might be changed by re-registrations) and not just
for one transaction. Any estimate when this will be available?
Thanks for your help,
regards
--Joachim
7:12 p.m.
Hi Bogdan,
apply the attached tm.patch - it's trivial change
that will
synchronize
the execution of on_reply route. And it will be safe to use avpops
functions in on_reply routes. Note that you have to change the module
interface of AVPOPS and add the ONREPLY_ROUTE flag.
Many, many thanks. Will try it tonight.
PS: if you get a coredump, I'm free of any
responsibilities :D
No, no, we insist on ownership of code. Quality management
rulez. ;)))
Thanks again,
Best regards
--Joachim
20 Oct
20 Oct
12:25 p.m.
Hi Bogdan,
I tried your patch, works perfectly, absolutely no problem so
far. It's exactly what we needed.
Just one more question (for now ;): Is the same procedure safe
to be used with 0.9.5 and 0.9.0 devel? Obviously the patch
must be applied manually for 0.9.x;
Looking at the sources and comparing the affected 0.9.x and
0.10.x files I am pretty sure that moving the lock in the
0.9.x t_reply.c is supposed to do exactly the same thing like
in 0.10 devel. And, as written above, anything works as
expected - also for 0.9.x.
So, is there something we miss?
Thanks again,
best regards
--Joachim
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
Sent: Mittwoch, 19. Oktober 2005 17:07
To: Joachim Fabini
Cc: users(a)openser.org; 'Joachim Fabini'
Subject: Re: [Users] Persistently storing headers from
onreply_route()?
Hi Joachim,
apply the attached tm.patch - it's trivial change that will
synchronize
the execution of on_reply route. And it will be safe to use avpops
functions in on_reply routes. Note that you have to change the module
interface of AVPOPS and add the ONREPLY_ROUTE flag.
regards,
bogdan
PS: if you get a coredump, I'm free of any responsibilities :D
Joachim Fabini wrote:
onreply_route
Hi Bogdan,
>the reason haven't changed: avps doesn't work in on_reply
route since
the avp
belong to a transaction and the on_reply route
execution is not synchronized and may be done in parallel for same
transaction.
For the moment there is no solution to this - synchronizing
the on_reply routes will be quite ugly :-/
Do you see another - even proprietary - very-short-term-workaround
that can provide this functionality (storing avps within in the database that can be later on accessed from
the route block
using avp-ops) without extra module coding?
Ugly is not important at all if it works. After all it's just about
prototyping, the final code should be clean... ;))
But what will be done (there was a discussion with
Juha on
this topic) is to add global avps which not being bound to
a transaction can be used inside on_reply route. I guess this
will solve your problem....
Definitely. That's also conceptually closer to what Service-Route
is supposed to do - it's valid for the lifetime of a registration
(although it might be changed by re-registrations) and not just
for one transaction. Any estimate when this will be available?
Thanks for your help,
regards
--Joachim
12:34 p.m.
Hi Joachim,
you are perfectly right - do the same trick for devel also, if needed.
regards,
bogdan
Joachim Fabini wrote:
Hi Bogdan,
I tried your patch, works perfectly, absolutely no problem so
far. It's exactly what we needed.
Just one more question (for now ;): Is the same procedure safe
to be used with 0.9.5 and 0.9.0 devel? Obviously the patch
must be applied manually for 0.9.x;
Looking at the sources and comparing the affected 0.9.x and
0.10.x files I am pretty sure that moving the lock in the
0.9.x t_reply.c is supposed to do exactly the same thing like
in 0.10 devel. And, as written above, anything works as
expected - also for 0.9.x.
So, is there something we miss?
Thanks again,
best regards
--Joachim
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
Sent: Mittwoch, 19. Oktober 2005 17:07
To: Joachim Fabini
Cc: users(a)openser.org; 'Joachim Fabini'
Subject: Re: [Users] Persistently storing headers from
onreply_route()?
Hi Joachim,
apply the attached tm.patch - it's trivial change that will
synchronize
the execution of on_reply route. And it will be safe to use avpops
functions in on_reply routes. Note that you have to change the module
interface of AVPOPS and add the ONREPLY_ROUTE flag.
regards,
bogdan
PS: if you get a coredump, I'm free of any responsibilities :D
Joachim Fabini wrote:
onreply_route
Hi Bogdan,
>the reason haven't changed: avps doesn't work in on_reply
>
>
route since
the avp
belong to a transaction and the on_reply route
execution is not synchronized and may be done in parallel for same
transaction.
For the moment there is no solution to this - synchronizing
the on_reply routes will be quite ugly :-/
Do you see another - even proprietary - very-short-term-workaround
that can provide this functionality (storing avps within
in the database that can be later on accessed from
the route block
using avp-ops) without extra module coding?
Ugly is not important at all if it works. After all it's just about
prototyping, the final code should be clean... ;))
But what will be done (there was a discussion with
Juha on
this topic) is to add global avps which not being bound to
a transaction can be used inside on_reply route. I guess this
will solve your problem....
Definitely. That's also conceptually closer to what Service-Route
is supposed to do - it's valid for the lifetime of a registration
(although it might be changed by re-registrations) and not just
for one transaction. Any estimate when this will be available?
Thanks for your help,
regards
--Joachim
6960
days inactive
6962
days old
6 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Joachim Fabini