RE: Questions, comments on some CCXML operations

The issue of defining an ECMA left hand-side expression that will receives
the respective id of the: <createcall>, <dialogstart>, <dialogprepare>,
<createccxml> and <createconference> was discussed at the Working Group's
F2F on Wednesday (9/22/04). 

The consensus was the IDs are required. 

The discussion focused several instances when/where the IDs would be
required. Several "use" cases drove the discussion. First is the fact that a
CCXML session can own or manage multiple event sources. The IDs allow an
application to call any of these tags sequentially within a single
transition. Through the ID's the application can associate the
completion/error event with the original request. 

Another instance where the ID's are required is when a connection
disconnects while an application is in a transition expecting a completion
event. The ID allows the application to terminate the operation.  

Though ID's may reference real resources, conferences and connections the
physical resource need not be exposed to the application. ID's simply
provide a method of associating a connection object within CCXML to a
resource on a platform.

The following scenarios should help illustrate the usefulness of the ID's.

1)      A connection disconnects immediately after the CCXML application
issues a <dialogstart>. The application would process the
connection.DISCONNECTED before receiving a dialog.started. The ID provides a
mechanism of sending a <dialogterminate> without the application waiting for
the acknowledgement. Without the dialog ID an application may <exit\>
prematurely, abandoning the dialog.

2)      A conference application managing multiple connection objects. Again
the ID returned in the <dialogstart> provides the freedom of starting a
dialog on each connection without requiring an intermediate state waiting on
a dialog.started or error.dialog.* event to progress to another "State".

3)      A calling card type application that bridges two calls. If  the
original caller, A-Leg, disconnects as the application issues a <createcall>
to acquire a B-Leg. With the ID returned in the <createcall> the application
can terminate the B-Leg call before the caller is connected.

4)      The application should have the freedom of issuing any tag multiple
times within the same transition. For instance a call routing application
could create a new CCXML session for each connection.ALERTING event.
Certainly this type of application could not provide a transition for each
new session and would need to associate an error.createccxml with the
inbound call.

Note issue is not limited to the above tags, <send> <fetch> both return an
ID for similar purposes.


> On 09/17/2004 11:56, "Werner Dittmann" <Werner.Dittmann@t-online.de> 
> wrote: 
> 
>> 
>> All, 
>> 
>> the asynchronous operations <createccxml>, <createcall>, 
>> <dialogprepare>, <dialogstart>, and <createconference> define an ECMA 
>> lefthand-side expression that will receive the respective id of the 
>> newly created object. The same id is returned in the associacted 
>> event, e.g. ccxml.created. What is the rational behind this? 
>> 
>> Because all actions are asynchronous it is not guaranteed that they 
>> will succeed and having an id before the operation was finished 
>> successfully, i.e. the opject really created, does not make sense. 
>> 
>> Providing the id only with an event that indicates a success makes it 
>> easier to implementent a CCXML interpeter because no "look-ahead" 
>> generation of ids is necessary. 
>> 
>> In addition, it is sometimes appropriate to defer the generation of 
>> an id until the object is really created and activated by the 
>> platform. This is the case at least for some call control protocols, 
>> e.g. SIP, ISUP, etc. where the connectionid identifies the created 
>> conection. 
>> 
>> Any thoughts? 
>> 
>> Regards, 
>> Werner 
>> 
>> 
>> 
>  
Ggsr Srikant
Nortel Networks
Call Center and Self Service Solutions
email:  <mailto:gsrika@nortelnetworks.com> gsrika@nortelnetworks.com
tel:     (631) 285 3000

Received on Monday, 27 September 2004 13:02:32 UTC