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

Re: CCXML: Message on Hold - ISSUE-634 [cc]

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 22 Oct 2009 11:26:03 +0200
Cc: www-voice@w3.org, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Message-Id: <09FB4E68-F93D-4475-ABA4-A3A328D863F0@voxeo.com>
To: Petr Kuba <kuba@optimsys.cz>

Thanks for this comment. We will consider this feature request in the  
context of a CCXML 1.1 spec update. This is tracked as ISSUE-634.

Best regards.


RJ Auburn
CTO, Voxeo Corporation

On Sep 18, 2009, at 2:40 PM, Petr Kuba wrote:

> Hello,
> We need to implement Message on Hold service in CCXML which will use  
> SIP PBX instead of VXML dialog for playing music.
> Scenario for this service in SIP is described for instance here:
> http://www.tech-invite.com/Ti-sip-service-3.html
> The problem is that CCXML specification does not provide support for  
> this operation. I've noticed that early version of the specification  
> contained tag <hold> but later it was removed.
> Therefore it will be necessary to use some platform-specific (and  
> thus non-standard) extensions. Since we are trying to follow the  
> specification as much as possible we are looking for a solution that
> breaks the specification as little as possible.
> To the best of our knowledge, the only part of the CCXML  
> specification that could be related to this problem is at the end of  
> Section 10.2.1:
> "The PROGRESSING and ALERTING states have reflexive transitions.  
> This is intended to model protocols which have additional states at  
> these points, and which MAY exchange messages such as PROCEEDING,  
> ALERTING, FACILITY, or NOTIFY. Platforms MAY choose to implement  
> additional states which MAY be reflected in the substate property of  
> the Connection object. Additional messages can be implemented with  
> <send>."
> Our idea is to use the substate property of the Connection object to  
> identify that a connection is on hold.
> To place a connection on hold and take it off hold we can probably  
> use the <send> tag and send events (commands) to and from a  
> connection. This would give us also flexibility for similar tasks in  
> future.
> Unfortunately, sending events to and from a connection is mentioned  
> only in the quotation above. We would appreciate more detailed  
> description of this issue.
> We would also appreciate any comments on the suggested solution.  
> Does this solution make sense? Do we miss something? Does anybody  
> have better idea how to implement this? Has anybody implemented  
> something like this?
> Thanks for responses,
> Petr Kuba
> -- 
>   Petr Kuba, Project Manager
>   OptimSys, s.r.o
>   kuba@optimsys.cz
>   Tel: +420 541 143 065
>   Fax: +420 541 143 066
>   http://www.optimsys.cz
Received on Thursday, 22 October 2009 09:26:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:41 UTC