[OpenSIPS-Users] Calling engage_media_proxy per branch

[Thomas Gelf]

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

I consider the redirect interception a real-world example and I'm pretty
sure others will think so too. Or consider some announcement mechanism,
with a 183-announcement from a media server (saying you're low on credit
or whatever) before sending a second branch to a user behind NAT.

These "edge cases" are possible today and there will be discovered
others in the future. And they all have one thing in common: if
engage_media_proxy would be able to work per branch a script writer has
to write just one single line, otherwise he couldn't use this valuable
function and needs to do things "manually" as before.

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

Hmmm... so you call engage_media_proxy for the SDP-less initial INVITE
as you know from location database, that the called destination is
behind NAT? Cool!

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

Sorry, end_media_session should not be written there. Obviously it
should read "...call use_mediaproxy for each...", like also written
below.

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

Once again, sorry for causing confusion. README is on my desk, here as a
proof an older picture: http://devel.gelf.net/voip_fun.jpg ;-)

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

Hmmm... but it issues update commands (= use_media_proxy?) at each
Re-INVITE, does it? And probably the dispatcher ignores them as long
as there is no change to active streams, correct? I really like the
way it works! So please don't get me wrong - I consider mediaproxy
a fantastic and well-architectured module.

My intention was to make suggestions to improve the engage-function,
as I've been really excited once I discovered it. Later I realized,
that there is not everything as smooth as suggested. At least for me -
but I thinnk others will face similar challenges.

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

Thank you for pointing this out, I'll do so!

Regards,
Thomas Gelf