Comments below.
Bob Penfield wrote:
>
> ----- 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.
Sure, he asked for it. But as you say, that is no comfort,
because you can't tell why you are getting all those dead air calls.
But if you got notified that someone else had taken the call, the
annoyance turns into a feature.
>
> >
> > Minimally, it seems like there should be some way to
> > report the reason for the BYE.
> >
>
> Maybe a Warning header?
Yeah, but Warning only goes on replies, so you can't put it
on an ACK or BYE.
>
> > 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.
Of course it is too late to prevent ringing the phone.
But a NACK would make it clear that the call failed,
rather than simply being a very brief call. And it might
make some difference in how the user is alerted to the situation.
But I agree this can be managed either by NACK or ACK/BYE.
And ACK/BYE clearly requires less change.
But it does then seem that there should at least be some way
to indicate the reason for the BYE, that could then be
rendered to the user.
>
> >
> > 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
