[OpenSIPS-Users] Cancel ACK routing

Rik Broers RBroers at motto.nl
Mon May 15 03:59:18 EDT 2017


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

[https://www.motto.nl/sig_images/logo.png]<https://www.motto.nl/>

+31 (0)6 1472 0622
rbroers at motto.nl<mailto:rbroers at motto.nl>


Motto Communications
www.motto.nl<https://www.motto.nl>

[https://www.motto.nl/sig_images/nl_flag.png]<https://goo.gl/maps/PqlrB>.HEAD OFFICE • Zandbergweg 1 • 6361 HM • Nuth • +31 (0)45 404 0490
[https://www.motto.nl/sig_images/nl_flag.png]<https://goo.gl/maps/drgxY>.SALES OFFICE • Hogehilweg 15 • 1101 CB • Amsterdam • +31 (0)20 217 0707

[https://www.motto.nl/sig_images/linkedin.png]<https://www.linkedin.com/company/motto-voip-bv>. [https://www.motto.nl/sig_images/facebook.png] <https://www.facebook.com/MottoCommunications> . [https://www.motto.nl/sig_images/twitter.png] <https://www.twitter.com/motto_nl>


De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, vragen wij u om de inhoud niet te gebruiken, een retourbericht te sturen naar de afzender om aan te geven dat het verkeerd geadresseerd is, en de inhoud vervolgens te vernietigen.

The information taken in this message can be confidential and is only meant for the addressed. If you are not the rightful receiver of this message, we ask you, not to use the information in this message, inform the sender about the incorrectly delivered email and then destroy the contents of this email.



Van: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
Verzonden: 12 May 2017 18:28
Aan: users at lists.opensips.org; Rik Broers <RBroers at motto.nl>
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

rbroers at motto.nl<mailto:rbroers at motto.nl>





_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto: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/20170515/57c3871b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9798 bytes
Desc: image001.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/57c3871b/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 950 bytes
Desc: image002.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/57c3871b/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 500 bytes
Desc: image003.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/57c3871b/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 349 bytes
Desc: image004.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/57c3871b/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 638 bytes
Desc: image005.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/57c3871b/attachment-0009.png>


More information about the Users mailing list