W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2006

RE: State transition from ALERTNG to CONNECTED in CCXML

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:04 GMT