[BUG] b2b_entities request route is not fired for any non initial request with TLS RURI

[babakyakhchali]

OpenSIPS version you are running

3.2.19

Describe the bug

When using b2b with a tls socket, b2b_entities request route is not launched for any mid dialog request, for example a BYE.
To Reproduce

1. Start OpenSIPS
2. Start a call from a TLS client
3. End the call from TLS client
4. BYE is not hitting b2b_entities request route
   Expected behavior

b2b entities request route must be called.
Relevant System Logs

Dec 18 12:31:00 SBC [234667]: DBG:core:parse_msg:  method:  <BYE>
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_msg:  uri:     <sip:172.25.17.142;transport=tls>
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_msg:  version: <SIP/2.0>
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_headers: flags=ffffffffffffffff
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK3810360835>; state=16
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_via: end of header reached, state=5
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_headers: via found, flags=ffffffffffffffff
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_headers: this is the first via
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_to_param: tag=B2B.232.80.1734512456
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_to_param: end of header reached, state=13
Dec 18 12:31:00 SBC [234667]: DBG:core:_parse_to: end of header reached, state=29
Dec 18 12:31:00 SBC [234667]: DBG:core:_parse_to: display={}, ruri={sip:[email protected]}
Dec 18 12:31:00 SBC [234667]: DBG:core:get_hdr_field: <To> [50]; uri=[sip:[email protected]]
Dec 18 12:31:00 SBC [234667]: DBG:core:get_hdr_field: to body [<sip:[email protected]>]
Dec 18 12:31:00 SBC [234667]: DBG:core:get_hdr_field: cseq <CSeq>: <2> <BYE>
Dec 18 12:31:00 SBC [234667]: DBG:core:get_hdr_field: content_length=0
Dec 18 12:31:00 SBC [234667]: DBG:core:get_hdr_field: found end of header
Dec 18 12:31:00 SBC [234667]: DBG:core:receive_msg: After parse_msg...
Dec 18 12:31:00 SBC [234667]: DBG:core:receive_msg: preparing to run routing scripts...
Dec 18 12:31:00 SBC [234667]: DBG:core:parse_headers: flags=ffffffffffffffff
Dec 18 12:31:00 SBC [234667]: DBG:b2b_entities:b2b_prescript_f: start - method = BYE
Dec 18 12:31:00 SBC [234667]: DBG:b2b_entities:b2b_prescript_f: <uri> host:port [172.25.17.142][0]
Dec 18 12:31:00 SBC [234667]: DBG:core:grep_sock_info_ext: checking if host==us: 13==13 &&  [172.25.17.142] == [172.25.17.142]
Dec 18 12:31:00 SBC [234667]: DBG:core:grep_sock_info_ext: checking if port 5061 matches port 5060
Dec 18 12:31:00 SBC [234667]: DBG:core:check_self: host != me
Dec 18 12:31:00 SBC [234667]: DBG:b2b_entities:b2b_prescript_f: RURI does not point to me

OS/environment information

• Operating System:
• OpenSIPS installation:
• other relevant information:

Additional context

I checked the code and it seems problem is caused by using default SIP_PORT when RURI does not contain a port. When the request is sent to a TLS socket and port is not present in RURI, 5061 or zero must be used otherwise b2b_entities matching fails according to the above logs. This change solved the problem for me:

diff --git a/modules/b2b_entities/dlg.c b/modules/b2b_entities/dlg.c
index de89d24ab..7a665e8a1 100644
--- a/modules/b2b_entities/dlg.c
+++ b/modules/b2b_entities/dlg.c
@@ -809,7 +809,7 @@ int b2b_prescript_f(struct sip_msg *msg, void *uparam)
        if(method_value!= METHOD_CANCEL)
        {
                LM_DBG("<uri> host:port [%.*s][%d]\n", host.len, host.s, port);
-               if (!check_self( &host, port ? port : SIP_PORT, msg->rcv.proto))
+               if (!check_self( &host, port , msg->rcv.proto))
                {
                        LM_DBG("RURI does not point to me\n");
                        return SCB_RUN_ALL;

[github-actions]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[bogdan-iancu]

Hi @babakyakhchali , passing a 0 value port to check_self() means ignoring the port check... which is not ok IMO.
If no port is found in the URI, the default (as per protocol) should be assumed.
BUT, what puzzles me is why there is no port in that RURI - as it is a BYE, a sequential requests, that RURI comes from a Contact from an INVITE/200OK generated by OpenSIPS B2B. And AFAIK, OpenSIPS is always filling in the port. Could you check the Contact hdr - or if you have the trace of the call, please PM it to me.