<html><body bgcolor="#FFFFFF">
<p>Hi Doug,<br>
<br>
Here are the relevant sections (with a lot of other stuff deleted). Unfortunately, due the embedded biz logic I cannot post whole script.<br>
<br>
if (loose_route()) {<br>
if(is_method("INVITE")) {<br>
t_check_trans();<br>
if (check_route_param("mr=1")) {<br>
use_media_proxy();<br>
# Set flag so response will also get proxy applied<br>
setbflag(BFLAG_USED_MPROXY);<br>
};<br>
t_on_reply("reply_reinvite");<br>
t_relay();<br>
exit;<br>
}<br>
<br>
Within branch-route for initial INVITE (populated from usrloc):<br>
if ( need-mproxy ) {<br>
use_media_proxy();<br>
add_rr_param(";mr=1");<br>
setbflag(BFLAG_USED_MPROXY);<br>
}<br>
<br>
Both the reply handler for invite and reinvite have sections like:<br>
onreply_route[reply_reinvite] {<br>
if (isbflagset(BFLAG_USED_MPROXY)) {<br>
use_media_proxy();<br>
}<br>
}<br>
<br>
The logic for "need-mproxy" for me is quite complicated due to the number of different use cases I have to support. For the case you describe, it is just the cflag coming from usrloc.<br>
<br>
Regarding B's reply's Contact header, I used to do the same with nat_uac_test() and fix_nated_contact() but eventually gave up on it. As you say many ALGs break this. (Either out-right corruption or just put the wrong number in). Also, if B is behind a proxy that does outbound flow routing (RFC 5626) it will leave the private IP in the Contact header and the check will false trigger and corrupt the path. I ended up implementing flow-routing within opensips instead.<br>
<br>
Regards,<br>
Kennard<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=07BBFD29DFF463BA8f9e8a93df9@logitech.com" border="0" alt="Inactive hide details for Doug ---10/12/2010 11:36:10 AM--- Hi Kennard, Would you be so kind as to post what you did in regard"><font color="#424282">Doug ---10/12/2010 11:36:10 AM--- Hi Kennard, Would you be so kind as to post what you did in regards to the reply</font><br>
<br>
<font size="2" color="#5F5F5F">From: </font><font size="2">Doug <doug@wd.co.za></font><br>
<font size="2" color="#5F5F5F">To: </font><font size="2">users@lists.opensips.org</font><br>
<font size="2" color="#5F5F5F">Date: </font><font size="2">10/12/2010 11:36 AM</font><br>
<font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [OpenSIPS-Users] NAT and Re-INVITE</font><br>
<font size="2" color="#5F5F5F">Sent by: </font><font size="2">users-bounces@lists.opensips.org</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="4">Hi Kennard,<br>
<br>
Would you be so kind as to post what you did in regards to the reply handler? Also do you set the bflag if check_route_param succeeds and then let your reply handler check for a bflag?<br>
<br>
In regards to the private IP address, thats handled easily with the following:<br>
<br>
if(nat_uac_test("1"))<br>
{<br>
fix_nated_contact();<br>
}<br>
<br>
I also modded the code of nathelper.c to include a 64 check for nat_uac_test that checks the port number in the contact header against the source port of the packet (not sure if this breaks RFC's?), as I had an issue with a dumb ALG device stuffing up the port in the contact header on the 180 Ringing. It was suppose to be something like:<br>
</font><u><font size="4" color="#0000FF"><br>
</font></u><a href="sip:xxxx@1.2.3.4:17319"><u><font size="4" color="#0000FF">sip:xxxx@1.2.3.4:17319</font></u></a><font size="4"><br>
<br>
but instead, came through as:<br>
</font><u><font size="4" color="#0000FF"><br>
</font></u><a href="sip:xxxx@1.2.3.4:17319319"><u><font size="4" color="#0000FF">sip:xxxx@1.2.3.4:17319319</font></u></a><font size="4"><br>
<br>
which just broke everything else, so I added my check and if the contact header port and source port did not match, I simply called fix_nated_contact() to resolve it - this fixed the ALG issue, but still left the re-INVITE issue.<br>
<br>
I look forward to your assistance.<br>
<br>
Thanks<br>
Doug<br>
<br>
<br>
On 2010/10/12 8:02 PM, </font><a href="mailto:Kennard_White@logitech.com"><u><font size="4" color="#0000FF">Kennard_White@logitech.com</font></u></a><font size="4"> wrote: </font>
<ul>
<ul><font size="4">Hi Doug,<br>
<br>
I had similar problem. My solution is to use record-route variable: add_rr_param("mr=1") on initial INVITE at same time as first call to use_media_relay(). The later within loose_route block, I use check_route_param("mr=1") for re-INVITES and then re-invoke media relay if found. In that case I also install a reply handler for the reinvite and set the bflag. The reinvite reply handler then checks the bflag and invokes use_media_proxy on the reply. That solves the media problem for me.<br>
<br>
How are you handling the private IP in the Contact address in B's 200 response to A's re-INVITE? This contact address will become the R-URI of all subsequent in-dialog messages from A (e.g., INFO, MESSAGE, BYE).<br>
<br>
Regards,<br>
Kennard<br>
<br>
</font><img src="cid:1__=07BBFD29DFF463BA8f9e8a93df9@logitech.com" width="16" height="16" alt="Inactive
hide details for Doug ---10/12/2010 08:47:39 AM--- Hi All,
I've got a problem I'm not 100% sure how to resolve."><font size="4" color="#424282">Doug ---10/12/2010 08:47:39 AM--- Hi All, I've got a problem I'm not 100% sure how to resolve.</font><font size="4"><br>
</font><font color="#5F5F5F"><br>
From: </font>Doug <a href="mailto:doug@wd.co.za"><u><font color="#0000FF"><doug@wd.co.za></font></u></a><font color="#5F5F5F"><br>
To: </font>OpenSIPS users mailling list <a href="mailto:users@lists.opensips.org"><u><font color="#0000FF"><users@lists.opensips.org></font></u></a><font color="#5F5F5F"><br>
Date: </font>10/12/2010 08:47 AM<font color="#5F5F5F"><br>
Subject: </font>[OpenSIPS-Users] NAT and Re-INVITE<font color="#5F5F5F"><br>
Sent by: </font><a href="mailto:users-bounces@lists.opensips.org"><u><font color="#0000FF">users-bounces@lists.opensips.org</font></u></a>
<p><hr width="100%" size="2" align="left" noshade><font size="4"><br>
<br>
</font><tt><font size="4"><br>
Hi All,<br>
<br>
I've got a problem I'm not 100% sure how to resolve.<br>
<br>
Ok the scenario is, client A is on a public interface, Client B is on a <br>
private IP address and has cflag 6 set in the location table.<br>
<br>
Client A calls Client B via Opensips.<br>
<br>
Now during the initial INVITE, opensips locates Client B, loads the <br>
information, and naturally bflag is set to 6 (my NAT flag). This then <br>
triggers mediaproxy to get involved, and the call is established <br>
correctly, media passes from Client A ----> Mediaproxy ----> Client B.<br>
<br>
Now the problem is, the Client A device (Audiocodes ATA) sends a <br>
Re-INVITE to switchover to T.38. The process works pretty much the same, <br>
but follows the loose_route path due the call already being in a dialog <br>
(i think thats the right terminology).<br>
<br>
Client B receives the Re-INVITE, however, because loose_route doesn't <br>
know about the bflag (I've check with xlog and its not set during this <br>
phase), mediaproxy is not engaged (as the INVITE is coming form Client A <br>
who is not behind NAT). So when Client B responds, the SDP is a private <br>
IP address, and the call falls apart.<br>
<br>
Now I suppose what I could do is call "use_media_proxy()" from the <br>
onreply_route if the SDP is RFC1918 (nat_uac_test("8")), however, this <br>
would engage mediaproxy for only one leg of the call and not the Client <br>
A leg.<br>
<br>
The other option is I can force mediaproxy on all calls, which works, <br>
but now I have to have RTP flowing through my links for devices that <br>
could be speaking directly to each other.<br>
<br>
Has anyone had experience with this, or an idea of how to check during <br>
the loose_route phase if the Client B sisde is behind nat, or set a flag <br>
that remains consistent throughout the entire call flow (INVITE, 200Ok, <br>
Re-INVITE, 200OK, BYE).<br>
<br>
I look forward to your assistance.<br>
<br>
Many thanks<br>
Doug<br>
<br>
<br>
_______________________________________________<br>
Users mailing list</font></tt><tt><u><font size="4" color="#0000FF"><br>
</font></u></tt><a href="mailto:Users@lists.opensips.org"><tt><u><font size="4" color="#0000FF">Users@lists.opensips.org</font></u></tt></a><tt><u><font size="4" color="#0000FF"><br>
</font></u></tt><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"><tt><u><font size="4" color="#0000FF">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</font></u></tt></a><font size="4"><br>
</font><br>
<tt><font size="4"><br>
<br>
_______________________________________________<br>
Users mailing list<br>
</font></tt><a href="mailto:Users@lists.opensips.org"><tt><u><font size="4" color="#0000FF">Users@lists.opensips.org</font></u></tt></a><tt><font size="4"><br>
</font></tt><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"><tt><u><font size="4" color="#0000FF">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</font></u></tt></a><tt><font size="4"><br>
</font></tt><tt>_______________________________________________<br>
Users mailing list<br>
Users@lists.opensips.org<br>
</tt><tt><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></tt><tt><br>
</tt><br>
</ul>
</ul>
</body></html>