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

Raj,

Thanks for your comments - see mine below.

Thanks,
Alan

Raj Jain wrote:
> 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?
>   

Yes, the Appearance Agent could consider this appearance in use and 
start a timer.  During this period, another UA requesting it would get a 
403.  If the original UA did not resend the INVITE or the INVITE failed, 
the timer would expire and this appearance number could be allocated again.

> 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.
>   

Right - this situation would be the race condition only - normally a UA 
would not request an appearance number already in use.

> --
> Raj Jain
>
>
>   

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