Hi Lorenzo, rport stuff applies to VIA port and it used only for sending back the replies (to a request).
Your problem is the the Contact URI (the bogus port) which has nothing to do with rport. Regards, Bogdan lorenzo wrote: > 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 > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
