CCXML: Message on Hold

[Petr Kuba]

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@...
    Tel: [phone]
    Fax: [phone]
    http://www.optimsys.cz

[RJ Auburn]

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:[phone]

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@...
>   Tel: [phone]
>   Fax: [phone]
>   http://www.optimsys.cz
>