[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