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

[Bogdan-Andrei Iancu]

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 
> <mailto:sip%3A5017 at myvoiptest.net>}
>  DBG:core:get_hdr_field: <To> [70]; uri=[sip:5017 at myvoiptest.net 
> <http://myvoiptest.net> ]
>  DBG:core:get_hdr_field: to body [<sip:5017 at myvoiptest.net 
> <http://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 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/20180412/6c174264/attachment-0001.html>