11 Aug
2008
11 Aug
'08
1:14 p.m.
What is the simplest way to identify the branch (by branch index) to
which a reply belongs in an ONREPLY-ROUTE?
I have parallel forking with my registrar and do passive call
statekeeping. The problem is that it must be branch-aware; I need to
know if, for example, I got a successful provisional reply on one branch
of the call and a failure on the other, and deal with those separately.
Right now my statekeeping information is keyed by Call-ID, but since
that persists across two branches, obviously some sort of
branch-identifying information has to be present.
I've tried setting a persistent variable to the value of $T_branch_idx
inside a BRANCH-ROUTE, but in ONREPLY-ROUTE that just shows up with the
most recent branch index, regardless of which branch the reply actually
came in on.
I'm probably missing something quite obvious here, so I ask - how do I
incorporate some form of branch awareness into ONREPLY-ROUTEs? I really
do not care what form that is - be it branch index, or some other
built-in value, as long as it is consistent.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
11 Aug
11 Aug
1:35 p.m.
I suppose I can extract the 'branch' parameter from the topmost Via: in
the reply, but are there are any prebuilt API/module functions for
manipulating the Via? Or is it plain old textops time?
Alex Balashov wrote:
What is the simplest way to identify the branch (by
branch index) to
which a reply belongs in an ONREPLY-ROUTE?
I have parallel forking with my registrar and do passive call
statekeeping. The problem is that it must be branch-aware; I need to
know if, for example, I got a successful provisional reply on one branch
of the call and a failure on the other, and deal with those separately.
Right now my statekeeping information is keyed by Call-ID, but since
that persists across two branches, obviously some sort of
branch-identifying information has to be present.
I've tried setting a persistent variable to the value of $T_branch_idx
inside a BRANCH-ROUTE, but in ONREPLY-ROUTE that just shows up with the
most recent branch index, regardless of which branch the reply actually
came in on.
I'm probably missing something quite obvious here, so I ask - how do I
incorporate some form of branch awareness into ONREPLY-ROUTEs? I really
do not care what form that is - be it branch index, or some other
built-in value, as long as it is consistent.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
2:01 p.m.
Hello,
On 08/11/08 13:35, Alex Balashov wrote:
I suppose I can extract the 'branch' parameter
from the topmost Via: in
the reply, but are there are any prebuilt API/module functions for
manipulating the Via? Or is it plain old textops time?
you found a good solution and with transformations should be easy to
get. honestly I had no need so far and I think the right approach is to
ma $T_branch_index return the branch of the processed reply.
Cheers,
Daniel
Alex Balashov wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
What is the simplest way to identify the branch
(by branch index) to
which a reply belongs in an ONREPLY-ROUTE?
I have parallel forking with my registrar and do passive call
statekeeping. The problem is that it must be branch-aware; I need to
know if, for example, I got a successful provisional reply on one branch
of the call and a failure on the other, and deal with those separately.
Right now my statekeeping information is keyed by Call-ID, but since
that persists across two branches, obviously some sort of
branch-identifying information has to be present.
I've tried setting a persistent variable to the value of $T_branch_idx
inside a BRANCH-ROUTE, but in ONREPLY-ROUTE that just shows up with the
most recent branch index, regardless of which branch the reply actually
came in on.
I'm probably missing something quite obvious here, so I ask - how do I
incorporate some form of branch awareness into ONREPLY-ROUTEs? I really
do not care what form that is - be it branch index, or some other
built-in value, as long as it is consistent.
1:59 p.m.
Daniel-Constantin Mierla wrote:
you found a good solution and with transformations
should be easy to
get. honestly I had no need so far and I think the right approach is to
ma $T_branch_index return the branch of the processed reply.
The problem is that $T_branch_idx has no validity outside of a BRANCH-ROUTE.
Also, as far as transformations, I can't seem to get the following to
work with textops:
if(search("^Via:.*branch=([a-zA-Z0-9\.\-\_]+)")) {
xlog("L_INFO", " Via: \1 \n");
}
It matches, but, how do I display the matched regex atom? \1 works in
substitutions, but not here evidently?
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
2:01 p.m.
Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
Ditto for trying to do anything with $hdr(Via).
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
you found a good solution and with
transformations should be easy to
get. honestly I had no need so far and I think the right approach is
to ma $T_branch_index return the branch of the processed reply.
The problem is that $T_branch_idx has no validity outside of a
BRANCH-ROUTE.
Also, as far as transformations, I can't seem to get the following to
work with textops:
if(search("^Via:.*branch=([a-zA-Z0-9\.\-\_]+)")) {
xlog("L_INFO", " Via: \1 \n");
}
It matches, but, how do I display the matched regex atom? \1 works in
substitutions, but not here evidently?
2:34 p.m.
Daniel,
Well, for now I am processing $hdr(Via) in my Perl middleware to get the
branch ID out.
The problem then becomes that the topmost Via visible to the initial
REQUEST-ROUTE (as well as any corresponding BRANCH-ROUTEs resulting from
lookup & stateful relay) during processing is from the call source, not
the outgoing call leg.
So:
SBC --> its Via and a certain branch param -->
registrar --> branches to contacts
At the point at which the registrar is processing the request, the Via
from the SBC is what is visible. Only once the request is forwarded
does the new Via stamped on by the proxy become visible, with the
corresponding branch parameters.
As a result, I have no way of identifying the same branches from the
REQUEST-ROUTE (or BRANCH-ROUTE) as later in the ONREPLY-ROUTE.
What would you suggest as my other options? I suppose it is possible to
append some custom headers, but these do not come back in replies. I
would hate to use add_rr_param() for this purpose or something equally
nefarious, as well; that does not seem RFC-kosher.
I suppose I *could* store the branch= parameter of the incoming leg and
then collate the subsequent branches with it, but it seems like there
really ought to be a better way.
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
7:04 p.m.
Hello,
On 08/11/08 14:34, Alex Balashov wrote:
Daniel,
Well, for now I am processing $hdr(Via) in my Perl middleware to get
the branch ID out.
The problem then becomes that the topmost Via visible to the initial
REQUEST-ROUTE (as well as any corresponding BRANCH-ROUTEs resulting
from lookup & stateful relay) during processing is from the call
source, not the outgoing call leg.
So:
SBC --> its Via and a certain branch param -->
registrar --> branches to contacts
At the point at which the registrar is processing the request, the Via
from the SBC is what is visible. Only once the request is forwarded
does the new Via stamped on by the proxy become visible, with the
corresponding branch parameters.
As a result, I have no way of identifying the same branches from the
REQUEST-ROUTE (or BRANCH-ROUTE) as later in the ONREPLY-ROUTE.
What would you suggest as my other options? I suppose it is possible
to append some custom headers, but these do not come back in replies.
I would hate to use add_rr_param() for this purpose or something
equally nefarious, as well; that does not seem RFC-kosher.
I suppose I *could* store the branch= parameter of the incoming leg
and then collate the subsequent branches with it, but it seems like
there really ought to be a better way.
maybe you you tell what you need to do with
this branches I can find a
solution. So far I don't get exactly the logic you want to implement. I
thought you need the branch id in the onreply route and that is all.
Cheers,
Daniel
-- Alex
--
Daniel-Constantin Mierla
http://www.asipto.com
7:40 p.m.
Daniel-Constantin Mierla wrote:
maybe you you tell what you need to do with this
branches I can find a
solution. So far I don't get exactly the logic you want to implement. I
thought you need the branch id in the onreply route and that is all.
A branch ID that is visible in the onreply route would suffice.
What I am doing is monitoring call state in order to enforce per-user
concurrent session limits, somewhat akin to what a billing application
that generates CDRs from passively inspecting dialogs passing through
OpenSER would do. I am doing it myself rather than using the dialog
module. So, I log INVITEs, BYEs, CANCELs, OKs, 183s, into a table
associated with a user and then count open calls.
The problem is that the registrar also supports multiple contacts, and
when forking occurs as a result of a lookup(), this mechanism breaks
down because the reply routes aren't branch-aware in any way.
For instance, my logic simply deletes a call from the call state table
if it receives an error (4/5/6xx) in the onreply route. But if I have
two branches, what if one of them passes back an error and the other one
succeeds with 200 OK? From the onreply route's point of view, there is
only one call going on here, and so the state entry is deleted by GUID
(Call-ID) and any subsequent developments in other branches never get
logged.
Obviously, what I need is to track call state by branch <--> Call-ID,
not just Call-ID. But in order to do that, I need more than just a
branch route; I need to know what branch feedback belongs to in the
replies and in new requests.
I can get it using the topmost Via header stamped by the proxy, which
appears in replies as well as in new in-dialog requests (i.e. BYE). But
Kamailio appears to offer no options for extracting the branch=
parameter from these Vias in an elegant, high-level way. Furthermore,
these branch IDs are not known in the initial INVITE that establishes
the branches, so I have to somehow collate them with the incoming call leg.
So, what I'd really be looking for to graetly simplify this endeavour is
twofold:
1. $T_branch_idx ought to be lexically valid outside of a branch route,
and reveal the pertinent branch wherever possible, including in request
routes and reply routes. I do not know if the way 'tm' works makes
structurally possible.
2. Some way to determine branch IDs at their onset. I don't expect to
know branch IDs in the initial request route, before I even call
t_relay(), but I think it is reasonable for a branch route to know its
own branch ID. It does, in the form of $T_branch_idx, but as per #1,
that is something that has no meaning outside of a branch route, making
correlation impossible.
If #1 could be addressed #2 would go away.
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
7:38 p.m.
El Monday 11 August 2008 18:40:50 Alex Balashov escribió:
Daniel-Constantin Mierla wrote:
Is not useful for you $T_reply_code?
http://www.kamailio.org/docs/modules/1.3.x/tm.html#AEN576
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
maybe you you tell what you need to do with this
branches I can find a
solution. So far I don't get exactly the logic you want to implement. I
thought you need the branch id in the onreply route and that is all.
A branch ID that is visible in the onreply route would suffice.
What I am doing is monitoring call state in order to enforce per-user
concurrent session limits, somewhat akin to what a billing application
that generates CDRs from passively inspecting dialogs passing through
OpenSER would do. I am doing it myself rather than using the dialog
module. So, I log INVITEs, BYEs, CANCELs, OKs, 183s, into a table
associated with a user and then count open calls.
The problem is that the registrar also supports multiple contacts, and
when forking occurs as a result of a lookup(), this mechanism breaks
down because the reply routes aren't branch-aware in any way.
For instance, my logic simply deletes a call from the call state table
if it receives an error (4/5/6xx) in the onreply route. But if I have
two branches, what if one of them passes back an error and the other one
succeeds with 200 OK? From the onreply route's point of view, there is
only one call going on here, and so the state entry is deleted by GUID
(Call-ID) and any subsequent developments in other branches never get
logged.
Obviously, what I need is to track call state by branch <--> Call-ID,
not just Call-ID. But in order to do that, I need more than just a
branch route; I need to know what branch feedback belongs to in the
replies and in new requests.
I can get it using the topmost Via header stamped by the proxy, which
appears in replies as well as in new in-dialog requests (i.e. BYE). But
Kamailio appears to offer no options for extracting the branch=
parameter from these Vias in an elegant, high-level way. Furthermore,
these branch IDs are not known in the initial INVITE that establishes
the branches, so I have to somehow collate them with the incoming call leg.
So, what I'd really be looking for to graetly simplify this endeavour is
twofold:
1. $T_branch_idx ought to be lexically valid outside of a branch route,
and reveal the pertinent branch wherever possible, including in request
routes and reply routes. I do not know if the way 'tm' works makes
structurally possible.
2. Some way to determine branch IDs at their onset. I don't expect to
know branch IDs in the initial request route, before I even call
t_relay(), but I think it is reasonable for a branch route to know its
own branch ID. It does, in the form of $T_branch_idx, but as per #1,
that is something that has no meaning outside of a branch route, making
correlation impossible.
If #1 could be addressed #2 would go away.
-- Alex
7:51 p.m.
Iñaki Baz Castillo wrote:
Is not useful for you $T_reply_code?
http://www.kamailio.org/docs/modules/1.3.x/tm.html#AEN576
Unless I am missing something, no, because it does not tell me anything
about the individual branch on which the reply occurred.
Parece un poco inutil.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
8:28 p.m.
El Lunes, 11 de Agosto de 2008, Alex Balashov escribió:
Iñaki Baz Castillo wrote:
Well, I suggested it to retrieve the final reply sent by OpenSer after
possible forking and so. But I think this is not what you mean, sorry, I
should read the entire message :)
--
Iñaki Baz Castillo
Is not useful for you $T_reply_code?
http://www.kamailio.org/docs/modules/1.3.x/tm.html#AEN576
Unless I am missing something, no, because it does not tell me anything
about the individual branch on which the reply occurred.
12 Aug
12 Aug
9:25 a.m.
Hello,
On 08/11/08 19:40, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
hope I understood what you want to achieve. By using reply routes you
get a bit more complex data structure and operations. Isn't it enough to
use failure route? Even if is parallel forking, only one branch wins or
all fail. If one win, then you don't delete, if all fail then you delete
the record.
This should work unless you want to see also branches in you table.
Cheers,
Daniel
maybe you you tell what you need to do with this
branches I can find a
solution. So far I don't get exactly the logic you want to implement. I
thought you need the branch id in the onreply route and that is all.
A branch ID that is visible in the onreply route would suffice.
What I am doing is monitoring call state in order to enforce per-user
concurrent session limits, somewhat akin to what a billing application
that generates CDRs from passively inspecting dialogs passing through
OpenSER would do. I am doing it myself rather than using the dialog
module. So, I log INVITEs, BYEs, CANCELs, OKs, 183s, into a table
associated with a user and then count open calls.
The problem is that the registrar also supports multiple contacts, and
when forking occurs as a result of a lookup(), this mechanism breaks
down because the reply routes aren't branch-aware in any way.
For instance, my logic simply deletes a call from the call state table
if it receives an error (4/5/6xx) in the onreply route. But if I have
two branches, what if one of them passes back an error and the other one
succeeds with 200 OK? From the onreply route's point of view, there is
only one call going on here, and so the state entry is deleted by GUID
(Call-ID) and any subsequent developments in other branches never get
logged.
Obviously, what I need is to track call state by branch <--> Call-ID,
not just Call-ID. But in order to do that, I need more than just a
branch route; I need to know what branch feedback belongs to in the
replies and in new requests.
I can get it using the topmost Via header stamped by the proxy, which
appears in replies as well as in new in-dialog requests (i.e. BYE). But
Kamailio appears to offer no options for extracting the branch=
parameter from these Vias in an elegant, high-level way. Furthermore,
these branch IDs are not known in the initial INVITE that establishes
the branches, so I have to somehow collate them with the incoming call leg.
So, what I'd really be looking for to graetly simplify this endeavour is
twofold:
1. $T_branch_idx ought to be lexically valid outside of a branch route,
and reveal the pertinent branch wherever possible, including in request
routes and reply routes. I do not know if the way 'tm' works makes
structurally possible.
2. Some way to determine branch IDs at their onset. I don't expect to
know branch IDs in the initial request route, before I even call
t_relay(), but I think it is reasonable for a branch route to know its
own branch ID. It does, in the form of $T_branch_idx, but as per #1,
that is something that has no meaning outside of a branch route, making
correlation impossible.
If #1 could be addressed #2 would go away.
-- Alex
--
Daniel-Constantin Mierla
http://www.asipto.com
5949
days inactive
5950
days old
11 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Iñaki Baz Castillo