Re: [OpenSIPS-Users] strange behavior with TCP reply port
On 19.08.2021 22:10, Jeff Pyle wrote: Do you have any thoughts what this might break? I wouldn't worry about it, as I've never seen a client complain that OpenSIPS included "received=xxx;rport=xxx" in the reply's Via header, so it can properly route the reply to its source port. And even if some of these UACs do not support those RFC 3261 parameters, they will outright ignore them and process the reply normally. Best, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2021 Distributed | www.opensips.org/events ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] strange behavior with TCP reply port
Hi Liviu, You're probably right. And, force_rport() appears to solve the problem. I'm calling it first thing in the script so all the replies go to the right place. Basic testing seems okay, even on UDP connections into proxy where everything is 5060. Do you have any thoughts what this might break? - Jeff On Mon, Aug 16, 2021 at 4:06 PM Liviu Chircu wrote: > On 11.08.2021 22:01, Jeff Pyle wrote: > > the sl_send_reply() function opens a new TCP socket to the UAC on the > IP:port listed in the original message's Contact, rather than sending the > 100 on the existing socket (using the ephemeral port) > > Hi, Jeff! > > Just to frame the problem better: are you sure the reply's target IP:port > is equal to the request's Contact header and not the topmost Via header? > Maybe a *force_rport()* before calling *sl_send_reply()* is everything > that's needed here. *fingers crossed* > > Best, > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS Summit 2021 Distributed | www.opensips.org/events > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] strange behavior with TCP reply port
On 11.08.2021 22:01, Jeff Pyle wrote: the sl_send_reply() function opens a new TCP socket to the UAC on the IP:port listed in the original message's Contact, rather than sending the 100 on the existing socket (using the ephemeral port) Hi, Jeff! Just to frame the problem better: are you sure the reply's target IP:port is equal to the request's Contact header and not the topmost Via header? Maybe a /force_rport()/ before calling /sl_send_reply()/ is everything that's needed here. *fingers crossed* Best, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2021 Distributed | www.opensips.org/events ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] strange behavior with TCP reply port
Hello,
This is on the 3.1.3~20210731~b333a222f-1 from the Debian 3.1-nightly repo.
Typically I run with
modparam("tm", "auto_100trying", 0)
so I can manually send a 100 with
sl_send_reply(100, "Trying");
earlier in the script, before blocking processes like DB lookups and such.
No problem...until today. On a TCP (TLS) connection, the sl_send_reply()
function opens a new TCP socket to the UAC on the IP:port listed in the
original message's Contact, rather than sending the 100 on the existing
socket (using the ephemeral port) the UAC used for its TCP socket to us.
Future downstream replies are relayed back upstream to the ephemeral port.
In other words, only the 100 Trying message from sl_send_reply() is opening
a new socket back upstream.
The auto_100trying option from tm, however, sends its 100 messages to the
ephemeral port of the UAC.
How can I get the sl_send_reply() function to reply on the existing TCP
socket?
Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
