[Serusers] ReTransmission of CANCELs on 0.9.7

[Frank Durda IV]

rupert.organ at bt.com wrote:
>
> Hi All,
>
> Has anyone come up against an issue on 0.9.6 / 0.9.7 whereby a SIP App
> Server, delivers a CANCEL to the SER.
> The SER proxies the CANCELs to all the forked endpoints.
> At the same time it sends "200 Cancelling" back to the SIP App
> server...(this suppresses CANCEL retransmission from the SIP App
> server).
> If one of the CANCELs from the SER to the SIP UA gets lost....the phone
> keeps ringing.
> There is no CANCEL retransmission on the SER !!!
> There is CANCEL retransmission on the SIP App, but when it sends SER
> replies "no pending branches"
>
> Ideally want the SER do CANCEL retransmissions. I understand the timers
> were rewritten in 0.10.x but this is not hardened version like
> 0.9.6....any suggestions?
>
> Thanks in advance
>
> Rupert

Yes, SER behavior is obnoxious or even wrong for CANCEL,  even for
simple cases, such as the switch that SER forwards the CANCEL to
rejects it.  In that situation, SER has already sent a "200 cancelling",
and can now only discard the rejection message.   So the call continues
on downstream of SER but upstream thinks the handshake is complete.
Does this generate billing disputes?  You bet it does, such as when the
called party is a IVR and never hangs up or hangs up only after a day or 
more.

Due to a bug in the branch computation (chosing header elements that can
change for re-computing the branch tag for subsequent messages of the
same command sequence), we used to see this problem all the time.

Regardless of what the RFC may say on the subject, really SER should
wait and return the the response to the CANCEL rather than assuming
it is going to work and faking its own reply.  I really don't see another
rational way to handle it.