|
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
>>
>>
>>
>
Ggsr
Srikant
Nortel
Networks
Call Center and
Self Service Solutions
tel: (631) 285
3000
| 