W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2004

Re: Questions, comments on some CCXML operations

From: Werner Dittmann <Werner.Dittmann@t-online.de>
Date: Mon, 27 Sep 2004 20:25:32 +0200
Message-ID: <41585B1C.3000306@t-online.de>
To: Govardhan Srikant <gsrika@nortelnetworks.com>
CC: "'www-voice@w3c.org'" <www-voice@w3c.org>, "'rj@voxeo.com'" <rj@voxeo.com>, Scott Slote <scotts@nortelnetworks.com>


thanks for the information and I'll got the point. Well, it
makes the implementation of a CCXML interpreter a little more
complex.... :-).

As an idea I would propose to add you description as an informative
cahpter or appendix to the CCXML specifiation as this would highlight
the rationale behind the design.


Govardhan Srikant wrote:
> 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
>  >>
>  >>
>  >>
>  >   
> G Srikant
> Nortel Networks
> Call Center and Self Service Solutions
> email: gsrika@nortelnetworks.com <mailto:gsrika@nortelnetworks.com>
> tel:     (631) 285 3000
Received on Wednesday, 29 September 2004 13:42:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:37 UTC