As part of the design of the call-completion feature, we are running into a problem regarding data which needs to be carried from the UAC to UAS. So the call-completion design committee is circulating the question to the Bliss membership for opinions.
Background: In the call completion design, there are three circumstances where we want the UAC to supply certain parameters which will certainly seen by the UAS. The question is how to best accomplish this in the face of complex forking scenarios and the current definitions of SIP. In the original call from the UAC to the UAS, the UAC may wish to apply a specifically constructed unique identifier to the call. The idea of using it as the Call-Id was rejected because of the ubiquitous assumption in SIP that Call-Ids can be constructed arbitrarily (as long as they are unique). The current choice is to attach it to the >From header as the 'id' header parameter. (The conceptually ideal choice would be to attach it as a parameter to the Call-Id header, but the grammar does not allow that.) Advantages: Attaching 'id' to the From header is almost certain to work in existing systems. Disadvantages: The 'id' is not conceptually an attribute of the caller, but of the call itself. In the call completion request SUBSCRIBE, by which the UAC indicates that it wants to be notified when the UAS's user is available for another call, we wish to attach two parameters: 'id' is used to carry the Call-Id of the original call (or the 'id' paramater of the original INVITE, if there was one), and 'm' is used to carry the "mode" by which the original call failed. The current choice is to attach these to the request-URI. Advantages: This allows us to consider the SUBSCRIBE as identifying the record of a particular original call that is archived at the UAS, and so it is natural that when that original call is selected for re-call, the single subscription will receive that notice. Disadvantages: The above advantage is specious, as there can be multiple subscriptions regarding a single original call and we want to select only one subscription for re-call; thus different subscriptions to the same URI should receive different event information. Worse, any forking proxy is likely to discard the request-URI parameters. Another possibility is attaching these parameters to the event package name in the Event header. Advantages: Proxies are unlikely to alter the Event header. Disadvantages: Giving up the illusion that these subscriptions are passive observers of a data object that is not affected by which subscriptions exist. In the call completion re-call INVITE, by which the UAC contacts again the UAS, we also want to carry the 'id' value as an authenticator that this INVITE is an authorized call completion re-call, so that this INVITE can be given priority over other INVITEs. The current choice is to attach this parameter to the request-URI. Advantages: It might work, especially if the INVITE is sent directly to the UAS or a monitor that is responsible for handling call completion on behalf of the UAS. Disadvantages: Forking proxies are likely to discard the request-URI parameters. An alternative to all of the above is that we could define new header(s) to carry the required information. Advantage: It would work. Disadvantage: Defining a new header just for this one feature. Comments? Dale _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
