Paul Kyzivat ha scritto: > Marco, > > I've wondered about this too. > > Obviously the UAC is free to send a CANCEL at any time, whether it > included an Expires in the INVITE or not. So the value of this header > has to be in what effect it has on the UAS. If the UAS does as > specified, then there is indeed no reason for the UAC to send a CANCEL. > > So, the purpose of the CANCEL must be to cover the case where the UAS > fails to abort the request on its own. But since the UAS *knows* the > UAC will send a CANCEL if it really cares, then there is even less > incentive for the UAS to handle this case. > > That means that the only real advantage to the UAS of doing this is so > that it can stop the call slightly sooner - by the amount of time it > takes for the CANCEL to be generated, get to the UAS, and be > processed. Since it can be presumed that the CANCEL will be coming in > that case, stopping sooner avoids the risk of the call being answered > in the interim, and then being hung up on. But this is a really > marginal benefit. > > Bottom line: I can see very little value in this feature. Me too, I found this "feature" investigating how to implement another feature in our B2BUA. Probably it is better to directly explain what my problem is.
A calls B through a B2B. A transfers B to C. C rings but never answers. After some times A sees that the transfer is not already performed (NOTIFY terminated not yet received) and wants to terminate the transfer (that is say to B to give up calling C) so that A can resume his call with B. One solution can be to put some "transfer-expire-time" parameter in our B2B that makes the B2B send a cancel in the new leg with C if C doesn't answer before that time. Of course the parameter is the same for every call and A cannot control this behaviour. Maybe there is another common solution. Thanks. -- Marco Ambu R&D Software Engineering Abbeynet S.p.A. - www.abbeynet.com <http://www.abbeynet.com> Phone: +390702339331 Call me for free: <http://www.marco-ambu.sitofono.it> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
