<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Jeremy,<br>
<br>
On 09/15/2011 07:07 PM, Jeremy Childs wrote:
<blockquote cite="mid:4E7222CC.3050103@ssimicro.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Thanks, for the reply, Bogdan.<br>
<br>
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.<br>
</blockquote>
I agree with this limitation - but this will affect only the case
when the dialog module has to send in dialog requests (like BYE).<br>
<br>
<blockquote cite="mid:4E7222CC.3050103@ssimicro.com" type="cite"> <br>
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.<br>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:4E7222CC.3050103@ssimicro.com" type="cite"> <br>
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.<br>
</blockquote>
I'm not really following. Could show a simple example with an SDP +
ops you are doing?<br>
<br>
Regards,<br>
Bogdan<br>
<br>
<blockquote cite="mid:4E7222CC.3050103@ssimicro.com" type="cite"> <br>
Any suggestions on how we can remove this one-rewrite limitation?<br>
<br>
On 11-09-14 11:47 AM, Bogdan-Andrei Iancu wrote:
<blockquote cite="mid:4E70E8BD.5060401@opensips.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Jeremy,<br>
<br>
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.<br>
<br>
On initial INVITE :<br>
<br>
<pre class="programlisting">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) ;
}
</pre>
<br>
Again, not tested, not sure it will work, but just an idea :)<br>
<br>
Regards,<br>
Bogdan<br>
<br>
On 09/13/2011 07:30 PM, Jeremy Childs wrote:
<blockquote cite="mid:4E6F8540.7000607@ssimicro.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<font size="-1">I'm having a problem with the dialog module's
topology hiding when a UA is behind a NAT.<br>
<br>
If I call <br>
<br>
if (nat_uac_test()) {<br>
fix_nated_contact();<br>
}<br>
topology_hiding();<br>
<br>
The Contact header is rewritten twice - once by
fix_nated_contact() and again by topology_hiding(). This
results in an invalid contact header.<br>
<br>
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.<br>
</font>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 19th of September 2011
OpenSIPS solutions and "know-how"</pre>
</blockquote>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 19th of September 2011
OpenSIPS solutions and "know-how"</pre>
</body>
</html>