[OpenSIPS-Users] Calling engage_media_proxy per branch

[Dan Pascu]

On Friday 29 May 2009, Thomas Gelf wrote:
> ...this part leads me to the question, how such edge cases could
> be automagically solved in the future.

Quite frankly I know of no generic solution to future undefined problems. That 
is a fantasy. What we have is a solution with a given complexity that is able 
to solve certain classes of problems. Once you come up with a new class of 
problems not covered by the complexity of the solution, you need to extend 
your solution (make it more generic) in order to cover the new class of 
problems you are trying to solve. Since no solution has infinite complexity, 
at any time I can come up with a problem that cannot be "auto-magically" 
solved and we will need to extend the solution yet again.

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

And I'm sure many others will consider it useful, but only those with an itch 
to scratch will consider it's worth the effort.

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

Again, this "behave flawlessly" is relative. It behaves flawlessly for me, 
because my use case is within the design parameters (in other words my problem 
is within the complexity of the solution). If you have a use case that is not 
covered by the existing complexity, then indeed for you it will not be 
flawless and it will require the solution to be extended.

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

You assume wrong. I have it working just fine with that case. It even has a 
unit test script to test exactly that case.

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

Why would you want to end_media_session for a reINVITE? While technically you 
can do it, I see no point in it. If done, it'll have negative side effects on 
the accounting that mediaproxy does. As for use_media_proxy, yes you have to 
call it for every reINVITE/reply. The README indicates exactly when to call 
each of the functions.

> Probably this is what also engage_media_proxy does, so the answer would
> be "yes". 

engage_media_proxy doesn't terminate the media session until the dialog is 
destroyed.

> 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

You need to call use_media_proxy for the initial INVITE and its positive 
replies as well as for every in-dialog request/reply, except for the BYE, in 
which case you will call end_media_session. Testing if the body is present 
before calling use_media_proxy is pointless as the function will test that 
itself and do nothing if there is no SDP.

-- 
Dan