Re: Questions, comments on some CCXML operations

Govardhan,

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.

Regards,
Werner

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@xxxxxxxxxxx>
>  > 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@xxxxxxxxxxxxxxxxxx <mailto:gsrika@xxxxxxxxxxxxxxxxxx>
> tel:     (631) 285 3000