Re: [BLISS] Multiple Session Appearances of an AOR using INVITE

On Fri, May 30, 2008 at 3:52 PM, Alan Johnston <alan@sipstation.com> wrote:
> A UA that does need to select a particular appearance number would use
> an approach similar to overlap dialing (multi-stage dialing).  An INVITE
> would be sent when the appearance number is requested (i.e. when the
> button is pressed, before dialing begins).  The appearance number
> selected would be carried in the INVITE, in a header field, for
> example.  The proxy would reject the INVITE with a 484 Address
> Incomplete response (see RFC 3578) if the appearance number is
> available.  The UA could then resend the INVITE after the URI has been
> dialed and then PUBLISH this appearance number to the ESC.  If the
> appearance number is not available, another response code such as 403
> would be sent.  The user could then select a different appearance number
> and resend the INVITE.

This approach generally sounds fine to me, but I see one problem. The
problem is that the appearance is not being shown as busy on other UAs
while the dialing is in progress. Since a 484 response will imply that
the appearance is available, would it make sense to also say that 484
will mean that the appearance has been won?

This way the UA can send a PUBLISH as soon as it gets the first 484
and the appearance can then be shown as busy on other UAs immediately.
Also, this way the 403 situation becomes rare because the window in
which multiple users can start dialing on the same appearance at the
same time becomes minimal.

--
Raj Jain
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss