[cc] Proposed CCXML Changes From F2F vs JCC, etc

Based on CCXML 1.0 Working Draft 2, September 3.

[[[ add the following text in Section 2: ]]]

Recognizing that implementations may choose to use one of many telephony
APIs (JAIN Call Control, ECMA CSTA, S.100, etc), we have tried to make the
call control model in CCXML sufficiently abstract that it can accommodate
all major APIs.  For relatively simple types of call control, this
abstraction is straightforward.  Our basic philosophy in this regard has
been to "make simple things simple to do."   Outdial, transfer (redirect),
two-party bridging, and many forms of multi-party conferences fall within
this classification.

For more complex forms of call control and media control (e.g., conference
floor control), we have decided reluctantly that a lower-level, more
granular, and more complex set of tags and events is needed.  This is under
further study at this time.  We have set these goals for this study:

- to accommodate different underlying telephony APIs and provide access to
as much of their functionality as possible

- to eschew "escapes" to implementation-dependent techniques to the greatest
possible degree, since these would compromise interoperability

- to facilitate decomposition of CCXML documents so that a complex call
scenario does not require a single massive document

- to provide a kind of "macro" capability so that low-level, granular call
control actions can be aggregated, encapsulated, and referenced in a
high-level way

- to consider some kind of registration mechanism or capability
specification so that the browser will not throw low-level events to a
program that is not prepared to handle them

- to classify all call control tags, attributes, events, and fields as
mandatory (any compliant implementation must handle them), optional (not
required to be implemented, but if implemented must function as specified),
or implementation-dependent. 

[[[ end text ]]]

[[[ replace the last paragraph in Section 3.3 with the following text: ]]]

We want to expose the phone network in a provider-neutral way, while still
offering enough methods and information to allow sophisticated types of call
management.  Toward that end, we have defined typical call control actions
in a high-level, abstract way so that almost any underlying telephony API
should be able to implement them.  This is discussed in more detail in
Section 9.

[[[ end text ]]]

[[[ editor's note: there appears to be confusing text in the first few
paragraphs of Section 4 regarding which things have identifiers and which do
not.   For example, the text implies that audio connections have
identifiers, but they don't.   The text also imples that dialogs are not
identified.  And no mention is made of sessions.  I'm not sure what to do
about all this, so I am raising it to others' attention. ]]]

[[[ in the bullet list following the first paragraph of Section 4, add text
"(see note below)" to the third bullet on conference objects, and add the
following text after the bullet list: ]]]

Note: Some telephony APIs do not define a separate conference object,
instead defining a conference simply as a call with more than two parties.
In order to accommodate the widest range of underlying telephony APIs, CCXML
assumes a separate conference object.  When implemented above an API that
does not support this construct, it is suggested that the callid be returned
to the id attribute of the <createconference> tag, and that the
<destroyconference> tag be ignored.

[[[ end text ]]]

[[[ remove the text "(derived from the JTAPI/JCP/JCC event model. See JSR021
and JSR 034 from the sun web site)" from the second paragraph in Section 9.2
]]]

[[[ replace the third through sixth paragraphs of Section 9.4 with the
following text: ]]]

For now, we've focused on relatively simple types of call control, and we
have tried to make the call control model in CCXML sufficiently abstract so
that it can be implemented using all major telephony APIs such as JAIN Call
Control, ECMA CSTA, and S.100.  More complex forms of call control and media
control (e.g., conference floor control) appear to require a lower-level,
more granular, and more complex set of tags and events.  This is under
further study at this time.

The CCXML call model consists of Calls and Connections.  A Call represents
an association of zero or more Connections (one Connection for each party in
the call).
A Connection models the relationship between a Call and a network address.

[[[ end text ]]]

[[[ remove Section 9.4.3 ]]]

[[[ add the following text in Section 10.3: ]]]

Some telephony APIs do not define a separate conference object, instead
defining a conference simply as a call with more than two parties.  In order
to accommodate the widest range of underlying telephony APIs, CCXML requires
explicit use of a conference resource whenever two or more audio streams are
mixed.

[[[ end text ]]]

[[[ replace contents of Section 10.4 with the following text: ]]]

In many situations, the CCXML document may want to create a simple,
two-party bridge. In these cases, a separate conference is not needed.
Instead, the CCXML document can use the <join> CCXML tag to bridge the two
call legs (connections). The unjoin tag can be used to remove one or both
legs (connections) explicitly from a bridge.   If a <join> would result in a
leg (connection) being a listener to two audio sources, the leg is
automatically unjoined from its existing bridge or conference, and then
joined as specified in the <join>.  Asynchronous events will be sent to the
CCXML document upon completion of both the join and unjoin operations.

<join> cannot be used to add a connection to an existing two-party bridge in
order to create a 3-way conference.  Instead, this functionality can be
achieved by first using the <createconference> tag to create a conference
object and then joining all three connections to this conference. 

If leg A is joined full duplex to leg B, and then leg A is joined full
duplex to leg C, the result will be a single two-party bridge between A and
C.  Leg B will be unjoined.

A call leg (connection) can be joined to any number of bridges or
conferences simultaneously as long as it is only "listening" directly to one
source.

[[[ end text ]]]

[[[ replace contents of Section 10.5 with the following text: ]]]

Another common scenario in call center applications is the idea of a coach.
Here, the 'coach' is a supervisor whose purpose is to eavesdrop on a
conversation between the user and the support agent in order to allow the
coach to 'whisper' advice to the agent.  

This functionality can be achieved by creating two special three-party
conferences.  The conferences are "special" insofar as each contains two
parties that are only "talkers" (i.e., they do not hear the conference) and
one party that is only a "listener" (i.e., the conference does not hear
them).  

In conference #1, the user and agent are talkers and the coach is the
listener.  

In conference #2, the user and coach are talkers and the agent is the
listener.  

The connection between the agent and the user is a half-duplex bridge (i.e.,
the user hears only the agent).

Note that, in this arrangement, each call leg (connection) is listening
directly to only one audio source: the supervisor is listening to conference
#1, the agent is listening to conference #2, and the user is listening to
the agent.

[[[ end text ]]]

Received on Monday, 14 October 2002 16:32:05 UTC