rupert.organ@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.