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

From: Alan Johnston <[email-masked]>
Date: Tue, 03 Jun 2008 11:24:32 -0500

Raj,

Thanks for your comments - see mine below.

Thanks,
Alan

Raj Jain wrote:
> On Fri, May 30, 2008 at 3:52 PM, Alan Johnston <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Venkatesh <[email-masked]>
Date: Tue, 3 Jun 2008 12:31:28 -0700

This approach is much simpler than BFCP but I have a couple of comments. You
want to make sure that people are not using 484 Address Incomplete for
purposes like overlap dialing (handling features like billing codes and
such). I am not sure if this proposal "semantically" alters 484 response and
if the SIPPING folks will have objections to this proposal as well.....

Thanks
Venkatesh

1. 484 Address incomplete has specific semantics with respect

On Fri, May 30, 2008 at 12:52 PM, Alan Johnston <[email-masked]> wrote:

> All,
>
> Here is an alternative approach that utilizes sending an INVITE to
> select/reserve/seize an appearance number.
>
> A UA that does not need to select a particular appearance number (or
> doesn't care) would just send an INVITE as normal.    The Appearance
> Agent would tell the proxy which appearance number was being used by
> inserting this information in a header field (such as a parameter in the
> Alert-Info header field) in the first non-100 Trying response sent back
> to the calling UA.  The UA would then PUBLISH this appearance number to
> the Dialog Event State Compositor for the AOR which would distribute
> details of the dialog and the appearance number to the other UAs in the
> group.
>
> If an INVITE is sent and no appearance number is available, the proxy
> would reject the INVITE with a suitable response code and perhaps a
> header field indication.
>
> Note that this approach does not actually require a B2BUA, but it does
> require a proxy that can act as a UAS and communicate with an Appearance
> Agent which keeps track of appearance number allocations.
>
> Comments and suggestions are most welcome!
>
> Thanks,
> Alan
>