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