[OpenSIPS-Users] 1XX, 2XX not relayed to caller

[SamyGo]

Hi,
So CSEQ is 2 but the caller sends another INVITE with CSEQ 3 which isn't
relayed and that doesnt happen 100% of time, so CSEQ was my first suspect.
VIA headers have some difference matching with a working call and I wonder
why. The same devices are known to be working just as good on production
multi-hop scenarios. I'm going to flush all my work and resort to the
sample config file and figure this out.

What confuses me is the enable_double_rr is turned ON as well..same flow of
call works for UDP-UDP, So, while there is an extra Record-Route in
there..why is it treated differently.

Let me share a trace shortly.

Regards,
Sammy

On Thu, Apr 12, 2018 at 4:16 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi,
>
> The 100 is never relayed, it is a hop by hop reply. So that is ok. On the
> 180, indeed, the TM/transaction module fails to match the reply to any
> transaction - have you actually inspected the VIA/Cseq/Callid to see if the
> do match ? Maybe the incoming 180 is indeed broken.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>   http://www.opensips.org/events/Summit-2018Amsterdam
>
> On 04/12/2018 08:21 PM, SamyGo wrote:
>
> Hi,
> Seems like I'm stuck with a very basic situation. I've 2 OpenSIPS boxes
> and 2 Users registered on each Proxy. Caller is on UDP, Destination is on
> TCP. Call made from A to B will not have its 1XX and 2XX relayed back to
> the originating Proxy: see this sngrep flow.
>
>
>
> So, naturally OpenSIPS-B triggers 408 Timeout.
>
> So iptables is off and I can see 180 Ringing and subsequent replies
> showing up in OpenSIPS logs like this:
> </img>
>
>  DBG:core:tcp_read_req: tcp_read_req end
>  DBG:core:tcp_read_req: Using the global ( per process ) buff
>  DBG:core:tcp_handle_req: content-length= 0
>  DBG:core:tcp_handle_req: Nothing more to read on TCP conn 0x7f93987cc9b8,
> currently in state 0
>  DBG:core:parse_msg: SIP Reply  (status):
>  DBG:core:parse_msg:  version: <SIP/2.0>
>  DBG:core:parse_msg:  status:  <180>
>  DBG:core:parse_msg:  reason:  <Ringing>
>  DBG:core:parse_headers: flags=2
>  DBG:core:get_hdr_field: cseq <CSeq>: <2> <INVITE>
>  DBG:core:parse_via_param: found param type 234, <received> =
> <18.11.20.74>; state=6
>  DBG:core:parse_via_param: found param type 232, <branch> =
> <z9hG4bK56988cb3-e13c-e811-961a-c45444377777>; state=6
>  DBG:core:parse_via_param: found param type 235, <rport> = <5060>; state=16
>  DBG:core:parse_via: end of header reached, state=5
>  DBG:core:parse_headers: via found, flags=2
>  DBG:core:parse_headers: this is the first via
>  DBG:core:receive_msg: After parse_msg...
>  DBG:core:forward_reply: found module nathelper, passing reply to it
>  DBG:core:parse_headers: flags=4
>  DBG:core:parse_to_param: tag=40adb5b3-e13c-e811-86eb-c4544411cd9b
>  DBG:core:_parse_to: end of header reached, state=29
>  DBG:core:_parse_to: display={}, ruri={sip:5017 at myvoiptest.net}
>  DBG:core:get_hdr_field: <To> [70]; uri=[sip:5017 at myvoiptest.net ]
>  DBG:core:get_hdr_field: to body [<sip:5017 at myvoiptest.net >]
>  DBG:core:get_hdr_field: content_length=0
>  DBG:core:get_hdr_field: found end of header
>  DBG:core:forward_reply: found module tm, passing reply to it
>  DBG:tm:t_check: start=0xffffffffffffffff
>  DBG:core:parse_headers: flags=22
>  DBG:core:parse_headers: flags=8
>  DBG:tm:t_reply_matching: failure to match a transaction
>  DBG:tm:t_check: end=(nil)
>  DBG:core:destroy_avp_list: destroying list (nil)
>
>
>
> For successful relaying the last few lines show a matched transaction. I
> suspected CSEQ and Via headers and going through the traces+logs meanwhile
> looking for some guidance as what params to look for.
>
>
> OpenSIPS is latest devel:
> version: opensips 2.4.0-dev (x86_64/linux)
> flags: STATS: On, SHM_EXTRA_STATS, DISABLE_NAGLE, USE_MCAST, SHM_MMAP,
> PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll, sigio_rt, select.
> git revision: 0ff609d
> main.c compiled on 19:11:13 Apr 11 2018 with gcc 5.4.0
>
> P.S: Same config works for other calls as well.
>
> Regards,
> Sammy
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180412/b00d239b/attachment.html>