<div dir="ltr">Add this in your route:<div><br></div><div>subst_uri('/(sip:.*);transport=tcp/\1/');</div><div><br></div><div>To remove transport=tcp from request-uri. </div><div><br></div><div>This should fix it.</div>
<div><br></div><div>Regards,</div><div>Ali Pey<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 6, 2013 at 2:15 PM, Simon Quigley <span dir="ltr"><<a href="mailto:squigley@versature.com" target="_blank">squigley@versature.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>
I've done some more testing, and it seems the issue I'm having with the NATed contact is related to the UA I'm using.<br><br></div>If I use empathy/telepathy-sofiasip, then the contact isn't being mangled properly, which causes it to send the 200 OK packet after answering, receive no ACK, and continue resending the 200 OK, until it gives up and sends a BYE.<br>
</div><br>The same behaviour occurs if I use sipdroid, however it doesn't send a BYE when it doesn't receive an ACK, but the call still isn't up properly, and when I do hang up, it doesn't send a BYE, so the originating UA (and switch) thinks the call is still up.<br>
<br></div>However, if I use the built in Android SIP client, it's contact is mangled properly, and so the OK / ACK process works properly.<br><br></div>How can I debug to see what the fix nated contact function is doing, to see if I can work out what the differences between these UA's packets are?<br>
<br></div>Thanks<br></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 1, 2013 at 5:44 PM, Simon Quigley <span dir="ltr"><<a href="mailto:squigley@versature.com" target="_blank">squigley@versature.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Bogdan,<br><br>Thanks for your response, your suggestion was much appreciated, and gave me a good direction to work in.<br>
<br></div>You are correct, I was trying to mix stateless and stateful routing together, I realised after watching the webinar.<br>
<br></div>I've made some changes to my configuration file to use record_route() and loose_route(), in a few different ways, but it hasn't made any difference.<br><br></div><div>The 200 OK is always sent back to the switch containing the non routable IP in the contact of the device, rather than fix_nated_contact changing it to the IP the packet arrives from, and it's also failing to match it and translate it for the ACK response to get to the device.<br>
<br></div><div>I've enabled debugging, and looking through the output, I think it's an issue with matching the dialogue.<br></div><div><br>Here's the config I'm using now:<div><br><br>listen=udp:[internal VM IP]:5060<br>
listen=tcp:[internal VM IP]:5060<br><br>disable_tcp=no<br><br></div>advertised_address="[dns name]"<br>alias="[dns name]"<div><br><br>route{<br> if (src_ip != "[switch ip]"){<br>
# from device<br></div>
if (!is_method("REGISTER|MESSAGE")) {<div><br> if (is_method("INVITE")) {<br> fix_nated_sdp("7");<br></div> record_route();<div>
<br> }<br> else if (is_method("OPTIONS")){<br>
exit;<br> }<br></div> else {<br> loose_route();<br> fix_nated_contact();<br> if (has_totag()){<br> fix_nated_sdp("7");<br>
}<br> t_relay("udp:[switch ip]:5060");<div><br> }<br> }<br> }<br><br> else if (src_ip == "[switch ip]"){<br> # from switch<br> if (is_method("INVITE")) {<br>
</div>
fix_nated_contact();<br> fix_nated_sdp("7");<br> record_route();<br> }<br> else {<br> loose_route();<div><br> }<br> <br> # mangle to TCP<br>
$du = $ru + ";transport=tcp";<br><br></div> t_relay();<br> }<br> exit;<br>}<br><br></div>Is there something obvious that I'm doing wrong?<br><br></div>Thanks again for your help.<br></div>
<div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 4:52 AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<u></u>
<div text="#000000" bgcolor="#ffffff">
<tt>Hello Simon,<br>
<br>
Most probably it is a mistake on the way you do record_routing
(for initial INVITE) and loose_route (for sequential requests).
All sequential requests are driven by this mechanism. If the case,
check how it suppose to work :<br>
<a href="http://www.opensips.org/Documentation/Webinars#toc12" target="_blank">http://www.opensips.org/Documentation/Webinars#toc12</a> (5.5)<br>
<br>
Basically you need to do record_route() for INVITE and
loose_route() for ACK - OpenSIPS will take care of changing the
interface for the ACK after the loose_route() call.<br>
<br>
Regards,<br>
</tt>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre><div><div>
<br>
On 10/25/2013 07:42 PM, Simon Quigley wrote:
</div></div><blockquote type="cite"><div><div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hello,<br>
<br>
</div>
I'm trying to use OpenSIPS as a TCP to UDP proxy, (with
the registrar module disabled) connecting all sorts of
devices from different IP addresses over TCP to a UDP
switch.<br>
<br>
So far I've managed to get OpenSIPS configured to change
the contact header, and the SDP, append the transport,
and forward the packets correctly, for making an
outbound call (from TCP device to UDP switch).<br>
<br>
</div>
I've got incoming to work somewhat (from UDP switch to TCP
device), the INVITE will pass, and the TRYING/RINGING gets
back to the switch, however the issue I'm having is that
the OK packet from the TCP device is sent to the switch,
which responds with the ACK, however the contact header is
wrong, and OpenSIPS is trying to sent the ACK to the
internal non routable IP of the device.<br>
<br>
As a result the call comes up, but the device has an ACK
timeout and drops the call.<br>
<br>
</div>
I'm having difficulties working out how to get the contact
header mangled sufficiently for the OK/ACK to contain the
routable IP of the TCP device, rather than it's
internal/behind NAT IP.<br>
<br>
</div>
I've tried removing the header, using loose_route, using
t_relay, and (am currently attempting) to use route(relay).<br>
<br>
</div>
<div>Also of relevance, is the fact that I'm running OpenSIPS on
a Google Compute VM, so it's behind 1 to 1 NAT, with a non
routable IP on the VM, but I have assigned a static routable
IP to the 1 to 1 NAT, and I have DNS pointing to this routable
IP.<br>
</div>
<div><br>
</div>
Here's my config file, excluding default values/routes etc:<br>
<br>
listen=udp:[internal VM IP]:5060<br>
listen=tcp:[internal VM IP]:5060<br>
<br>
disable_tcp=no<br>
<br>
advertised_address="[DNS name]"<br>
alias="[DNS name]"<br>
<br>
route{<br>
if (src_ip != "[switch ip]"){<br>
# from device<br>
if (is_method("INVITE")) {<br>
fix_nated_sdp("7");<br>
}<br>
else if (is_method("OPTIONS")){<br>
exit;<br>
}<br>
<br>
fix_nated_contact();<br>
forward ("udp:[switch ip]:5060");<br>
}<br>
<br>
else if (src_ip == "[switch ip]"){<br>
# from switch<br>
if (is_method("INVITE")) {<br>
fix_nated_sdp("7");<br>
}<br>
else if (is_method("ACK")) {<br>
fix_nated_contact();<br>
}<br>
<br>
# mangle to TCP<br>
$du = $ru + ";transport=tcp";<br>
<br>
route(relay);<br>
}<br>
<br>
exit;<br>
}<br>
<br clear="all">
<div>
<div>
<div>
<div>
<div>
<div>Is the issue perhaps related to the fact I'm not
recording a route, so it doesn't know how to
correctly route the response, or am I just missing
something obvious?<br>
<br>
</div>
<div>Thanks,<br>
Simon<br>
</div>
<div><br>
-- <br>
Simon Quigley, Systems Engineer<br>
Versature Corp. | <a value="+18774983772">877-498-3772 x128</a><br>
<br>
Follow us on Twitter - <a href="http://twitter.com/Versature" target="_blank">http://twitter.com/Versature</a><br>
Check out the Versature Blog - <a href="http://inside.versature.com" target="_blank">http://inside.versature.com</a>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div><pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>
Simon Quigley, Systems Engineer<br>
Versature Corp. | <a value="+18774983772">877-498-3772 x128</a><br>
<br>
Follow us on Twitter - <a href="http://twitter.com/Versature" target="_blank">http://twitter.com/Versature</a><br>
Check out the Versature Blog - <a href="http://inside.versature.com" target="_blank">http://inside.versature.com</a>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>
Simon Quigley, Systems Engineer<br>
Versature Corp. | <a value="+18774983772">877-498-3772 x128</a><br>
<br>
Follow us on Twitter - <a href="http://twitter.com/Versature" target="_blank">http://twitter.com/Versature</a><br>
Check out the Versature Blog - <a href="http://inside.versature.com" target="_blank">http://inside.versature.com</a>
</div>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div><img class="" src="https://contactmonkey.com/api/v1/tracker?cm_session=a2ff65e6-08f2-48ed-ad76-8a3be4e7e319&cm_type=open&cm_user_email=alipey@gmail.com"></div></div>