[OpenSIPS-Users] Calling engage_media_proxy per branch

[Dan Pascu]

On Thursday 28 May 2009, Thomas Gelf wrote:
> Hi list,
> 
> I really like engage_media_proxy() as it really makes life easier.
> However, currently it is dialog-based and cannot be called in a
> branch_route. This has some side-effect:
> 
> a) if a call is forked to two users, one behind NAT and one with
>    non-symmetric router and STUN or on public IP, mediaproxy is
>    always used, even if the client without NAT picks up the call.
> 
> While I could live with this, a second scenario is really ugly:
> 
> b) A is calling B, both with public IP. B issues a conditional
>    call forward (30x) to C, with C being behind NAT. As far as
>    I understood the module there is no way to "engage" Mediaproxy
>    in this scenario.

It depends on what you do. If you process the redirect in the proxy's failure 
routes, then indeed you have a problem. If you just relay the 30x to the phone 
and let it do the redirection, that it will generate a new INVITE which you 
handle the normal way as it generates a new dialog. In fact this would be 
recommended, as the caller should be the one deciding if he accepts the 
redirect, not the proxy.

> What I would like to know is:
> 
> - is there a known workaround for this issue, that I can apply
>   to my config script?

See above.

> - is it planned to change engage_media_proxy to make it "branch-
>   aware"?

It cannot be called in a branch route as engage_media_proxy must be called 
before the transaction/dialog is created. As far as I understand the branch 
routes are called by t_relay after creating the transaction/dialog.

Besides, it's not possible to do it even if the branch route would be called 
before creating the transaction/dialog. engage_media_proxy works by setting a 
flag on the dialog to indicate that it has to use mediaproxy on every request 
and reply inside that dialog. If you call it from a branch, it will still set 
the same dialog flag. Now because the dialog flag is global (not branch 
specific), it will modify all the outgoing INVITEs on all branches, including 
the ones on branches with phones with public addresses because there is really 
just 1 dialog, no matter how many branches. So mediaproxy will still be used 
even for non-NATed devices.

It's important to understand that when you call engage_media_proxy doesn't do 
anything else than set a flag to indicate that it has to modify the request 
later when the dialog is started. So it doesn't matter where you call it 
(branch or main route), it will not modify the INVITE request that is 
available at the moment you call it (be that in the main or the branch route). 
Later when the dialog is created only then it will modify the message.

As far as I understand it, the process looks like this:

engage_media_proxy (sets dialog flag) -> t_relay -> create transaction/dialog 
-> call mediaproxy and modify the request -> branch it -> call branch routes 
to apply branch changes -> send out requests on each branch.

But even if you would be able to call it from the branch route, it would still 
not solve your b case above if that is be handled by a failure route.

> - if you can acknowledge neither of the above: do I really need
>   to tear down/re-use Mediaproxy session on each ReINVITE? What
>   is the current best practice in this case?

You cannot do that with engage_media_proxy. When you want to use that, you 
have to decide before hand if you are going to use mediaproxy or not. Once 
started it will only be ended when the dialog ends. If you want to be able to 
have a fine-grained control when to start/stop mediaproxy, you have to use 
use_mediaproxy/end_media_session explicitly.

-- 
Dan