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 PROTECTED]> 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 protected] https://www.ietf.org/mailman/listinfo/bliss
