Subject: [BLISS] Call-completion design question: Suppressing CC processing by "downstream" agents

From: [email-masked]
Date: Fri, 22 Feb 2008 16:13:42 -0500

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-masked]
http://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Feb 2008 16:59:54 -0500

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

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 25 Feb 2008 12:16:23 -0500

> that could be appropriate.

I agree - a 'proxy' (the real meaning of proxy, not a b2bua) shouldn't
mess with this.  The example you give doesn't really stand up - a proxy
can't really be a very interesting ACD; it needs to be a b2bua to do
much of what real users expect of an ACD.

-- 
Scott Lawrence  tel:+1.781.229.0533;ext=162 or sip:[email-masked]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  CTO, Voice Solutions   - Bluesocket Inc. http://www.bluesocket.com/ 
                                           http://www.pingtel.com/

---

From: [email-masked]
Date: Tue, 26 Feb 2008 17:04:23 -0500

From: Scott Lawrence <[email-masked]>

Yes, I suppose that's true -- in any case that's complicated enough
that the middle device would want to explicitly manipulate call
completion, the middle device would be a B2BUA already.

Dale