On 24.09.2009 10:28 Uhr, Alex wrote:
On Friday 04 September 2009, Juha Heinanen wrote:
SourceForge.net writes:
> I would either expect the ruri and all other variables and headers to
> be exactly the same as at t_relay time for each branch, or (for
> DNS-based failover ONLY) the packet sent to a failover destination to
> be exactly the same as the first branch (including any added headers
> / from replacement, etc.) Not a mix of both.
if i add a header in branch route, i want it to be there ONLY for that
branch, not for any other branch.
Of course, and you'd probably expect that changing the RURI in branch route
is only for that branch. Unfortunately both statements are not fulfilled by
Kamailio.
not sure I got this one. Headers and r-uri on updated on a branch route
are visible on that branch only.
If you add a header for a specific destination domain, you'd probably want
it to be sent to every ip if there are multiple ip's in the domains SRV
records. Currently it doesn't work for DNS based failover:
In case a 503 is received, you can add the header again from the script, as
branch route is called again for the next IP. Keep in mind you don't get the
RURI you set before t_relay(), but the RURI set in the previous branch
route.
DNS failover is pretty much hidden to script writer, and each step
creates a new branch. Also remember that this is serial forking, so a
branch from a branch, not parallel, branches from initial invite.
In case there is a timeout, you're lost. No branch route is called, and the
header is missing.
Failure route is processing the initial message. Hopefully lot of such
limitations will be removed in kamailio 3.0 with the new function
msg_apply_changes() from textops where the script writer can apply
changes, therefore make new headers permanent before creating the
transaction and going into the forking logic.
Cheers,
Daniel
Unfortunately the above is a very common scenario: LCR. When every carrier
requires a specific RURI format, require some additional headers and that
the carriers are reachable over SRV records.
A quick workaround would be that on DNS based failover in case of a timeout,
branch route is called again. I tried to find in the source the place where
the decision is made whether or not to call branch route on DNS failover,
but got lost.
Alex.
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
* http://www.asipto.com/
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
