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 _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users