<div dir="ltr"><div><div><div>Hello again,<br><br></div>We have re-checked the case, and I think there is no relation with "user=phone" parameter in the r-uri.<br><br></div>We have verified that in our scenario, forwarding from UDP to TCP opensips sends INVITE in the TCP side to a wrong port.<br></div>I think it changes origin and destination ports. This seems a opensips bug.<br><div><br>- Network1 is using UDP, and opensips listens at port UDP:eth1_IP:5060<br>
- Network2 is using TCP, and opensips listens at port TCP:eth2_IP:5060<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-10 19:46 GMT+02:00 Albert Ofertas <span dir="ltr"><<a href="mailto:avallespi.ofertas@gmail.com" target="_blank">avallespi.ofertas@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi to all,<br>
<br>
We have a new opensips r.2.1 in a production environment where it is configured between two different networks.<br>
We are using always private networks, therefore there is not any NAT or similar.<br>
<br>
- Network1 is using UDP, and opensips listens at port UDP:eth1_IP:5060<br>
- Network2 is using TCP, and opensips listens at port TCP:eth2_IP:5060<br>
<br>
We have observed that when we forward an INVITE from Network1 to Network2 sometimes there is a port mismatch in the outgoing INVITE.<br>
<br>
This INVITE should go from opensipts TCP:eth2_IP:6xxxx (for example 63445) to the remote peer that uses TCP:REMOTE_IP:5060.<br>
What we have observed is that this INVITE many times and without a logical explanation mixes the ports.<br>
I mean, the r-uri is correct (example: XXXXXX@REMOTE_IP:5060;transport=tcp;user=phone), but the message is sent via TCP with the ports crossed.<br>
The wrong INVITE is going from TCP:eth2_IP:5060 to TCP:REMOTE_IP:6xxxx.<br>
<br>
We have observed that this incorrect behaviour in opensips is happening when we are using the parameter "user=phone" in the request uri.<br>
<br>
We have tested some minutes without the "user=phone" and we have not observed the port mismatch then.<br>
<br>
We must use the parameter "user=phone". This is a mandatory parameter in our case because we are sending always this INVITE to a MediaGateway that requires it to translate the uri and send the call to the telephony network.<br>
<br>
¿Could you please help us to solve this issue?<br>
<br>
Best regards<br>
<br>
Albert Vallespí</blockquote></div><br></div>