----- Original Message ----- From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 12:19 PM Subject: Re: [Sip-implementors] another problem related to multiple call legs at UAC > Bob Penfield wrote: > [snip] > > If the UAC only wants the first 200-OK, it can accept it. If it > > sees another 200-OK, it can just ACK it and send a BYE. > > I have seen this answer many times. > But I have never seen any discussion of the kind of user > experience this provides. More often than not, the callee will just get dead air. > > >From a callee perspective this kind of behavior will be identical > to the failed predictive dialer calls I frequently get. > It seems like a bad idea to be devising a protocol that > makes this behavior even more common. Proxies don't fork just because they feel like it. Typically, it is because the user (the callee) has registered from multiple endpoints (e.g. desk phone, home phone, mobile phone) so that all of those endpoints will be "invited" at the same time. In other words, he asked for it. Granted that is no comfort to the third party answering his phone that gets dead air. > > Minimally, it seems like there should be some way to > report the reason for the BYE. > Maybe a Warning header? > It would be even better to report the problem sooner. > Why can't there be a NAC to send as an alternative to an ACK? > This could stop the call before it is fully started. It is already too late. When the 200-OK arrives, the callee has already answered the call and there is no caller to connect them to. Besides, a NACK as opposed to ACK/BYE will only save a few milliseconds. > > But either way, this would provide a hook to notify the > callee why the caller didn't follow through on the call. > When I answer a call, I would prefer to receive a message: > "Sorry, this call has already been answered by another party" > before being hung up. Of course the calling UA could do this, > but it is a bit much to expect that. With the reason signalled, > the called UA can present this in an appropriate way. > The better solution would be to CANCEL the incomplete call legs (the 18x's recieved by the UAC) when the first 200-OK is received. However, even if they do this, there is still the possibility that the CANCEL and a subsequent 200-OK will "pass on the wire", so the UAC will still have to deal with it. > Paul Kyzivat > Cisco Systems > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
