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