As part of the design of the call-completion feature, we are running into a problem which seems straightforward but seems to have no standardized solution. So the call-completion design committee is circulating the question to the Bliss membership for opinions.
Background: When a call is made, the call-completion design allows each destination UAS to send information back to the UAC giving indication that call-completion is available to calls to that UAS, and (often) a URI to contact to obtain call-completion services. The indication is a specific format of the Call-Info header inserted into the final response to the INVITE. (The final response is hoped to propagate back to the UAC.) In addition, if there is an HERFP mechanism, that mechanism can carry the final response with the Call-Info header back to the UAC. In any case, the effect is that call completion is by default handled on an end-to-end basis between the UAC and the UASs that receive its INVITE. Under some circumstances, an INVITE may propagate through a proxy that does complex call processing (e.g., an "automatic call distributor"), and that proxy may wish to control call completion processing itself, and not effectively delegate call completion processing to the downstream agents (which would be the default effect). For example, consider an ACD distributing calls to agents, and one agent is working from home. Although the agent's home phone may implement call completion, the ACD would want to integrate call completion requests for its incoming AORs into its call processing logic, and prevent the agent's home phone from attempting to provide call-completion for calls routed through the ACD. The difficulty arises because of the end-to-end design of call completion processing; the proxy does not have a good way to interfere with the operation of call completion between the UAC and a downstream UAS. Design alternatives: 1. Create a new header whose effect is to prevent a UAS from offering call completion services. The proxy would add this header to forwarded requests. Advantages: It is fully RFC 3261 compliant for a proxy to add a header to a request it is forwarding. Disadvantages: Creating a new header to carry exactly one bit of information. 2. Create a new option-tag, and allow a UAS to provide call completion information only if the new tag appears in a Supported header. The proxy would remove the option-tag from the Supported header as it was forwarding requests. Advantages: Aligns well with the concept of Supported enabling extensions. Disadvantages: Strictly speaking, RFC 3261 does not allow a proxy to delete a header when forwarding a request. Creating a new option-tag to carry exactly one bit of information. 3. The proxy could edit responses that are returned by UASs to remove the Call-Info headers. Advantages: Doesn't require additional standardized definitions. Disadvantages: Requires considerable editing of responses, which is not RFC 3261-complaint. Opinions? Dale _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
