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