19 Nov
2009
19 Nov
'09
6:08 p.m.
rupert.organ(a)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.