1XX, 2XX not relayed to caller

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

1XX, 2XX not relayed to caller

SamyGo
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:


 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={[hidden email]}
 DBG:core:get_hdr_field: <To> [70]; uri=[sip:5017@myvoiptest.net ]
 DBG:core:get_hdr_field: to body [<sip:5017@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 1XX, 2XX not relayed to caller

Bogdan-Andrei Iancu-2
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={[hidden email]}
 DBG:core:get_hdr_field: <To> [70]; uri=[<a class="moz-txt-link-freetext" href="sip:5017@">sip:5017@myvoiptest.net ]
 DBG:core:get_hdr_field: to body [<<a class="moz-txt-link-freetext" href="sip:5017@">sip:5017@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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={[hidden email]}
 DBG:core:get_hdr_field: <To> [70]; uri=[sip:5017@myvoiptest.net ]
 DBG:core:get_hdr_field: to body [<sip:5017@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users