On 22/01/10 16:24, Bogdan-Andrei Iancu wrote: > Hi Lorenzo, > > I would say the STUN fails - STUN is used to discover both the IP and > PORT, so if the port is wrong, STUN failed. > > There is no issue with your cfg, simply stun did not manage to discover > the correct port - note that STUN does not work with symmetrical NATs.
Hi Bogdan, maybe i'm mistaken, but shouldn't it be rport that prevails here? the fact i use rport in my request means opensips knows i want the ip header's port to be stored and used to contact me, right? because the port that stun discovers is the one i used to connect to the stun server, which is not necessarily the same i'm going to use to connect to opensips! my undertanding is that if i'm using the rport parameter, i can specify ANY port in the sip header while forging a request, since rport will tell the UAS not to consider it! form rfc3581 (rport) : "If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter." have i missed the point? > Regards, > Bogdan thanks, Lorenzo _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users