10 feb 2009 kl. 13.10 skrev Iñaki Baz Castillo:
2009/2/10 Johansson Olle E <[email protected]>:If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users.Hi, I don't fully agree on it: alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will "fail" because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes "force_rtpproxy()" this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition).
On the INVITE there's no need for ProxyB to allocate an rtpproxy, since the SDP already has public IP - fixed by Proxy A.
ProxyB must be well configured, this means that since "force_rtpproxy()" didn't success on the incoming INVITE, it must no execute "force_rtpproxy()" on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if "force_rtpproxy()" succeded in the incoming INVITE, and only run "force_rtpproxy()" for responses from bob if that bflag is on.
It should force RTPproxy on teh response from Bob, since Bob is a local user and the SDP includes a private IP.
"force_rtpproxy()" returns TRUE (1) just in case the SDP was modified.
Yes. /O
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
