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

Peter,

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

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

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