[OpenSIPS-Devel] "Early cancel" issue in the tm module

[Bogdan-Andrei Iancu]

Hi Maxim,

Thank you for your detailed email on the matter. Indeed, if there is no 
reply received on the branch, OpenSIPS internally cancel the branch 
(stops retransmissions and generates a 487 reply for the INVITE). 
Nevertheless, the branch gets marked as canceled and as soon as a reply 
is received on it (provisional), a CANCEL will be fired to UAS. Of 
course, the reply must be received within the transaction lifetime (wait 
timer).

With the approach you mentioned:
     - could you point to the RFC section mentioning this behavior ?
     - what happens if there is no reply at all from UAS ?

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 13.11.2015 01:41, Maxim Sobolev wrote:
> Hi Volks, there seems to be an issue in the way how the tm handles 
> early CANCEL, i.e. when a CANCEL arriving before the downstream UAS 
> gets chance to generate a 100 Trying reply, or that reply is still in 
> flight (or maybe 100 Trying is lost). In that case the OpenSIPS stops 
> outbound INVITE re-transmits and generates both 200 OK for CANCEL and 
> 487 Transaction Terminated for the INVITE. This only works if initial 
> INVITE has not reached the target UAS, otherwise inconsistent state of 
> session is produced, with UAC thinking that the transaction is over 
> with, while the UAS is still proceeding with call setup. Needless to 
> say this can produce all kind of weird things ranging from irritated 
> users to billing mismatches.
>
> This behavior comes from the RFC requirement that UAC cannot generate 
> CANCEL until at least one provisional reply has arrived, but 
> implementation is completely wrong in my view. Instead, it should be 
> only generating 200 Cancelling for cancel immediately (to stop any 
> CANCEL retransmits) and continue with re-transmitting INVITEs in due 
> course until either transaction timeout occurs in 32 or so seconds or 
> 100 Trying finally comes and then outbound CANCEL transaction can be 
> fired immediately and the rest of the logic can proceed as happens now 
> on regular CANCEL.
>
> I've made a little diagram explaining the current vs. "proper" 
> behavior. You can see it at the link below:
>
> https://docs.google.com/document/d/1mkNuqvQdw6a6j0iAmjvTssyu-VF-5i4d2Kut4Eg9qLk/pub
>
> In general this is very non-intuitive, but for INVITE transactions in 
> no circumstances retransmits should be terminated. Once the first 
> INVITE has left the port, there is no way for the  SIP proxy to know 
> if missing provisional response is due to that invite never being 
> received or due to response being lost or some propagation/processing 
> delay in between.
>
> This issue tracks back to the original SER code and so that all 
> releases are affected.
>
>
> -Max