[OpenSIPS-Users] Calling engage_media_proxy per branch

[Thomas Gelf]

Dan Pascu wrote:
> 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.

That was not the question ;-) If your customers are paying for their
calls to PSTN they would not be amused if someone would be able to force
them into calling special service numbers or whatever. You either want
to forbid redirects at all or bill the call to the user issuing the
"call forward".

>> - is there a known workaround for this issue, that I can apply
>>   to my config script?
> 
> See above.

Sincerely, even it the above statement might be correct I don't care ;-)
Therefore this part of your response doesn't really help me - but it
allows me to read between the lines that there will be no quick fix,
so I guess the answer is simply "NO".

>> - 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.
> ...
> 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.

Thank you very much for this detailled explanation! Now I really
understand, why what I want to achieve is not possible using
engage_media_proxy. This combined with...

> 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.

...this part leads me to the question, how such edge cases could
be automagically solved in the future. Some time ago Bogdan raised a
brainstorm request regarding new route types - as for example right
now it is not possible to have different reply routes for different
branches, who needs such thing needs to hack something with his config
file, using rr-params or whatever.

We are dialog stateful, transaction stateful - but it seems there is
nothing allowing script/module writers to easily distinct between
different branches, still being dialog aware. Wouldn't it be worth
the effort to provide such thing, as especially in this specific
case (engage_media_proxy) I would consider it to be really useful.

NAT issues are handled per branch, and so should RTP issues in case
of NAT problems. Functions like nat_keepalive and engage_media_proxy
take away a lot of pain from the script writer - and should therefore
be designed to behave flawlessly in most/all cases.

And, something else: SDP does not need to be negotiated with INVITE/200,
if there is no SDP in your initial INVITE you'll get your offer from
200 Ok and you'll respond in your ACK packet. Even if I have never seen
such thing in the wild, I assume this is not possible to be handled with
engage_media_proxy.

>> - 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.

That's pretty clear. My intention (by asking for "best practice") was
to figure out how this could be done as efficient as possible. As of
session timers there are a lot of ReINVITES in a single phone call.
Do I really need to call end_media_session() and use_mediaproxy() for
each In-Dialog INVITE with SDP?

Probably this is what also engage_media_proxy does, so the answer would
be "yes". Is it enough to call use_mediaproxy() for all:

- initial INVITEs with SDP
- In-Dialog INVITEs with SDP
- ACKs with SDP
- Replies > 100 and < 300 with SDP - or just 180|183|200

I'll manually "tag" branches using Mediaproxy to be also prepared for
the 200/ACK variant and to avoid useless end_media_session calls for
branches not using it.

Regardless of the above thoughts - will I be fine with this approach?

Best regards,
Thomas Gelf