In those cases where an intermediate node wants to interfere in the e2e
CC behavior, why doesn't it act as a B2BUA? IMO this is a case where
that could be appropriate.
Paul
[EMAIL PROTECTED] wrote:
> 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
>
_______________________________________________
BLISS mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/bliss
