Hi, I’ve run this exact scenario against log_level 4 and sent you the output in a separate mail. It should be a hop-by-hop ACK against the 487, only thing that strikes me is that opensips already ACKS the 487 to the Callee side. Instead of sending the 487 all the way first before the ACK gets generated by the caller and routed..
Met vriendelijke groet, Rik Broers Voice Engineer Van: Bogdan-Andrei Iancu [mailto:[email protected]] Verzonden: 15 May 2017 10:42 Aan: Rik Broers <[email protected]>; [email protected] Onderwerp: Re: [OpenSIPS-Users] Cancel ACK routing Hi Rik, There is no need for such extra logs, just use the script_trace() function: http://www.opensips.org/Documentation/Script-CoreFunctions-2-3#toc43 Now, there must be something wrong with that ACK (it is a hop by hop ACK to a negative reply), if it is not caught by t_check_trans(). Could you run this function in debug 4, so we can see what is going on ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 05/15/2017 10:59 AM, Rik Broers wrote: Hi Bogdan, Put some logs in my script, and the ACK is hitting exit/red highlighted part. In this part of the sequential route. } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server t_relay(); exit; } else { xlog("L_WARN", "[$ci] ACK without matching transaction"); # ignore and discard exit; } } So apparently it can’t find a transaction. Should the ACK be forwarded all the way to the right endpoint? As that leg has already been acked by opensips directly according to the trace. Met vriendelijke groet, Rik Broers Voice Engineer Van: Bogdan-Andrei Iancu [mailto:[email protected]] Verzonden: 12 May 2017 18:28 Aan: [email protected]<mailto:[email protected]>; Rik Broers <[email protected]><mailto:[email protected]> Onderwerp: Re: [OpenSIPS-Users] Cancel ACK routing Hi Rik, So, without the TH part, it seems that the incoming ACK (from caller side) is not recognized and the 487 is retransmitted. How do you handle that ACK? are you sure it hits a t_relay() or t_newtran() function ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 05/12/2017 12:28 PM, Rik Broers wrote: Hi! I’m building a proxy between two public endpoints, so no nat involved luckily. I’ve got everything to work except for the CANCEL. It breaks the same if I start the call from the other endpoint. Attached a visual of the traffic flow. Not attached, at link here: https://www.dropbox.com/s/m45wwjlt4cmhy7k/Captuasdre.JPG?dl=0 Now I would like to fix the final 487 ACK bouncing, and it seems to me that opensips should just accept the ACK from the 487 and end the transaction. The script is based on the standard one after install with some routing logic. So the ACK is handled in the sequential path with this comment: # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server I also tried to fix/workaround it with the topology_hiding module, but as soon as the ACK (packet 12 in the diagram) is sent back opensips crashes with CRITICAL:core:free_lump: called on a not free-able lump:0x7f9ba2cc9d68 flags=2 and no 487 is being sent to the left endpoint. version: opensips 2.3.0-beta (x86_64/linux) git revision: 2f688b5 Crash dump with dbg on for the topo hiding scenario available on request, rather not share it on the list ☺ Did I hit an opensips bug or am I missing something? Regards, Met vriendelijke groet, Rik Broers Voice Engineer [email protected]<mailto:[email protected]> _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
