[OpenSIPS-Users] Cancel ACK routing

[Rik Broers]

Hi John,

Yeah i'm using the uac_replace_from on the invite.
This does it's task perfectly, everything is manipulated correctly on the way forward and back.

Bogdan has looked into it deeper, and he is suspecting the VIA headers in the ACK.

In all the requests the caller side keeps using a domain name in the via header, and suddenly on the ACK (specifically the 487 ACK) it decides to use it's ip address only as via.. branch identifiers are correct though.

The rfc says this:
For all other request methods, a request is matched to a transaction
   if the Request-URI, To tag, From tag, Call-ID, CSeq (including the
   method), and top Via header field match those of the request that
   created the transaction


And the top via header does not match anymore so..
Seems to be a case of broken implementation :) I will slap the creators with the RFC and see what they are going to do.

To confirm I will run a test where I will remove the opensips proxy in between, and I suspect the cancel to be just as broken as it is now. 
Luckily the call is correctly handled cdr-wise so it shouldn't pose any major issues except for some unwanted retransmissions.

Regards,
Met vriendelijke groet,

Rik Broers
Voice Engineer


-----Oorspronkelijk bericht-----
Van: John Quick [mailto:john.quick at smartvox.co.uk] 
Verzonden: 16 May 2017 10:10
Aan: users at lists.opensips.org
CC: Rik Broers <RBroers at motto.nl>; 'Bogdan-Andrei Iancu' <bogdan at opensips.org>
Onderwerp: Re: [OpenSIPS-Users] Cancel ACK routing

I had something very similar happening on CANCEL ACK handling.
In my case, it was because I had changed the To header. 

The scenario I had was this:
Invites sent to OpenSIPS had a 4-digit prefix which appeared in both the R-URI and the To header. I wanted to remove the prefix.
It was easy to change the R-URI and strip the prefix off, but attempts to use uac_replace_to (from the UAC module) ended up with unexpected problems So I stripped the prefix from the To header using subst function instead.
That is when I noticed CANCEL would no longer be handled properly just like Rik is describing.
The TM module (t_relay) was tracking changes made to the R-URI but not those made to the To header.

Hope this helps you to identify the problem. Rik, are you changing the R-URI or any of the headers (To, From, etc) when the Invite is processed?

John Quick
Smartvox Limited