2009/6/9 Dan Pascu <[email protected]>: >> In case other proxy also tries to use RtpProxy for a request already >> forzed by other proxy, then "force_rtpproxy()" will return "false" >> since it detects the line "a=nortpproxy:yes" in the SDP so the second >> Rtpproxy is not used and $rc is false. >> > > Having to rely (and depend) on what other proxies do, for your own NAT > traversal is a bad design decision.
If we consider the hypothetical case in which a a VoIP platform is designed not just for PSTN or local-users-to-local-users calls, but also for real outbound calls to other domains managed by other proxies, then we cannot have control of how the NAT is handled in those remote proxies. The only we can do is "fix" our side, which involves "fixing" signaling and media when our user is behind NAT (with no STUN and so). This is: I would *never* rely on external proxies to handle my *own* NAT issues (my users behind NAT), I fix NAT in my platform so when the request leaves it, it seems to arrive from public IP (signaling and media). Of course, considering SIP just for a closed environments (provider2clients and clients2provider) is a limited vision (even if nowadays it's the real usage of SIP when involving end-users). This scenario simplifies a lot the use case so handling two media proxies for the same call is just *prohibited* by design :) Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
