You must have stun in your client so that you will have NAT public address filled instead of private address. According to RFC whatever the client is performing is correct. I mean responding to 192.168.0.100
On Fri, Jul 4, 2008 at 9:41 AM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote: > 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 -- " You must be the change you want to see in the world." - Mahatma Gandhi _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
