<div dir="auto">You might want to read up on bridge mode, it allows you to meet the finely control which interface is presented during the SDP rewrites.<div dir="auto"><br></div><div dir="auto">All of the information on the various use cases is available in the module docs, I've used both successfully including some pretty complex request routing. </div><div dir="auto"><br></div><div dir="auto">The move to offer/answer with interface specifications works great, you'll just have to fire off the offer with different params when in the failure route so it will override your initial public/public selection from the initial invite processing</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Nov 2019, 12:27 Mark Farmer, <<a href="mailto:farmorg@gmail.com">farmorg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Răzvan</div><div dir="ltr"><br></div><div>My OpenSIPS/RTPProxy box has 2 interfaces, public(NAT) - for phones & internal - for Asterisk.</div><div>The issue is that if a call from one registered user to another is rejected & goes to failure_route() then I send the call to an Asterisk box for voicemail which is connected via the internal interface.</div><div><br></div><div>When the call is routed to Asterisk, I need the RTP to flow between RTPproxy & Asterisk on the internal interfaces so I need to have the SDP correct before it hits Asterisk. RTP to & from the phone needs to use the public interface.</div><div><br></div><div>Initial media flow:</div><div>phone<-->OpenSIPS/RTPproxy<-->phone</div><div><br></div><div>Voicemail media flow:</div><div><span style="color:rgb(0,0,0)"><font face="arial, sans-serif">phone<-->OpenSIPS/RTPproxy<-->Asterisk</font></span><br></div><div><span style="color:rgb(0,0,0)"><font face="arial, sans-serif"><br></font></span></div><div>What is the best way to achieve this?</div><div><br></div><div>Many thanks!</div><div>Mark.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 18 Nov 2019 at 12:50, Răzvan Crainea <<a href="mailto:razvan@opensips.org" target="_blank" rel="noreferrer">razvan@opensips.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Yes, the problem is definitely the fact that you are calling <br>
`rtpproxy_offer()` for the initial invite. Hence, when you run <br>
`fix_nated_sdp()`, you're trying to change the same IP once again - this <br>
is not possile in OpenSIPS.<br>
But I wonder why you need the `fix_nated_sdp()` if you are using <br>
RTPProxy. Can't you just use the `ip_address`[1] field to advertise the <br>
proper IP int he c= line.<br>
<br>
[1] <br>
<a href="https://opensips.org/html/docs/modules/3.0.x/rtpproxy.html#func_rtpproxy_offer" rel="noreferrer noreferrer" target="_blank">https://opensips.org/html/docs/modules/3.0.x/rtpproxy.html#func_rtpproxy_offer</a><br>
<br>
Best regards,<br>
Răzvan<br>
<br>
On 11/13/19 1:51 PM, Mark Farmer wrote:<br>
> Hi everyone<br>
> <br>
> In my failure_route I'm routing to an Asterisk box for voicemail & I <br>
> need to change the SDP c/o parameters to use the correct internal IP <br>
> address but using fix_nated_sdp() is not taking effect.<br>
> <br>
> if (t_check_status("486|408|603")) {<br>
> xlog("CUSTOM_LOG: User replied $T_reply_code - Routing <br>
> to Asterisk Voicemail service.");<br>
> prefix("VMR_");<br>
> rewritehostport("<a href="http://10.150.50.53:2404" rel="noreferrer noreferrer" target="_blank">10.150.50.53:2404</a> <br>
> <<a href="http://10.150.50.53:2404" rel="noreferrer noreferrer" target="_blank">http://10.150.50.53:2404</a>>");<br>
> force_send_socket(udp:10.150.50.51);<br>
> fix_nated_sdp(10,"10.150.50.51");<br>
> <br>
> if (!t_relay()) {<br>
> send_reply(500,"Internal Error");<br>
> }<br>
> exit;<br>
> }<br>
> <br>
> I get the CUSTOM_LOG entry so I know that the route is executing.<br>
> <br>
> Maybe I'm doing something wrong with the flags, I've tried:<br>
> fix_nated_sdp(2,"10.150.50.51");<br>
> fix_nated_sdp(8,"10.150.50.51");<br>
> fix_nated_sdp(10,"10.150.50.51");<br>
> <br>
> But when I examine the SDP in the resulting invite, the c/o parameters <br>
> are never changed.<br>
> I'm using rtpengine_offer/answer in the initial routing, could it be <br>
> related to that?<br>
> <br>
> I'm using OpenSIPS 3.0.1<br>
> <br>
> Best regards<br>
> Mark.<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
> <br>
<br>
-- <br>
Răzvan Crainea<br>
OpenSIPS Core Developer<br>
<a href="http://www.opensips-solutions.com" rel="noreferrer noreferrer" target="_blank">http://www.opensips-solutions.com</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Mark Farmer<br><a href="mailto:farmorg@gmail.com" target="_blank" rel="noreferrer">farmorg@gmail.com</a></div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><div><img src="https://www.x-on.co.uk/email/footer/General-Practice-Awards-shortlisted.jpg"></div><div><br></div><div><div><div><font size="4"><b><sup><font face="Verdana">0333 332 0000 | <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a> | <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a> <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a> <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font></sup></sub> </b></font><br><p><span style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
The information in this e-mail is confidential and for use by the addressee(s)
only. If you are not the intended recipient, please notify X-on immediately on <span>+44(0)333 332 0000</span> and delete the<br>message from your computer. If you are not a named addressee you must not use,
disclose, disseminate, distribute, copy, print or reply to this email. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>within this email may not necessarily
reflect the views of X-on or its associated companies. Although X-on routinely
screens for viruses, addressees should scan this email and any attachments<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>
<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p></div></div></div>