Inaki, I think RFC3261 is not totally dependable for NAT transversal. Symmetric respnse(RFC3581) must be adopted here.
-Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz Castillo Sent: Friday, July 04, 2008 11:42 PM To: [email protected] Subject: [Sip-implementors] NAT and "18.2.2 Sending Responses" Hi, imagine a request from NAT received by a UAS with publi IP: # INVITE from 80.80.80.80:5060 Via: SIP/2.0/UDP sip:192.168.0.100:5060 The UAS converts t to: Via: SIP/2.0/UDP sip:192.168.0.100:5060;received=80.80.80.80 Now imagine the UAS replies a 404 but gets an ICMP error, so it must perform: 18.2.2 Sending Responses o Otherwise (for unreliable unicast transports), if the top Via has a "received" parameter, the response MUST be sent to the address in the "received" parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP "port unreachable" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response. So finally it would send the response to IP 192.168.0.100:5060 that obviously is unreachable for the UAS. Or worse, 192.168.0.100 could be the private LAN of the UAS so the UAS would send the response to a host in its private LAN. Isn't it a problem in some way? Thanks. -- Iñaki Baz Castillo _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
