[OpenSIPS-Devel] [OpenSIPS-News] NEW additions to configuration file routes

[Thomas Gelf]

Anca Vamanu wrote:
> 1. The routes can have string names also...

I wished this was true long time ago, once I was fiddling with numerical
IDs ;-) Since using M4 macros it is no longer an issue, nonetheless I
consider it a useful and comfortable addition making routing script
writer's life easier.

> 2. Two new types of routes were added.

Cool! I have no immediate use for them, but I'd really like to make use
of the cache module sooner or later - and cache warmup would be an
important task in that case.

> 3. One new type of *onreply_route* was added: *per branch on reply
> route*. Sometimes it is useful to know in a reply route to which branch
> it belongs to. Now this is very simple to achieve - if you call
> t_on_reply("name") from a branch route then only the replies for that
> branch will go through onreply_route[name].

WOW, that's what I've been waiting for! As I have been talking with
Bogdan regarding this missing and IMO really important puzzle piece
(thanks for changelog credits, btw!), I'd like to to take the occasion
to point out that another related important addition has been made:

   $T_branch_idx has been corrected / improved

Let me provide a short example showing what this could be used for:

    route(use_mediaproxy_for_branch) {
        $var(helper) = null;
        $var(helper) = "br_" + $T_branch_idx + "_mp";
        store_dlg_value("$var(helper)", "1");
    }

    route(branch_uses_mediaproxy) {
        $var(result) = null;
        $var(helper) = "br_" + $T_branch_idx + "_mp";
        fetch_dlg_value("$var(helper)", "$var(result)");
        return $var(result);
    }

"Better"-looking constructs like

    $dlg("br_" + $T_branch_idx + "_mp")

are not (yet?) possible, but at least as shown above it (should) work.
Why I'm doing so? This simulates "per-branch-dialog-vars". You are now
able to fork an INVITE transaction to multiple endpoints with different
requirements to your routing script (e.g. whether to use mediaproxy or
not).

This solves issues with calls from UACs with public IP forked to

a) UAC on public IP, no need for Mediaproxy, packet gets relayed
b) UAC with NAT issue, [use|engage]_media_proxy, packet with modified
   SDP is relayed

If a) picks up the call, SDP in it's reply will be mangled, RTP will
fail. Since per-branch reply_routes are working as expected, the above
example will help. Another option would be a combination of branch flags
(callee has nat issue) and dialog vars (caller has nat issue) - if you
don't like this $dlg-fiddling-voodoo ;-)

Just my 2 Eurocent. Thank you for this improvement!

Best regards,
Thomas Gelf

-- 
 mail: thomas at gelf.net
  web: http://thomas.gelf.net/