[OpenSIPS-Users] Problem: INVITE port mismatch
Albert Vallespi Ofertas
avallespi.ofertas at gmail.com
Mon Jul 13 11:34:34 CEST 2015
We have re-checked the case, and I think there is no relation with
"user=phone" parameter in the r-uri.
We have verified that in our scenario, forwarding from UDP to TCP opensips
sends INVITE in the TCP side to a wrong port.
I think it changes origin and destination ports. This seems a opensips bug.
- Network1 is using UDP, and opensips listens at port UDP:eth1_IP:5060
- Network2 is using TCP, and opensips listens at port TCP:eth2_IP:5060
2015-07-10 19:46 GMT+02:00 Albert Ofertas <avallespi.ofertas at gmail.com>:
> Hi to all,
> We have a new opensips r.2.1 in a production environment where it is
> configured between two different networks.
> We are using always private networks, therefore there is not any NAT or
> - Network1 is using UDP, and opensips listens at port UDP:eth1_IP:5060
> - Network2 is using TCP, and opensips listens at port TCP:eth2_IP:5060
> We have observed that when we forward an INVITE from Network1 to Network2
> sometimes there is a port mismatch in the outgoing INVITE.
> This INVITE should go from opensipts TCP:eth2_IP:6xxxx (for example 63445)
> to the remote peer that uses TCP:REMOTE_IP:5060.
> What we have observed is that this INVITE many times and without a logical
> explanation mixes the ports.
> I mean, the r-uri is correct (example: XXXXXX at REMOTE_IP:5060;transport=tcp;user=phone),
> but the message is sent via TCP with the ports crossed.
> The wrong INVITE is going from TCP:eth2_IP:5060 to TCP:REMOTE_IP:6xxxx.
> We have observed that this incorrect behaviour in opensips is happening
> when we are using the parameter "user=phone" in the request uri.
> We have tested some minutes without the "user=phone" and we have not
> observed the port mismatch then.
> 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.
> ¿Could you please help us to solve this issue?
> Best regards
> Albert Vallespí
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users