I don't think it behaves as you describe -- I have mainly used rtpproxy
so far, but also rtpengine quite many times, and rtpengine variant is
based on the rpproxy_manage() -- I quickly looked at the sources right now.
For an INVITE request, the delete command to rtp relay is done only when
executed from failure_route. But you execute it from branch_route, which
is different top route type and it is sending init or update session,
based in intial request or re-invite.
The default configuration file uses rtpproxy_manage() for many stable
versions right now. I use the same architecture in all my configs for
rtpproxy like in default configuration, where the rtpproxy_manage() ends
up being executed from branch_route, failure_route and onreply_route. No
issues with serial forking and that is done a lot.
Are you sure it does a delete command when rtpengine_manage() is
executed from branch_route following a relay to a new destination from
failure_route? Or is just your guess?!? If it does, it's a bug in
setting the route block type, but I would think that is very unlikely.
Cheers,
Daniel
On 03/02/16 15:14, Alex Balashov wrote:
> Daniel,
>
> I do like rtpengine_manage() philosophically, and agree it's easier to
> use and handles the case where the SDP offer is in the reply from the
> UAS.
>
> I used to use it. However, it doesn't behave correctly in certain
> route script contexts. Here's an example from my own environment:
>
> ---
> route[XYZ_TRY] {
> # Lots of stuff that can be executed either with or without
> # transaction already having been created, e.g. use send_reply(),
> # never just sl_send_reply() or t_reply(), etc.
>
> t_on_branch("XYZ_BRANCH");
> t_on_failure("XYZ_FAILURE");
>
> t_relay();
> }
>
> branch_route[XYZ_BRANCH] {
> rtpengine_manage();
> }
>
> failure_route[XYZ_FAILURE] {
> if(t_is_canceled())
> exit;
>
> # Load some more routes maybe, create new
> # branch.
>
> $rd = "new_host";
>
> route(XYZ_TRY);
> }
> ---
>
> This behaves mostly as you'd expect, _except_ in the case of a branch
> timeout. If there's a _timeout_ per se, e.g. branch #1 host did not
> respond, then in the subsequent branch #2 attempt, rtpengine_manage()
> in the branch_route will send a 'delete' command rather than an
> updated 'offer' command.
>
> Perhaps the root of the problem is that I am calling a request_route
> from a failure_route, but I don't know how else to recycle the huge
> corpus of logic that's in XYZ_TRY. I'm open to better suggestions.
>
> Notwithstanding that, there may be other exotic cases as well where
> rtpengine_manage() doesn't do the right thing. Either way, for this
> reason I do not use it.
>
> -- Alex
>
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu
_______________________________________________
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
