[OpenSIPS-Users] OpenSIPS 1.7.0 Topology Hiding and NAT Traversal

Bogdan-Andrei Iancu bogdan at opensips.org
Thu Sep 15 19:41:58 CEST 2011


Hi Jeremy,

On 09/15/2011 07:07 PM, Jeremy Childs wrote:
> Thanks, for the reply, Bogdan.
>
> I see what you're getting at, but the problem runs a little deeper 
> that this, though. For the reply from the NATed UA, the dialog module 
> needs to store the "fixed" contact, and it has no way of getting this 
> information, as it only looks at the incoming header, not what 
> fix_nated_contact has already pushed into a lump.
I agree with this limitation - but this will affect only the case when 
the dialog module has to send in dialog requests (like BYE).

>
> In your opinion, how difficult would it be to just make $ct writable? 
> If it was writable, then nathelper could be coerced into putting 
> $avp(contact) into $ct, where it could presumable be read normally by 
> dialog.so. This assumes that modules have access to core variables 
> that may have changed since the packet was received.
The problem here is more complex as with the current design, changing a 
change is impossible - basically you should first undo the prev change, 
before doing a new one.

>
> I recently ran into a similar problem with codec_delete and friends 
> where I need to remove a codec that has no a=rtpmap entry. 
> codec_delete can't find the coded to remove it, as it has no rtpmap 
> entry, and once codec_delete was done removing the codecs it could 
> find, any textops I ran on the SDP after that point corrupted the packet.
I'm not really following. Could show a simple example with an SDP + ops 
you are doing?

Regards,
Bogdan

>
> Any suggestions on how we can remove this one-rewrite limitation?
>
> On 11-09-14 11:47 AM, Bogdan-Andrei Iancu wrote:
>> Hi Jeremy,
>>
>> Indeed, seems to be an incompatibility here...What I would suggest is 
>> a bit of a trick, to manually handle the NATed contact in a dialog 
>> variable...Haven;t tried it, just an idea.
>>
>> On initial INVITE :
>>
>> modparam("nathelper", "received_avp", "$avp(contact)")
>> ...
>> topology_hiding();
>> if (nat_uac_test()) {
>> 	fix_nated_register(); # puts the fix contact into received avp
>> 	$dlg_val(caller_contact) = $avp(contact);
>> }
>> ...
>>
>>
>> And for sequential requests:
>> ...
>> loose_route();
>> ...
>> if ( match_dialog() ) {
>>      # sequential request from callee to caller?
>>      if ($DLG_dir=="UPSTREAM") $ru = $dlg_val(caller_contact) ;
>> }
>>
>> Again, not tested, not sure it will work, but just an idea :)
>>
>> Regards,
>> Bogdan
>>
>> On 09/13/2011 07:30 PM, Jeremy Childs wrote:
>>> I'm having a problem with the dialog module's topology hiding when a 
>>> UA is behind a NAT.
>>>
>>> If I call
>>>
>>> if (nat_uac_test()) {
>>>     fix_nated_contact();
>>> }
>>> topology_hiding();
>>>
>>> The Contact header is rewritten twice - once by fix_nated_contact() 
>>> and again by topology_hiding(). This results in an invalid contact 
>>> header.
>>>
>>> Is there an obvious way I'm missing that could make these two 
>>> modules coexist, or is the best solution to add NAT knowledge to 
>>> dlg_tophiding.c? This seems like a lot of code to duplicate.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> -- 
>> Bogdan-Andrei Iancu
>> OpenSIPS eBootcamp - 19th of September 2011
>> OpenSIPS solutions and "know-how"
>


-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 19th of September 2011
OpenSIPS solutions and "know-how"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110915/e48c3b71/attachment-0001.htm>


More information about the Users mailing list