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 <bog...@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:5...@myvoiptest.net} > DBG:core:get_hdr_field: <To> [70]; uri=[sip:5...@myvoiptest.net ] > DBG:core:get_hdr_field: to body [<sip:5...@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@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users