El Viernes, 29 de Mayo de 2009, Thomas Gelf escribió: > 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.
I agree on it. Serial and parallel forking are not "future undefined problems". The both cases you mention as examples have been common requeriments in some deployments I've done. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
