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:

...

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 5/5/11 12:40 PM, Sebastian Damm wrote:

Hi,

On Wed, May 4, 2011 at 8:33 PM, Daniel-Constantin Mierla <miconda@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

On 5/5/11 4:43 PM, Alex Balashov wrote:

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?

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