- From: Jayalakshmi Swaminathan <jayalakshmi@huawei.com>
- Date: Wed, 25 Oct 2006 10:03:43 +0530
- To: 'Petr Kuba' <kuba@optimsys.cz>, www-voice@w3.org
- Message-id: <004c01c6f7ee$c1550710$6704120a@china.huawei.com>
Petr, Thanks for your response.
The specification is not very clear with respect to the connection state
transitions. Currently, it looks as if <accept> directly leads to a state
change to CONNECTED state. It would be good if more detail is added to the
section describing the state table.
Thanks,
Jaya
****************************************************************************
***********
This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose address
is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-----Original Message-----
From: Petr Kuba [mailto:kuba@optimsys.cz]
Sent: Friday, October 20, 2006 6:31 PM
To: www-voice@w3.org
Cc: jayalakshmi@huawei.com
Subject: Re: State transition from ALERTNG to CONNECTED in CCXML
Hi Jayalakshmi,
Jayalakshmi Swaminathan wrote:
>
> Hi,
>
> Consider the following <transition> in a CCXML document. While
> entering the transition for "connection.alerting" event, the
> Connection State = ALERTING. As soon as the <accept> tag is
> encountered, lets say a command is sent to the underlying Telephony
> component to accept the incoming call. Should the Connection state be
> changed to CONNECTED, regardless of the success or failure of accept
> command?
>
No. The state is not changed until the Telephony component finishes the
operation, sends e.g. connection.connected event and the EHIA starts to
process the event. See CCXML specification, section 9.1:
"For instance, if a 'connection.alerting' event is being processed
against a connection with ID 1234, then
session.connections['1234'].state would have a value of 'ALERTING'. This
is true even if the actual connection has already been terminated, with
a 'connection.disconnected' event queued (but not yet processed) against
the session. It is required that the ECMAScript state for the session is
updated prior to the selection of a matching <transition>, since the
<transition> might contain an ECMAScript conditional expression the
value of which depends on the state changes caused by the event."
> Subsequently, if accepting the incoming call fails, which event should
> be thrown - "error.connection" OR "connection.failed"?
>
It depends on the reason why accepting fails. For instance, if the
calling party hangs up while the call is being accepted then the result
should be probably connection.failed. If it fails because of some error
then it should be error.connection.
>
> <transition event="connection.alerting"> <!--For connectionid = 1234 -->
>
> <accept/>
>
> <if cond ="session.connections['1234'].state == 'CONNECTED' ">
>
> <log expr=" 'State changed' "/>
>
> <else/>
>
> <log expr=" 'State not changed' "/>
>
> </if>
>
> </transition>
>
> For the above transition, is the "State changed" log sent out?
>
No. As explained above.
Regards,
Petr
--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@optimsys.cz
Tel: +420 541 143 065
Fax: +420 585 750 429
http://www.optimsys.cz
> Thanks,
>
> Jaya
>
>
****************************************************************************
***********
>
> This e-mail and attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address
> is listed above. Any use of the information contained herein in any
> way (including, but not limited to, total or partial disclosure,
> reproduction, or dissemination) by persons other than the intended
> recipient's) is prohibited. If you receive this e-mail in error,
> please notify the sender by phone or email immediately and delete it!
>
Received on Wednesday, 25 October 2006 04:34:24 UTC