El Viernes, 29 de Mayo de 2009, Iñaki Baz Castillo escribió: > 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.
Of course, what I mean is that serial and parallel forking with different NAT treatment for each branch is a common requeriment (IMHO). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
