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