Calling t_on_reply in branch_route doesn't work in Kamailio 3.1 - did work in Kamailio 1.5
4 May
2011
4 May
'11
12:34 p.m.
Hi,
I'm currently migrating a Kamailio 1.5 installation to Kamailio 3.1.3, and I
got all config changes merged, except this one:
branch_route[1] {
if ((isbflagset(4)) && (!isflagset(7))) {
fix_nated_sdp("1");
if (has_body()) {
force_rtp_proxy("R");
} else {
setflag(5);
}
t_on_reply("2");
}
}
In Kamailio 1.5 this worked without problems. In Kamailio 3.1 I get the
following error (line 1627 is the line with t_on_reply on it):
hostname:~# /usr/sbin/kamailio -c -f /etc/kamailio/proxy/kamailio.cfg
loading modules under
/urs/lib/kamailio/modules/:/usr/lib/kamailio/modules_k:/usr/lib/kamailio/modules_s/
0(13670) : <core> [cfg.y:3412]: parse error in config file
/etc/kamailio/proxy/kamailio.cfg, line 1627, column 17: Command cannot be
used in the block
ERROR: bad config file (1 errors)
hostname:~#
In the Kamailio 1.5 documentation it was stated for every t_on_* function,
where it could be called. For t_on_reply it said:
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, ONREPLY_ROUTE
and FAILURE_ROUTE.
In the Kamailio 3.1 documentation those lines are missing. But I don't
really see a reason, why t_on_reply shouldn't be called from branch route.
We need it for every branch to possibly have different onreply_routes.
Am I missing something? Thanks in advance for any hints.
Best regards,
Sebastian
4 May
4 May
12:43 p.m.
Wouldn't the same onreply_route be conserved for every branch? I
can't see how any of our implementations would actually work if that
weren't the case.
On 05/04/2011 12:34 PM, Sebastian Damm wrote:
Hi,
I'm currently migrating a Kamailio 1.5 installation to Kamailio 3.1.3,
and I got all config changes merged, except this one:
branch_route[1] {
if ((isbflagset(4)) && (!isflagset(7))) {
fix_nated_sdp("1");
if (has_body()) {
force_rtp_proxy("R");
} else {
setflag(5);
}
t_on_reply("2");
}
}
In Kamailio 1.5 this worked without problems. In Kamailio 3.1 I get
the following error (line 1627 is the line with t_on_reply on it):
hostname:~# /usr/sbin/kamailio -c -f /etc/kamailio/proxy/kamailio.cfg
loading modules under
/urs/lib/kamailio/modules/:/usr/lib/kamailio/modules_k:/usr/lib/kamailio/modules_s/
0(13670) : <core> [cfg.y:3412]: parse error in config file
/etc/kamailio/proxy/kamailio.cfg, line 1627, column 17: Command cannot
be used in the block
ERROR: bad config file (1 errors)
hostname:~#
In the Kamailio 1.5 documentation it was stated for every t_on_*
function, where it could be called. For t_on_reply it said:
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
ONREPLY_ROUTE and FAILURE_ROUTE.
In the Kamailio 3.1 documentation those lines are missing. But I don't
really see a reason, why t_on_reply shouldn't be called from branch
route. We need it for every branch to possibly have different
onreply_routes.
Am I missing something? Thanks in advance for any hints.
Best regards,
Sebastian
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
2:33 p.m.
On 5/4/11 6:43 PM, Alex Balashov wrote:
Wouldn't the same onreply_route be conserved for
every branch? I
can't see how any of our implementations would actually work if that
weren't the case.
Yes, the onreply_route will be conserved for the entire
transaction and
all its branches -- the last t_on_reply() called will be effective.
Seems this was forgotten when we switched to the new tm (from ser at
3.0) and these functions were not enabled for the branch_route, but
there is no reason they wouldn't work there -- probably nobody was using
in this way lately. I just enabled the t_on_reply() function for
branch_route, just fetch the latest version from git branch 3.1 and try
again.
Cheers,
Daniel
On 05/04/2011 12:34 PM, Sebastian Damm wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi,
I'm currently migrating a Kamailio 1.5 installation to Kamailio 3.1.3,
and I got all config changes merged, except this one:
branch_route[1] {
if ((isbflagset(4)) && (!isflagset(7))) {
fix_nated_sdp("1");
if (has_body()) {
force_rtp_proxy("R");
} else {
setflag(5);
}
t_on_reply("2");
}
}
In Kamailio 1.5 this worked without problems. In Kamailio 3.1 I get
the following error (line 1627 is the line with t_on_reply on it):
hostname:~# /usr/sbin/kamailio -c -f /etc/kamailio/proxy/kamailio.cfg
loading modules under
/urs/lib/kamailio/modules/:/usr/lib/kamailio/modules_k:/usr/lib/kamailio/modules_s/
0(13670) : <core> [cfg.y:3412]: parse error in config file
/etc/kamailio/proxy/kamailio.cfg, line 1627, column 17: Command cannot
be used in the block
ERROR: bad config file (1 errors)
hostname:~#
In the Kamailio 1.5 documentation it was stated for every t_on_*
function, where it could be called. For t_on_reply it said:
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
ONREPLY_ROUTE and FAILURE_ROUTE.
In the Kamailio 3.1 documentation those lines are missing. But I don't
really see a reason, why t_on_reply shouldn't be called from branch
route. We need it for every branch to possibly have different
onreply_routes.
Am I missing something? Thanks in advance for any hints.
Best regards,
Sebastian
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5 May
5 May
6:40 a.m.
Hi,
On Wed, May 4, 2011 at 8:33 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com>wrote;wrote:
Wouldn't the same onreply_route be conserved for
every branch? I can't see
OK, thanks for the clarification. It still helps so that we can force this
onreply_route only when at least one of the branches is detected to be
behind NAT.
how any of our implementations would actually
work if that weren't the case.
Yes, the onreply_route will be conserved for the entire transaction and all
its branches -- the last t_on_reply() called will be effective.
Seems this was forgotten when we switched to the new
tm (from ser at 3.0)
and these functions were not enabled for the branch_route, but there is no
reason they wouldn't work there -- probably nobody was using in this way
lately. I just enabled the t_on_reply() function for branch_route, just
fetch the latest version from git branch 3.1 and try again.
Thanks, I will update immediately.
Best regards,
Sebastian
10:40 a.m.
On 5/5/11 12:40 PM, Sebastian Damm wrote:
Hi,
On Wed, May 4, 2011 at 8:33 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Wouldn't the same onreply_route be conserved for every branch?
I can't see how any of our implementations would actually
work if that weren't the case.
Yes, the onreply_route will be conserved for the entire
transaction and all its branches -- the last t_on_reply() called
will be effective.
OK, thanks for the clarification. It still helps so that we can force
this onreply_route only when at least one of the branches is detected
to be behind NAT.
Seems this was forgotten when we switched to the new tm (from ser
at 3.0) and these functions were not enabled for the branch_route,
but there is no reason they wouldn't work there -- probably nobody
was using in this way lately. I just enabled the t_on_reply()
function for branch_route, just fetch the latest version from git
branch 3.1 and try again.
Thanks, I will update immediately.
There is an workaround for your version as well,
just copy the content
of the branch route in the 'route[xyz] {...}' and then execute
route(xyz); in the branch route. Should work, it is the way I have my
configs.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
10:43 a.m.
On 05/05/2011 10:40 AM, Daniel-Constantin Mierla wrote:
There is an workaround for your version as well, just
copy the
content of the branch route in the 'route[xyz] {...}' and then
execute route(xyz); in the branch route. Should work, it is the way I
have my configs.
That's what I do. But I've never been clear on why this works: doesn't
a request route executed from a branch route still have a "branch route"
scope? And if not, what is the exact way to foresee the implications of
doing certain things that are not allowed in a branch route explicitly
in a request route called from a branch route?
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
10:54 a.m.
On 5/5/11 4:43 PM, Alex Balashov wrote:
On 05/05/2011 10:40 AM, Daniel-Constantin Mierla
wrote:
the branch
route scope would be:
- request uri
- destination uri (outbound proxy)
- branch flags
- changes to request (header and body manipulation)
t_on_reply() at it is works on transaction scope no matter where is
used. So when it is called, it looks up the transaction based on
call-id, cseq a.s.o. (in many cases the transaction pointer is cached,
so just one lookup for a sip message) and the sets the value of the
onreply_route name to be executed.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
There is an workaround for your version as well,
just copy the
content of the branch route in the 'route[xyz] {...}' and then
execute route(xyz); in the branch route. Should work, it is the way I
have my configs.
That's what I do. But I've never been clear on why this works:
doesn't a request route executed from a branch route still have a
"branch route" scope? And if not, what is the exact way to foresee
the implications of doing certain things that are not allowed in a
branch route explicitly in a request route called from a branch route?
4986
days inactive
4987
days old
6 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Sebastian Damm