- From: Govardhan Srikant <gsrika@nortelnetworks.com>
- Date: Mon, 27 Sep 2004 09:01:03 -0400
- To: "'www-voice@w3.org'" <www-voice@w3.org>
- Message-ID: <F82F85D5C30F374DA85CE463919D029260BD44@zrtphxm1.corp.nortel.com>
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