Hi Lorenzo, When comes to NAT traversal, you can do it in two ways:
1) on the client (UAC) side - the client is doing the signalling in such a way that the server "sees" the traffic as coming from a public IP. This is actually STUN approach -> the server has 0 capabilities in handling NAT. 2) on the server side - the client has 0 capabilities in handling NAT traversal and the whole task must be done by server. In this case you need to configure opensips to do the nat traversal - to correct both signalling and RTP for coping with NAt. My understanding is you tried the first approach, but it fails due poor STUN/NAT working. So, you what to move into 2), right ? IF so, take a look at the nathelper module. Regards, Bogdan lorenzo wrote: > On 22/01/10 18:55, Bogdan-Andrei Iancu wrote: > >> 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. >> > > perfect, thanks for clarifying this! > > but if the problem is a wrong port in the Contact uri, can't $source_uri > fix the issue? (or fix_contact() maybe) > do they update/write to the user location database? > > i've been experimenting with both, in the main route, but they don't > seem to work, i.e. the ul always shows the wrong contact port.. > > >> 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
