[OpenSIPS-Users] Problem: INVITE port mismatch

[Podrigal, Aron]

Have you tried using force_send_socket()?
On Jul 13, 2015 5:35 AM, "Albert Vallespi Ofertas" <
avallespi.ofertas at gmail.com> wrote:

> Hello again,
>
> 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
>> similar.
>>
>> - 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í
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150713/6f295a37/attachment.htm>