From 623fc6d4a7da45fb1e7051fee5816cfc9c2b4629 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 14 Dec 2011 11:51:09 +0000 Subject: [PATCH 001/178] Initial rayo spec import --- extensions/inbox/rayo.xml | 499 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 499 insertions(+) create mode 100644 extensions/inbox/rayo.xml diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml new file mode 100644 index 00000000..ce982d73 --- /dev/null +++ b/extensions/inbox/rayo.xml @@ -0,0 +1,499 @@ + + +%ents; +]> + + +
+ Rayo + This specification describes the Rayo third-party call control protocol. + + This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. + ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## + In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. + This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). + + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Jose + de Castro + jdecastro@voxeo.com + jdecastro@voxeo.com + + + 0.0.1 + 2011-12-05 + jdc +

First draft.

 + +
+ +

Rayo is an extension for controlling phone calls, audio mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle...

+ + +
    +
  1. A call arrives to the Rayo Server
    2. +
  2. The Rayo Server uses the incoming call's matadata (e.g. SIP headers) to determine the JID of the controlling party
    3. +
  3. An is sent to the controlling party
    4. +
  4. +
  5. +
  6. +
+ + +

The protocol defined herein is designed to meet the following requirements:

+
    +
  1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Evey attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
    2. +
  2. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
    3. +
  3. Speech Synthesis / TTS: In cases where dynamic data must be spoken, a Speech Synthesis engine many be used to play computer generated speech to the caller.
    4. +
  4. Touch-tone Events / DTMF: Rayo surfaces real-time event when the caller presses keys on their touch-tone keypad.
    5. +
  5. Speech Recognition: Enables the phone application to take spoken queues allowing for sophisticated voice-driven menus and directory services.
    6. +
  6. Call Recording: Can be used to capture the caller's voice (e.g. Voicemail) or both sides of the call for auditing and compliance purposes.
    7. +
  7. Mixing: Typically referred to as an audio "conference" calls can be joined together so that the participants can hear each other in real-time.
    8. +
+ + + + + + + + + + + + + + + +
TermDefinition
CommandsCommands may be executed against a given call, component or mixer and can be considered completed as soon as they get a response.
ComponentComponents extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/&get; event
+ + +

+ + + + + + + +

The offer element MAY be empty or contain one or more header elements (for which see Header Element).

+

The attributes of the offer element are as follows.

+ + + + + + + + + + + + + + + + +
AttributeDefinitionInclusion
toA valid Rayo URI indicating the target of the call as described under Call target/source URI.REQUIRED
fromA valid Rayo URI indicating the source of the call as described under Call target/source URI.REQUIRED
+ + +

The header element MUST be empty.

+

The attributes of the header element are as follows.

+ + + + + + + + + + + + + + + + +
AttributeDefinitionInclusion
nameA string representing the name by which the header may be known.REQUIRED
valueA string value for the named header.REQUIRED
+ + +

The accept element MAY be empty or contain one or more header elements (for which see Header Element).

+

The accept element has no attributes.

+ + +

The answer element MAY be empty or contain one or more header elements (for which see Header Element).

+

The answer element has no attributes.

+ + +

The redirect element MAY be empty or contain one or more header elements (for which see Header Element).

+

The attributes of the redirect element are as follows.

+ + + + + + + + + + + +
AttributeDefinitionInclusion
toA valid Rayo URI indicating the new target for the call as described under Call target/source URI.REQUIRED
+ + +

The reject element MUST contain a single reject reason element (for which see Reject Reason Element). It MAY also contain one or more header elements (for which see Header Element).

+

The reject element has no attributes.

+ + +

The dial element MAY be empty or contain one or more header elements (for which see Header Element).

+

The attributes of the dial element are as follows.

+ + + + + + + + + + + + + + + + +
AttributeDefinitionInclusion
toA valid Rayo URI indicating the target of the call as described under Call target/source URI.REQUIRED
fromA valid Rayo URI indicating the source of the call as described under Call target/source URI.REQUIRED
+ + +

The ringing element MAY be empty or contain one or more header elements (for which see Header Element).

+

The ringing element has no attributes.

+ + +

The answered element MAY be empty or contain one or more header elements (for which see Header Element).

+

The answered element has no attributes.

+ + +

The end element MUST contain a single end reason element (for which see End Reason Element). It MAY also contain one or more header elements (for which see Header Element).

+

The end element has no attributes.

+ + +

The hangup element MAY contain one or more header elements (for which see Header Element).

+

The hangup element has no attributes.

+ + + +

STRONGLY RECOMMENDED.

+ + +

OPTIONAL.

+ + +

If an entity supports Rayo, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo:0" &VNOTE; in response to a &xep0030; information request. The response MUST also include features for the application formats and transport methods supported by the responding entity, as described in the relevant specifications.

+ + + + ]]> + + + + + + ]]> + + + + ]]> + + + + + + ]]> +

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

+ + +

OPTIONAL.

+ + + +

Rayo sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Rayo sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

+ + +

Rayo communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. For example, on some SIP networks authentication is optional and "from" addresses can be easily forged. Care must be taken in communicating through such gateways.

+ + +

Mere negotiation of a Rayo session can expose sensitive information about the parties (e.g. IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

+ + + +

This document requires no interaction with &IANA;.

+ + + +

This specification defines the following XML namespaces:

+
    +
  • urn:xmpp:rayo:1
    • +
  • urn:xmpp:rayo:client:1
    • +
  • urn:xmpp:rayo:ext:1
    • +
  • urn:xmpp:rayo:ext:complete:1
    • +
  • urn:xmpp:rayo:output:1
    • +
  • urn:xmpp:rayo:input:1
    • +
  • urn:xmpp:rayo:record:1
    • +
+

The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

+ + +

If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

+ + +

The XMPP Registrar maintains a registry of Rayo components. All component registrations with the exception of those defined above shall be defined in separate specifications (not in this document). Components defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URNs of the form "urn:xmpp:rayo:component_name:X" (where "component_name" is the registered name of the component and "X" is a non-negative integer).

+ ®PROCESS; + + The name of the component. + A natural-language summary of the component. + The document in which the component is specified. + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Duration is a in milleseconds + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + From 898a5003ca36350a9aa48a089de933c83b404199 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 14 Dec 2011 13:26:16 +0000 Subject: [PATCH 002/178] Formal definition for the Rayo component element --- extensions/inbox/rayo.xml | 106 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ce982d73..fac9503b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -195,6 +195,112 @@

The hangup element MAY contain one or more header elements (for which see Header Element).

The hangup element has no attributes.

+ + +

An input component is used to instruct the server to gather media input from the call, using either DTMF or ASR.

+

The input element MUST contain one or more grammar elements (for which see Grammar Element).

+

The attributes of the input element are as follows.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeDefinitionPossible ValuesDefaultInclusion
modeThe method by which to collect input.any|dtmf|speechanyOPTIONAL
terminatorThe terminator digit by which to force completion of the grammar.0-9,#,*noneOPTIONAL
recognizerAny valid ISO 639‑3 language codeen-USOPTIONAL
initial-timeoutThe timeout to be applied before the first digit is captured in the case of DTMF input, or before the beginning of an utterance is detected.Any positive integer in miliseconds, or -1 for no timeout.-1OPTIONAL
inter-digit-timeoutThe timeout to be applied between the first and subsequent captured digits.Any positive integer in miliseconds, or -1 for no timeout.-1OPTIONAL
sensitivityA decimal value between 0 and 1.OPTIONAL
min-confidenceA decimal value between 0 and 1.OPTIONAL
max-silenceThe maximum period of silence permitted before a timeout is triggered.Any positive integer in miliseconds, or -1 for no timeout.-1OPTIONAL
+ +

The grammar element defines the grammar by which input should be matched.

+

The grammar element MUST have either a url attribute set OR a content type and a body.

+

The attributes of the input element are as follows.

+ + + + + + + + + + + + + + + + + + + + + + +
AttributeDefinitionPossible ValuesDefaultInclusion
urlA URL to a grammar definition.Any valid URI scheme supported by the server (eg HTTP).noneREQUIRED unless content-type and content are set
content-typeThe content type of the grammar contained within the grammar element.application/grammar+voxeo|application/grammar+grxmlnoneREQUIRED unless url is set
+ + + + + + + + +

STRONGLY RECOMMENDED.

From 87c3058f2ae997e3d81edaf8e7cd8270b3156899 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 14 Dec 2011 13:27:29 +0000 Subject: [PATCH 003/178] Elements to be printed literally must be encoded --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index fac9503b..f1419add 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -46,7 +46,7 @@
  1. A call arrives to the Rayo Server
  2. The Rayo Server uses the incoming call's matadata (e.g. SIP headers) to determine the JID of the controlling party
    3. -
  3. An is sent to the controlling party
    4. +
  4. An <offer/> is sent to the controlling party
  7. From 228dbb9704bf87bde2ecc8186c61aee4da7c5e0f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 14 Dec 2011 13:55:43 +0000 Subject: [PATCH 004/178] Add media input commands and events formal definition --- extensions/inbox/rayo.xml | 42 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 40 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f1419add..9e483fc7 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -294,10 +294,48 @@ - +

    The input component supports only the component Stop command.

     - + +

    The complete element MUST contain a valid completion reason element. Possible completion reasons are as follows, in addition to the standard component completion reasons.

    + +

    Indicates that the input received matches the specified grammar, and provides results.

    +

    The success element MUST contain valid interpretation and utterance elements.

    +

    The attributes of the success element are as follows.

    + + + + + + + + + + + + + + + + + + + +
    AttributeDefinitionPossible ValuesInclusion
    modeThe method by which detection occurred.speech|dtmfREQUIRED
    confidenceThe confidence with which the interpretation matches the utteranceA decimal value between 0 and 1.REQUIRED
    +     + +

    Indicates that the input received did not match the specified grammar.

    +

    The nomatch element MUST be empty.

    +

    The nomatch element has no attributes.

    +     + +

    Indicates that the component did not receive any input.

    +

    The noinput element MUST be empty.

    +

    The noinput element has no attributes.

    +     + +     From cb1c24c4e5ea4da8e855b971f37f176d1ce8a6c7 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 15 Dec 2011 12:14:03 +0000 Subject: [PATCH 005/178] Add formal definition for media output --- extensions/inbox/rayo.xml | 133 +++++++++++++++++++++++++++++++++++++- 1 file changed, 132 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 9e483fc7..e600a327 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -196,8 +196,139 @@

    The hangup element has no attributes.

    + +

    An output component is used to instruct the server to generate audible output to a call or mixer.

    +

    The output element MUST contain a single CDATA entitiy containing the SSML document to render.

    +

    The attributes of the output element are as follows.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDefinitionPossible ValuesDefaultInclusion
    interrupt-onThe type of media input to allow interrupting the output.any|dtmf|speech|nonenoneOPTIONAL
    start-offsetA positive integer in ms.0OPTIONAL
    start-pausedWether or not to start the output in the paused state, ready to be resumed.true|falsefalseOPTIONAL
    repeat-intervalThe amount of time to wait between successive repetitions of the document.A positive integer in ms.0OPTIONAL
    repeat-timesThe number of times to produce the requested output before considering it to be complete.A positive integer.1OPTIONAL
    max-timeThe maximum time the output should be allowed to run for before being force-terminated.A positive integer in ms.-1OPTIONAL
    voiceThe voice with which to speak the requested document.Any voice supported by the TTS engine.allisonOPTIONAL
    + +

    The input component supports the component Stop command, along with the following.

    + +

    Instructs the server to pause the media output, but not terminate the component.

    +

    The pause element MUST be empty.

    +

    The pause element has no attributes.

    +     + +

    Instructs the server to resume a paused output.

    +

    The resume element MUST be empty.

    +

    The resume element has no attributes.

    +     + +

    Instructs the server to increase the speed by a unit amount.

    +

    The speed-up element MUST be empty.

    +

    The speed-up element has no attributes.

    +     + +

    Instructs the server to reduce the speed by a unit amount.

    +

    The speed-down element MUST be empty.

    +

    The speed-down element has no attributes.

    +     + +

    Instructs the server to increase the volume by a unit amount.

    +

    The volume-up element MUST be empty.

    +

    The volume-up element has no attributes.

    +     + +

    Instructs the server to reduce the volume by a unit amount.

    +

    The volume-down element MUST be empty.

    +

    The volume-down element has no attributes.

    +     + +

    Instructs the server to move the play marker of the output forward or back in time before resuming output.

    +

    The seek element MUST be empty.

    +

    The attributes of the seek element are as follows.

    + + + + + + + + + + + + + + + + + + + +
    AttributeDefinitionPossible ValuesInclusion
    directionThe direction in time in which to move the current play marker.forward|backREQUIRED
    amountA time value by which to move the play marker, in millisecondsA positive integer, in ms.REQUIRED
    +     +     + + +

    The complete element MUST contain a valid completion reason element. Possible completion reasons are as follows, in addition to the standard component completion reasons.

    + +

    Indicates that the output was completed successfully.

    +

    The nomatch element MUST be empty.

    +

    The nomatch element has no attributes.

    +     +     +     +     -

    An input component is used to instruct the server to gather media input from the call, using either DTMF or ASR.

    +

    An input component is used to instruct the server to gather media input from a call or mixer, using either DTMF or ASR.

    The input element MUST contain one or more grammar elements (for which see Grammar Element).

    The attributes of the input element are as follows.

    From d55548ff8b2d79f75be340403ae516526bd4bc9c Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 15 Dec 2011 15:00:53 +0000 Subject: [PATCH 006/178] Add hotword detection to Input --- extensions/inbox/rayo.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index e600a327..40bbc257 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -346,6 +346,13 @@ + + + + + + + From dbc4b3f0d0a0a04e4c3406ff46a5939b69567216 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 15 Dec 2011 15:48:45 +0000 Subject: [PATCH 007/178] Fix up some formatting, and add section5 and section6 tags --- extensions/inbox/rayo.xml | 10 ++-- extensions/xep.xsl | 116 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 122 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 40bbc257..883df133 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -76,7 +76,7 @@ - +
    any OPTIONAL
    hotword-timeoutThe amount of time for which to discard invalid input, awaiting a match.A positive integer in ms, or -1 to disable.-1OPTIONAL
    terminator The terminator digit by which to force completion of the grammar.
    ComponentComponents extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/&get; eventComponents extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/> event
    @@ -441,7 +441,7 @@

    Indicates that the input received matches the specified grammar, and provides results.

    The success element MUST contain valid interpretation and utterance elements.

    The attributes of the success element are as follows.

    - +
    @@ -472,7 +472,6 @@

    The noinput element MUST be empty.

    The noinput element has no attributes.

    - @@ -726,7 +725,10 @@ - + diff --git a/extensions/xep.xsl b/extensions/xep.xsl index b9d114fd..1f1e6c37 100644 --- a/extensions/xep.xsl +++ b/extensions/xep.xsl @@ -786,6 +786,122 @@ OR OTHER DEALINGS IN THE SOFTWARE. + + + + + + + + + + . + +
             + + + + # + + + + + + sect- + + + + + +     + + + + + + + + +
    +

    + .... + + + + + + + + + sect- + + + + + +

    + +
    +     + + + + + + + + + + + . + +
             + + + + # + + + + + + sect- + + + + + +     + + + + + + + + +
    +

    + ..... + + + + + + + + + sect- + + + + + +

    + +
    +     + From 23dc0e763b3fcac13c1483a0ea5524474dc62229 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 15 Dec 2011 16:39:58 +0000 Subject: [PATCH 008/178] Add partial matches to Input --- extensions/inbox/rayo.xml | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 883df133..b8d771fb 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -353,6 +353,13 @@     + + + + + + + @@ -435,6 +442,31 @@

    The input component supports only the component Stop command.

    + +

    Indicates that the input received triggered a match with the specified grammar, and provides results. This constitutes a partial match, and does not signal the end of the grammar.

    +

    The match element MUST contain valid interpretation and utterance elements.

    +

    The attributes of the match element are as follows.

    +
    Attribute Definition -1 OPTIONAL
    partial-matchWether or not the component should trigger match events whenever a partial match is detected.true|falsefalseOPTIONAL
    terminator The terminator digit by which to force completion of the grammar.
    + + + + + + + + + + + + + + + + + + +
    AttributeDefinitionPossible ValuesInclusion
    modeThe method by which detection occurred.speech|dtmfREQUIRED
    confidenceThe confidence with which the interpretation matches the utteranceA decimal value between 0 and 1.REQUIRED
    +

    The complete element MUST contain a valid completion reason element. Possible completion reasons are as follows, in addition to the standard component completion reasons.

    From 12ea4fefd1bef79800b78a9a2fd8ff517c8bc270 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Jan 2012 16:11:07 +0000 Subject: [PATCH 009/178] [BUGFIX] Answered/Ringing events are allowed headers --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b8d771fb..5b23052e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -626,10 +626,10 @@ - + - + From d51e506c10371297df9461341910f2d720d0f2a7 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Jan 2012 16:21:04 +0000 Subject: [PATCH 010/178] [FEATURE] Dial commands should have an optional timeout --- extensions/inbox/rayo.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 5b23052e..86daa3e8 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -705,6 +705,13 @@ + + + + Timeout is in milleseconds + + + From b4392cedad29cc64ba7a79697d6ba36a568abbf1 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Jan 2012 16:33:11 +0000 Subject: [PATCH 011/178] [BUGFIX] A timeout on an offer is not valid --- extensions/inbox/rayo.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 86daa3e8..5b03bdc2 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -616,7 +616,6 @@ - From c2d5415eba7f82bcd6bd1ad2c1e422f7c89a273a Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:40:35 +0000 Subject: [PATCH 012/178] [UPDATE] Add further author details --- extensions/inbox/rayo.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 5b03bdc2..a2b2f36c 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -31,6 +31,14 @@ de Castro jdecastro@voxeo.com jdecastro@voxeo.com + http://voxeolabs.com + + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me 0.0.1 From bb75207b4e32d4e20758e891ebac6fd4159540aa Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:42:41 +0000 Subject: [PATCH 013/178] [BUGFIX] Fix the type of ringing/answered elements to be callProgressType, which may contain headers --- extensions/inbox/rayo.xml | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a2b2f36c..3a28c0db 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -618,6 +618,12 @@ xmlns:tns="urn:xmpp:rayo:1" elementFormDefault="qualified"> + + + + + + @@ -627,16 +633,17 @@ - - - + + + + + - + - @@ -650,6 +657,7 @@ + From a4c3380e862c5a847d1a642a563a829ab5a75d9a Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:43:15 +0000 Subject: [PATCH 014/178] [BUGFIX] DTMF events are not valid, more generic signal detection spec on the way --- extensions/inbox/rayo.xml | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 3a28c0db..7a7585d4 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -644,19 +644,6 @@ - - - - - - - - - Duration is a in milleseconds - - - - From e0add288773b5549e4134471a4979cc358d306a9 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:43:48 +0000 Subject: [PATCH 015/178] [BUGFIX] Fix the name of the reject end reason --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 7a7585d4..0a362dc4 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -654,7 +654,7 @@ - + From 94ad97399bfad7b8bff93d05734ca0d976525683 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:44:22 +0000 Subject: [PATCH 016/178] [CS] Minor schema formatting fix --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0a362dc4..1dc43e44 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -678,7 +678,7 @@ - + From 47cd9fddf179e1bc32283ca5638b8284e32adf02 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:46:48 +0000 Subject: [PATCH 017/178] [FEATURE] Annotate the schema with a link to the xep --- extensions/inbox/rayo.xml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1dc43e44..759c361c 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -618,6 +618,12 @@ xmlns:tns="urn:xmpp:rayo:1" elementFormDefault="qualified"> + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + @@ -740,6 +746,12 @@ xmlns:tns="urn:xmpp:rayo:ext:1" elementFormDefault="qualified"> + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + @@ -771,6 +783,12 @@ xmlns:tns="urn:xmpp:rayo:ext:complete:1" elementFormDefault="qualified"> + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + From b5161fff7c2fc68117e9787d35d4860d1b379ad8 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:47:55 +0000 Subject: [PATCH 018/178] [BUGFIX] Complete reasons should have their own type and should allow any children --- extensions/inbox/rayo.xml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 759c361c..34a2a906 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -790,14 +790,18 @@ - + - + + + + + From 4f29505b8fd03b8015158e6de38935aee50bca56 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 00:51:53 +0000 Subject: [PATCH 019/178] [BUGFIX] A complete event should only have one child, being the reason --- extensions/inbox/rayo.xml | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 34a2a906..3090a2e6 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -758,11 +758,9 @@ - - - - - + + + From afaa4836b64cb73090bde072db609f1cf23c7b2f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 12:11:34 +0000 Subject: [PATCH 020/178] [FEATURE] Add basic schema for media components --- extensions/inbox/rayo.xml | 549 +++++++++++++++++++++++++++++++++----- 1 file changed, 477 insertions(+), 72 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 3090a2e6..ba93e089 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -631,14 +631,15 @@ - - - - - - - - + + + + + + + + + @@ -653,74 +654,74 @@ - - - - - - - - - - - - - + + + + + + + + + + + + + + - - - - - - + + + + + + + - - - - - - - + + + + + + + + - - - - - - - - - - - + + + + + + + + + + + + - - - - - - + + + + + + + - - - - - - - - - - - Timeout is in milleseconds - - - - + + + + + + + + + + @@ -735,6 +736,17 @@ + + + + + + Value is a duration in milleseconds + + + + + ]]>         @@ -756,12 +768,13 @@ - - - - - - + + + + + + + @@ -770,6 +783,17 @@ + + + + + + Value is a duration in milleseconds + + + + + ]]> @@ -807,37 +831,418 @@ + + + + + + Value is a duration in milleseconds + + + + + ]]> + + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Value is a duration in milleseconds + + + + + ]]> + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + + + + + + + + + + + + + + + + + + Value is a duration in milleseconds + + + + + + ]]> + + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Value is a duration in milleseconds + + + + + + ]]> + + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Value is a duration in milleseconds + + + + + ]]> + + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Value is a duration in milleseconds + + + + + + ]]> + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Value is a duration in milleseconds + + + + + + ]]> From be76ba475b433a230ff8f87e78af68f193b576db Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 13:06:24 +0000 Subject: [PATCH 021/178] [CS] Sequences of headers should come after attributes in the schema --- extensions/inbox/rayo.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ba93e089..f14f745f 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -681,10 +681,10 @@ + - @@ -714,12 +714,12 @@ - - - + + + From 3eb6bad2c0938e35dc7128eddd8356b24945527c Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 13:56:42 +0000 Subject: [PATCH 022/178] [FEATURE] Add join schema Fixes #8 --- extensions/inbox/rayo.xml | 52 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f14f745f..19b9a9bd 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -719,10 +719,62 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 6e258045962b2721757aeff1a79bc0452e0571f2 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 17:06:04 +0000 Subject: [PATCH 023/178] [DOC] Comprehensive schema documentation of core, non-component elements * Add accept command * #4 --- extensions/inbox/rayo.xml | 427 ++++++++++++++++++++++++++++++++------ 1 file changed, 365 insertions(+), 62 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 19b9a9bd..f6656f12 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -632,12 +632,35 @@ + + + Informs the recipient that a new call is available for control and invites it to take control using progress commands below. + + + + + + The target URI for the call. May me a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. + + + + + + + The caller ID URI for the call. May me a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. + + + - + + + + Set of header variables sent by the originating party (eg SIP INVITE headers). + + + - - @@ -647,23 +670,90 @@ - - - - + + + + Indication that an outbound call has begun ringing, or accepted by the remote party. + + + + + + + + + Indication that an outbound call has been answered and that the 3rd party negotiation has completed. At this point, the media stream should be open. + + + + + + Indicated to a call's controlling party that the call has come to an end, giving the reason. + + - - - - - + + + + Indication that the call ended due to a normal hangup by either party. + + + + + + + Indication that the call ended due to a timeout in contacting the remote party. + + + + + + + Indication that the call ended due to being rejected by the remote party subsequent to being accepted. + + + + + + + Indication that the call ended due to being rejected by the remote party before being accepted. + + + + + + + Indication that the call ended due to a system error. + + + + + + + Set of header variables sent by the remote party along with the indication of the call ending. + + + + + + + + + + + + Instructs the server to send notification to the calling party that the call will be dealt with and that ringing may begin. + + + + @@ -671,6 +761,11 @@ + + + Instructs the server to pick up an incoming call and connect the media stream. + + @@ -680,6 +775,11 @@ + + + Instructs the calling party that the call will not be accepted and that instead it should try to call the URI indicated in the command. + + @@ -690,12 +790,35 @@ + + + Instructs the server to reject the call with a given reason. + + - - - + + + + Indicates that the controlling party refused the call for an unspecified reason, such as access control. + + + + + + + Indicates that the controlling party refused the call due to excess load. + + + + + + + Indicates that the controlling party refused the call because some error occurred. + + + @@ -704,6 +827,11 @@ + + + Instructs the server to bring the call to an end naturally. + + @@ -713,73 +841,207 @@ + + + Instructs the server to create a new call and surrender control of it to the requesting party. + + - - - + + + + Indicates the party to whom the call should be directed. + + + + + + + Indicates the caller ID with which the call should appear to originate. + + + + + + + Indicates the maximum time allowed for a response to be provided by the third party before the call should be considered to have come to an end. + + + - + + + + Instructs the server to join the new call in the indicated mannor rather than the default (join to the local media server). + + + - + + + + Instructs the server to join the media streams of the call and the specified party, given direction and media negotiation parameters. + + + + + + + + + Indicates the direction in which the media should flow between the call and the 3rd party. + + + + + + + + Indicates that media should flow in both directions between the parties. + + + + + + + Indicates that media should only flow from the target call to the third party. + + + + + + + Indicates that media should only flow from the third party to the target call. + + + + + + + + + + Indicates the manner in which the server should negotiate media between the two parties. + + + + + + + + Instructs the server to bridge the parties media streams via its local media server. + + + + + + + Instructs the server to have the parties negotiate media directly with one another. + + + + + + + + + + - + + + + Instructs the server to unjoin the media streams of the call and the specified party. + + + - + + + + Indicates that the call was successfully joined to the specified party. + + + - + + + + Indicates that the call ceased to be joined to the specified party. + + + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + Indicates the 3rd party call ID to which the target call should be joined. May not be set if the mixer-name attribute is set. + + + + + + + Indicates the mixer name to which the target call should be joined. May not be set if the call-id attribute is set. + + + - + + + + Indicates that a call joined to a mixer with which the controlling party has an events subscription has activated a speech detector, providing its ID. + + + - + + + + Indicates that a call joined to a mixer with which the controlling party has an events subscription has ceased activation of a speech detector, providing its ID. + + + - + + + + Indicates the ID of the call which has triggered the speech detector. + + + - - - - + + + + Used to give an indication of the identity of a newly created resource, either a call or a component. + + + + + + + Gives the ID of the new resource. + + + + + @@ -817,13 +1079,30 @@ - + + + + Instructs a component to come to an end before it completes naturally. + + + + + + Indicates that the component has come to an end and no further processing will occurr. Gives the reason for the termination. + + - + + + + The reason for component termination. May be either one of the core termination reasons (stop, hangup, error) or a component specific reason. + + + @@ -864,16 +1143,40 @@ - + + + + Indicates that the component came to an end because it was issued a stop command by the controlling party. + + + - + + + + Indicates that the component came to an end because the call ended. + + + - + + + + Indicates that the component came to an end because it encountered an error. + + + - + + + + May be any component specific meta-data elements. + + + From 1c4789ce45664ab67fb3fa6436fcacee22ccf111 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 22:47:09 +0000 Subject: [PATCH 024/178] [DOC] Comprehensive schema documentation of Output component elements * Remove interrupt facility from Output * #4 --- extensions/inbox/rayo.xml | 142 ++++++++++++++++++++++++++++++-------- 1 file changed, 114 insertions(+), 28 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f6656f12..40cf3173 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1216,24 +1216,48 @@ + + + Instructs the server to begin an output component executing on the target call or mixer with the specified document and parameters. + + - - - - - - - - - + + + + Indicates some offset through which the output should be skipped before rendering begins. + + + + + + + Indicates wether or not the component should be started in a paused state to be resumed at a later point. + + + + + + + Indicates the duration of silence that should space repeats of the rendered document. + + + + + + + Indicates the number of times the output should be played. + + + + + + + Indicates the maximum amount of time for which the output should be allowed to run before being terminated. Includes repeats. + + - - - - - - @@ -1241,30 +1265,83 @@ - + + + + Instructs the server to cease rendering output at the current marker and permit resumption from the same point. + + + - + + + + Instructs the server to continue rendering the output from the last pause marker. + + + + + + Instructs the server to instantly proceed by a specified amount through the rendered document without producing output. + + - - + + + + Indicates the direction in which the play marker should be moved through the rendered audio. + + + + + + + Indicates the duration of audio to skip through. + + + - + + + + Instructs the server to increase the rate of output by a unit amount. + + + - + + + + Instructs the server to decrease the rate of output by a unit amount. + + + - + + + + Instructs the server to increase the volume of output by a unit amount. + + + - + + + + Instructs the server to decrease the volume of output by a unit amount. + + + @@ -1302,13 +1379,22 @@ - + + + + Indicates that the output component came to an end as a result of reaching the end of the document to be rendered. + + + - - - - + + + + Indicates that the output component came to an end due to the maximum time limit being reached. + + + From 2e78ff86c2a085d4b024a5624d4dc51edf1225f7 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 22:47:30 +0000 Subject: [PATCH 025/178] [FORMATTING] Fix a missing closing tag brace --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 40cf3173..be183019 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1432,7 +1432,7 @@ - From 50f8a4f05f5dffe02f6183b90f13e908c17763ea Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 23:08:05 +0000 Subject: [PATCH 026/178] [DOC] Comprehensive schema documentation of Input component elements * #4 --- extensions/inbox/rayo.xml | 164 +++++++++++++++++++++++++++++++++----- 1 file changed, 146 insertions(+), 18 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index be183019..f705bf50 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1433,8 +1433,20 @@ - - + + + + Provides a URI at which the grammar document is available. Must not be provided if the content-type attribute is set or the element contains a grammar document as CDATA. + + + + + + + Indicates the content type of the grammar document provided as CDATA. Must not be set if the url attribute is set. + + + @@ -1442,9 +1454,19 @@ + + + Instructs the server to begin an input detector of the specified mode, with certain attributes, governed by the rules provided in one or more grammar documents. + + + + + Indicates the particular variety of input detector to be started. + + @@ -1453,16 +1475,64 @@ - - - - - - - + + + + Indicates a terminator token which, when encountered, should cause the input detection to cease. + + + + + + + Indicates the name of the particular input processor to be engaged. Usually only applies to speech input, in order to specify the recognition language. + + + + + + + Indicates the amount of time preceding input which may expire before a timeout is triggered. + + + + + + + Indicates (in the case of DTMF input) the amount of time between input digits which may expire before a timeout is triggered. + + + + + + + + + + + + + + Indicates the confidence threshold, below which a match is to be considered unreliable. + + + + + + + Indicates the maximum period of silence which may be encountered during input gathering before a timeout is triggered. + + + - + + + + Provides the grammar document by which the input detection should be governed. + + + @@ -1505,29 +1575,69 @@ + + + Indicates that the component came to an end due to one of its grammars matching the received input. + + - + + + + Indicates that the component came to an end because the initial timeout was triggered. + + + - + + + + Indicates that the component came to an end because the inter-digit timeout was triggered. + + + - + + + + Indicates that the component came to an end because the max-silence timeout was triggered. + + + - + + + + Indicates that the component came to an end because the minimum confidence threshold was not reached. + + + - + + + + Indicates that the component came to an end because input was received which did not match any of the specified grammars. + + + + + + Indicates the mode by which the match occurred. + + @@ -1535,9 +1645,27 @@ - - - + + + + Indicates the confidence with which the match has been made. + + + + + + + Provides the result of the grammar match after any symantic processing which may have been performed. + + + + + + + Provides the raw string of the detected input. + + + From 59f9589fa1a408797239158adfd4dc687d22d56b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Jan 2012 23:15:37 +0000 Subject: [PATCH 027/178] [DOC] Comprehensive schema documentation of Record component elements * #4 --- extensions/inbox/rayo.xml | 129 ++++++++++++++++++++++++++++++++++---- 1 file changed, 116 insertions(+), 13 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f705bf50..968c17fe 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1705,19 +1705,77 @@ + + + Instructs the server to begin recording input to the call to a file. + + - - - - - - + + + + File format used during recording. + + + + + + + Indicates whether subsequent record will be preceded with a beep. + + + + + + + Whether subsequent record will start in PAUSE mode. + + + + + + + Indicates the maximum duration for the recording. + + + + + + + Controls how long the recognizer should wait after the end of the prompt for the caller to speak before sending a Recorder event. + + + + + + + Controls the length of a period of silence after callers have spoken to conclude they finished. + + + + + + Optional format-specific encoding hints + + - - + + + + The name of the hint value as expected by the recorder. + + + + + + + The value of the hint provided. + + + @@ -1725,10 +1783,22 @@ - + + + + Instructs the server to cease recording input but to leave the destination open for appending to permit resumption from the same point. + + + - + + + + Instructs the server to continue recording input, appending to the same destination. + + + @@ -1767,6 +1837,11 @@ + + + Indicates that the component came to an end due to the max duration being reached. + + @@ -1774,6 +1849,11 @@ + + + Indicates that the component came to an end due to no input being detected before the initial-timeout + + @@ -1781,6 +1861,11 @@ + + + Indicates that the component came to an end because no input had been detected for the final timeout duration. + + @@ -1788,9 +1873,27 @@ - - - + + + + Indicates the URI at which the recording is made available. + + + + + + + Indicates the duration of the completed recording. + + + + + + + Indicates the filesize (in bytes) of the completed recording. + + + From fd5a55e9cd2f343acbac16dbac2b35f39c5a8a07 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:04:30 +0000 Subject: [PATCH 028/178] Clean up the glossary and add notes about example conventions --- extensions/inbox/rayo.xml | 42 +++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 968c17fe..eb5f8dd0 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -72,21 +72,33 @@
  8. Mixing: Typically referred to as an audio "conference" calls can be joined together so that the participants can hear each other in real-time.
 - - - - - - - - - - - - - - -
TermDefinition
CommandsCommands may be executed against a given call, component or mixer and can be considered completed as soon as they get a response.
ComponentComponents extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/> event
+ + +
+ +
Third-party call control (3PCC)
+
The observation and/or control of a live media session by an entity which is not a direct party to the session.
+ + +
Command
+
Commands instruct the receiving entity to perform some atomic action. Commands may be executed against a given call, component or mixer and can be considered completed as soon as they receive a response.
+ + +
Component
+
Components extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/> event
+ +
+ + + + In examples, the following JIDs are used: +
    +
  • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
    • +
  • shakespeare.lit - The root domain of the Rayo service
    • +
  • call.shakespeare.lit - The Rayo service's call domain
    • +
  • mixer.shakespeare.lit - The Rayo service's mixer domain
    • +
+

From cce08312810512d3a3779364f0794a404ebe8959 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:05:09 +0000 Subject: [PATCH 029/178] Add a basic example session as an introduction --- extensions/inbox/rayo.xml | 100 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index eb5f8dd0..1186cb6e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -59,6 +59,106 @@
  • + + + + +]]> + + + + +]]> + + +]]> + + + + +]]> + + +]]> + + + + ![CDATA[ + You have no new messages. Goodbye! + ]] + + +]]> + + + + +]]> + + + + + + +]]> + + + + +]]> + + +]]> + + + + + + +]]>

    The protocol defined herein is designed to meet the following requirements:

    From df81803ee8cc73e6f3744bb55078ee68df9b137a Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:05:20 +0000 Subject: [PATCH 030/178] Add some missing namespaces --- extensions/inbox/rayo.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1186cb6e..07767024 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -701,8 +701,11 @@
  • urn:xmpp:rayo:ext:1
  • urn:xmpp:rayo:ext:complete:1
  • urn:xmpp:rayo:output:1
    • +
  • urn:xmpp:rayo:output:complete"1
  • urn:xmpp:rayo:input:1
    • +
  • urn:xmpp:rayo:input:complete:1
  • urn:xmpp:rayo:record:1
    • +
  • urn:xmpp:rayo:record:complete:1

    • The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    From 2015803f839001e276f95b94b83a668a4b34859b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:05:37 +0000 Subject: [PATCH 031/178] Add basic notes on history --- extensions/inbox/rayo.xml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 07767024..bd2eb8aa 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2033,4 +2033,16 @@ ]]>     + + Prior to the development of the Rayo protocol, the most widely-used 3PCC protocols were Asterisk's AGI and AMI. Unfortunately, these protocols have many drawbacks, not least in their inconsistency and relatively poor documentation, but also in that they are poorly secured and lacking in attributes required for significant scalability. Much 3PCC activity is also done using process-internal APIs rather than a wire protocol like XMPP. + +

    Rayo was developed to satisfy three main desires:

    +
      +
    • To separate the application logic from the back-end call processing infrastructure for large-scale scripting-based hosted voice application platforms. This helps to ensure that the performance of the back-end infrastructure cannot be impacted by the applications controling it, and specifically to allow sandboxing the applications.
      • +
    • To create a platform-agnostic protocol for the control of live media sessions that has been designed from the start for such use.
      • +
    • To enable authenticated, federated, web-scale 3PCC on platforms with APIs only suitable for trusted internal use (Asterisk, FreeSWITCH, etc).
      • +
    + + Initial development of the Rayo specification and its reference implementation was provided by Voxeo Labs and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols, as well as client library implementations in Node/CoffeeScript and Python. +     From 9087b771b928e825d573f44607cfca68f33c9fe7 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:07:12 +0000 Subject: [PATCH 032/178] Add a whole bunch of TODO comments and section skeletons --- extensions/inbox/rayo.xml | 60 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index bd2eb8aa..6c30f454 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -49,8 +49,20 @@

    Rayo is an extension for controlling phone calls, audio mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle...

    + + + +     +
    1. A call arrives to the Rayo Server
    2. The Rayo Server uses the incoming call's matadata (e.g. SIP headers) to determine the JID of the controlling party
      3. @@ -171,6 +183,8 @@
    3. Call Recording: Can be used to capture the caller's voice (e.g. Voicemail) or both sides of the call for auditing and compliance purposes.
    4. Mixing: Typically referred to as an audio "conference" calls can be joined together so that the participants can hear each other in real-time.
    + +     @@ -187,6 +201,14 @@
    Component
    Components extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/> event
    + +
    Potential controlling party
    +
    +     + +
    Difinitive controlling party
    +
    +     @@ -201,9 +223,40 @@     + + + + + + +

    + + + + + + + + + + + + + + + + + + + + + + + + @@ -676,7 +729,9 @@

    In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

     -

    OPTIONAL.

    + + +     @@ -2044,5 +2099,8 @@ Initial development of the Rayo specification and its reference implementation was provided by Voxeo Labs and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols, as well as client library implementations in Node/CoffeeScript and Python. + + + From fd0451ece7466ace39ed8b8ad4cd2736d2804d1c Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:07:26 +0000 Subject: [PATCH 033/178] Clarify some language --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 6c30f454..27d89697 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -48,7 +48,7 @@ -

    Rayo is an extension for controlling phone calls, audio mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle...

    +

    Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle...

    @@ -181,7 +181,7 @@
  • Touch-tone Events / DTMF: Rayo surfaces real-time event when the caller presses keys on their touch-tone keypad.
  • Speech Recognition: Enables the phone application to take spoken queues allowing for sophisticated voice-driven menus and directory services.
  • Call Recording: Can be used to capture the caller's voice (e.g. Voicemail) or both sides of the call for auditing and compliance purposes.
    • -
  • Mixing: Typically referred to as an audio "conference" calls can be joined together so that the participants can hear each other in real-time.
    • +
  • Mixing: Typically referred to as an audio "conference"; calls can be joined together so that the participants can hear each other in real-time.
    • From c832dcbbaa3ef15158cce4da0c186e01cd90d5c6 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 23 Jan 2012 19:24:28 +0000 Subject: [PATCH 034/178] Remove the business rules section --- extensions/inbox/rayo.xml | 3 --- 1 file changed, 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 27d89697..1aeb364e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -685,9 +685,6 @@

    STRONGLY RECOMMENDED.

     - -

    OPTIONAL.

    -

    If an entity supports Rayo, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo:0" &VNOTE; in response to a &xep0030; information request. The response MUST also include features for the application formats and transport methods supported by the responding entity, as described in the relevant specifications.

    Date: Tue, 24 Jan 2012 16:23:18 +0000 Subject: [PATCH 035/178] [FEATURE] Add skeleton documents for additional specifications on the following topics: * Clustering * Mapping to SIP * Mapping to Jingle * Mapping to Asterisk * Mapping to FreeSWITCH --- extensions/inbox/rayo-asterisk.xml | 125 +++++++++++++++++++++++++ extensions/inbox/rayo-clustering.xml | 132 +++++++++++++++++++++++++++ extensions/inbox/rayo-freeswitch.xml | 125 +++++++++++++++++++++++++ extensions/inbox/rayo-jingle.xml | 132 +++++++++++++++++++++++++++ extensions/inbox/rayo-sip.xml | 132 +++++++++++++++++++++++++++ 5 files changed, 646 insertions(+) create mode 100644 extensions/inbox/rayo-asterisk.xml create mode 100644 extensions/inbox/rayo-clustering.xml create mode 100644 extensions/inbox/rayo-freeswitch.xml create mode 100644 extensions/inbox/rayo-jingle.xml create mode 100644 extensions/inbox/rayo-sip.xml diff --git a/extensions/inbox/rayo-asterisk.xml b/extensions/inbox/rayo-asterisk.xml new file mode 100644 index 00000000..839b64e0 --- /dev/null +++ b/extensions/inbox/rayo-asterisk.xml @@ -0,0 +1,125 @@ + + +%ents; +]> + + +
    + Rayo on Asterisk + This specification describes the best practices for implementing a Rayo server on top of Asterisk. + + This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. + ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## + In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. + This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). + + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me + + + 0.0.1 + 2011-12-05 + bl +

    First draft.

     +     +
    + + + + + + + + + + + +
    + +
    Gateway
    +
    +     +
    +     + + + In examples, the following JIDs are used: +
      +
    • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
      • +
    • shakespeare.lit - The root domain of the Rayo service
      • +
    • call.shakespeare.lit - The Rayo service's call domain
      • +
    • mixer.shakespeare.lit - The Rayo service's mixer domain
      • +
    +     +     + + + + + + + + + + + + + +

    STRONGLY RECOMMENDED.

    +     + + + + + + + + +

    Rayo sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Rayo sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

    +     + +

    Rayo communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. For example, on some SIP networks authentication is optional and "from" addresses can be easily forged. Care must be taken in communicating through such gateways.

    +     + +

    Mere negotiation of a Rayo session can expose sensitive information about the parties (e.g. IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

    +     +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:rayo:gateway:1
      • +
    • urn:xmpp:rayo:node:1
      • +
    +

    The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    +     + +

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    +     +     + + + + + +     diff --git a/extensions/inbox/rayo-clustering.xml b/extensions/inbox/rayo-clustering.xml new file mode 100644 index 00000000..a1be816e --- /dev/null +++ b/extensions/inbox/rayo-clustering.xml @@ -0,0 +1,132 @@ + + +%ents; +]> + + +
    + Rayo Clustering + This specification describes an extension to the Rayo protocol to support clustering of Rayo servers and their presentation as a unified service. + + This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. + ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## + In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. + This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). + + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Jose + de Castro + jdecastro@voxeo.com + jdecastro@voxeo.com + http://voxeolabs.com + + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me + + + 0.0.1 + 2011-12-05 + jdc +

    First draft.

     +     +
    + + + + + + + + + + + +
    + +
    Gateway
    +
    +     +
    +     + + + In examples, the following JIDs are used: +
      +
    • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
      • +
    • shakespeare.lit - The root domain of the Rayo service
      • +
    • call.shakespeare.lit - The Rayo service's call domain
      • +
    • mixer.shakespeare.lit - The Rayo service's mixer domain
      • +
    +     +     + + + + + + + + + + + + + +

    STRONGLY RECOMMENDED.

    +     + + + + + + + + +

    Rayo sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Rayo sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

    +     + +

    Rayo communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. For example, on some SIP networks authentication is optional and "from" addresses can be easily forged. Care must be taken in communicating through such gateways.

    +     + +

    Mere negotiation of a Rayo session can expose sensitive information about the parties (e.g. IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

    +     +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:rayo:gateway:1
      • +
    • urn:xmpp:rayo:node:1
      • +
    +

    The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    +     + +

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    +     +     + + + + + +     diff --git a/extensions/inbox/rayo-freeswitch.xml b/extensions/inbox/rayo-freeswitch.xml new file mode 100644 index 00000000..7e0a84b9 --- /dev/null +++ b/extensions/inbox/rayo-freeswitch.xml @@ -0,0 +1,125 @@ + + +%ents; +]> + + +
    + Rayo on FreeSWITCH + This specification describes the best practices for implementing a Rayo server on top of FreeSWITCH. + + This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. + ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## + In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. + This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). + + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me + + + 0.0.1 + 2011-12-05 + bl +

    First draft.

     +     +
    + + + + + + + + + + + +
    + +
    Gateway
    +
    +     +
    +     + + + In examples, the following JIDs are used: +
      +
    • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
      • +
    • shakespeare.lit - The root domain of the Rayo service
      • +
    • call.shakespeare.lit - The Rayo service's call domain
      • +
    • mixer.shakespeare.lit - The Rayo service's mixer domain
      • +
    +     +     + + + + + + + + + + + + + +

    STRONGLY RECOMMENDED.

    +     + + + + + + + + +

    Rayo sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Rayo sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

    +     + +

    Rayo communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. For example, on some SIP networks authentication is optional and "from" addresses can be easily forged. Care must be taken in communicating through such gateways.

    +     + +

    Mere negotiation of a Rayo session can expose sensitive information about the parties (e.g. IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

    +     +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:rayo:gateway:1
      • +
    • urn:xmpp:rayo:node:1
      • +
    +

    The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    +     + +

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    +     +     + + + + + +     diff --git a/extensions/inbox/rayo-jingle.xml b/extensions/inbox/rayo-jingle.xml new file mode 100644 index 00000000..e12747ba --- /dev/null +++ b/extensions/inbox/rayo-jingle.xml @@ -0,0 +1,132 @@ + + +%ents; +]> + + +
    + Rayo on Jingle + This specification describes the best practices for implementing a Rayo server on top of an XMPP Jingle signaling platform. + + This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. + ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## + In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. + This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). + + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Jose + de Castro + jdecastro@voxeo.com + jdecastro@voxeo.com + http://voxeolabs.com + + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me + + + 0.0.1 + 2011-12-05 + jdc +

    First draft.

     +     +
    + + + + + + + + + + + +
    + +
    Gateway
    +
    +     +
    +     + + + In examples, the following JIDs are used: +
      +
    • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
      • +
    • shakespeare.lit - The root domain of the Rayo service
      • +
    • call.shakespeare.lit - The Rayo service's call domain
      • +
    • mixer.shakespeare.lit - The Rayo service's mixer domain
      • +
    +     +     + + + + + + + + + + + + + +

    STRONGLY RECOMMENDED.

    +     + + + + + + + + +

    Rayo sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Rayo sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

    +     + +

    Rayo communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. For example, on some SIP networks authentication is optional and "from" addresses can be easily forged. Care must be taken in communicating through such gateways.

    +     + +

    Mere negotiation of a Rayo session can expose sensitive information about the parties (e.g. IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

    +     +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:rayo:gateway:1
      • +
    • urn:xmpp:rayo:node:1
      • +
    +

    The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    +     + +

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    +     +     + + + + + +     diff --git a/extensions/inbox/rayo-sip.xml b/extensions/inbox/rayo-sip.xml new file mode 100644 index 00000000..a7af574c --- /dev/null +++ b/extensions/inbox/rayo-sip.xml @@ -0,0 +1,132 @@ + + +%ents; +]> + + +
    + Rayo on SIP + This specification describes the best practices for implementing a Rayo server on top of a SIP signaling platform. + + This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. + ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## + In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. + This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). + + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Jose + de Castro + jdecastro@voxeo.com + jdecastro@voxeo.com + http://voxeolabs.com + + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me + + + 0.0.1 + 2011-12-05 + jdc +

    First draft.

     +     +
    + + + + + + + + + + + +
    + +
    Gateway
    +
    +     +
    +     + + + In examples, the following JIDs are used: +
      +
    • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
      • +
    • shakespeare.lit - The root domain of the Rayo service
      • +
    • call.shakespeare.lit - The Rayo service's call domain
      • +
    • mixer.shakespeare.lit - The Rayo service's mixer domain
      • +
    +     +     + + + + + + + + + + + + + +

    STRONGLY RECOMMENDED.

    +     + + + + + + + + +

    Rayo sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Rayo sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

    +     + +

    Rayo communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. For example, on some SIP networks authentication is optional and "from" addresses can be easily forged. Care must be taken in communicating through such gateways.

    +     + +

    Mere negotiation of a Rayo session can expose sensitive information about the parties (e.g. IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

    +     +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:rayo:gateway:1
      • +
    • urn:xmpp:rayo:node:1
      • +
    +

    The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    +     + +

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    +     +     + + + + + +     From c908775df1beb6d979e883d97876d1483d2ce160 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 24 Jan 2012 17:48:00 +0000 Subject: [PATCH 036/178] [DOC] Explain the 3rd-party nature of Rayo --- extensions/inbox/rayo.xml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1aeb364e..0091feff 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -48,8 +48,6 @@ -

    Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle...

    - +

    Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself. A Rayo server takes on the role of negotiating a session between itself and some other endpoint, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else; the server may even bridge multiple networks. The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session. The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session. Such a relationship looks something like this:

    + + [caller] ----SIP---- [rayo server] -----Jingle---- [calee] +                              | + | +                          rayo client + + + This document defines the core Rayo protocol, and contains provisions for its extension by further specifications. Additionally, further documents specify implementation best practices, such as clustering.     From 0fd3d1cc5a00e2083c9f43820a129ebc40ea1024 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 24 Jan 2012 17:52:44 +0000 Subject: [PATCH 037/178] [FORMATTING] Improve the formatting of the introduction --- extensions/inbox/rayo.xml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0091feff..a322f444 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -49,6 +49,7 @@ +

    Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself.

    -

    Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself. A Rayo server takes on the role of negotiating a session between itself and some other endpoint, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else; the server may even bridge multiple networks. The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session. The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session. Such a relationship looks something like this:

    +
      +
    • A Rayo server takes on the role of negotiating a session between itself and some other endpoint, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else; the server may even bridge multiple networks.
      • +
    • The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session.
      • +

    • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session.

      • +
    + +

    The relationship between the calling parties, the Rayo server and the Rayo client looks something like this:

    [caller] ----SIP---- [rayo server] -----Jingle---- [calee]                              | From 2a9f049d728003996a20cfacd9a7cade558236c4 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 24 Jan 2012 17:54:37 +0000 Subject: [PATCH 038/178] [BUGFIX] Typo fix --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a322f444..586edc5a 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -62,7 +62,7 @@
    • A Rayo server takes on the role of negotiating a session between itself and some other endpoint, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else; the server may even bridge multiple networks.
    • The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session.
      • -

    • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session.

      • +
    • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session.

    The relationship between the calling parties, the Rayo server and the Rayo client looks something like this:

    From e52443311e15e3f502064681032d9e67b42d776d Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 24 Jan 2012 18:21:10 +0000 Subject: [PATCH 039/178] [BUGFIX] Clarify that the Rayo server may or may not be the end point for a call --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 586edc5a..c63cff10 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -60,14 +60,14 @@ * Flexible routing -->
      -
    • A Rayo server takes on the role of negotiating a session between itself and some other endpoint, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else; the server may even bridge multiple networks.
      • +
    • A Rayo server takes on the role of negotiating a session between itself and some other endpoint, or between two distinct endpoints, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else. The server may even bridge multiple networks.
    • The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session.
    • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session.

    The relationship between the calling parties, the Rayo server and the Rayo client looks something like this:

    - [caller] ----SIP---- [rayo server] -----Jingle---- [calee] + [caller] ----SIP---- [rayo server] ( -----Jingle---- [calee] ) optional                              | |                          rayo client From 20c02c732775b0766dd572f81490515a30a25aa8 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 24 Jan 2012 18:21:39 +0000 Subject: [PATCH 040/178] [FORMATTING] Minor --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index c63cff10..8ef3e091 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -73,7 +73,7 @@                          rayo client - This document defines the core Rayo protocol, and contains provisions for its extension by further specifications. Additionally, further documents specify implementation best practices, such as clustering. +

    This document defines the core Rayo protocol, and contains provisions for its extension by further specifications. Additionally, further documents specify implementation best practices, such as clustering.

     From 28f74905d3ead7b81effe18649d5f13aaa18d792 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 24 Jan 2012 18:29:28 +0000 Subject: [PATCH 041/178] [DOC] Annotate the simple session example --- extensions/inbox/rayo.xml | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 8ef3e091..f08f7cef 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -76,15 +76,7 @@

    This document defines the core Rayo protocol, and contains provisions for its extension by further specifications. Additionally, further documents specify implementation best practices, such as clustering.

     - -
      -
    1. A call arrives to the Rayo Server
      2. -
    2. The Rayo Server uses the incoming call's matadata (e.g. SIP headers) to determine the JID of the controlling party
      3. -
    3. An <offer/> is sent to the controlling party
      4. -
    4. -
    5. -
    6. -
    +

    In order to understand the nature of a Rayo interaction, here we show a simple example of a control session.

    ]]> +

    In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate for delegating control of the call, and so has directed an offer event to her 'balcony' resource.

    + +

    The client then decides that it is able to handle the incoming call, and so accepts it from the server, thus gaining exclusive control and indicating to the calling party that the call will be processed and that it should ring.

    + ]]> - Following confirmation from the server that the attempt to gain control of the call was successful, the client proceeds to answer the call, opening up the media stream between the caller and the server.

    + + ]]> - Once the client has confirmation that the call has been answered, it triggers the start of a media output component in order to play a message to the caller using a Text-to-speech (TTS) engine.

    + + ]]> +

    After confirmation that the output component was successfully created, the client then awaits notification of its completion.

    + ]]> +

    The client then decides it has no further operations to perform on the call, and that the call should end. It instructs the server to hang up the call gracefully.

    + Date: Tue, 24 Jan 2012 20:48:21 +0000 Subject: [PATCH 042/178] [DOC] Explain Rayo's features and design requirements --- extensions/inbox/rayo.xml | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f08f7cef..5f6f0347 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -48,17 +48,8 @@ -

    Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself.

    -
    • A Rayo server takes on the role of negotiating a session between itself and some other endpoint, or between two distinct endpoints, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else. The server may even bridge multiple networks.
    • The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session.
      • @@ -191,7 +182,7 @@ ]]> -

      The protocol defined herein is designed to meet the following requirements:

      +

      1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Evey attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
      2. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
        3. @@ -202,7 +193,29 @@
      3. Mixing: Typically referred to as an audio "conference"; calls can be joined together so that the participants can hear each other in real-time.
      - +

      Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have at least one or more of the following drawbacks:

      +
        +
      • Totally ground-up wire protocol requiring implementation all the way down to the socket
        • +
      • Platform/vendor/hardware specific
        • +
      • Synchronous interface
        • +
      • Inconsistent - evolved, rather than designed
        • +
      • Lacking in scaleability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
        • +
      • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
        • +
      • Inextensible
        • +
      + +

      Rayo has been designed with these failings in mind, and intends to address many concerns not addressed by these earlier attempts. The following considerations were made:

      +
        +
      • Simple client library implementation - XMPP client libraries exist in all modern languages, and many are of a high standard.
        • +
      • Cross-platform standard - The protocol must not expose any platform specifics and all elements should be candidates for implementation on any suitable platform. Addiditionally, the protocol must be ratified as a standard following a community discussion.
        • +
      • Asynchronous interface - The protocol should present an asynchronous interface for the purposes of performance and flexibility in performing paralell operations.
        • +
      • Consistent - The protocol must provide a considered, unobtrusive, logically and philisophically consistent interface.
        • +
      • Federated - The protocol must support communication between client and server entities on separately owned, operated and addressed networks.
        • +
      • Flexible routing - The protocol must lend itself to routing across wide networks such as the internet, and to potential complex routing such as proxying or redirection. Additionally, the client and server should each be aware of the presence of the other and be able to use such information to make routing decisions.
        • +
      • Extensible - The protocol must provide for the possibility of extra functionality being added by future specifications or an individual implementation.
        • +
      + +

      Additionally, the protocol is required to abstract away the complexity of the raw negotioation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Jingle and FreeSWITCH are made in the respective specifications.

       @@ -743,6 +756,9 @@ ]]>

      In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

       + + + From 96cc42547db06adef3012c6cb9581dc6daad5371 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 12:48:50 +0000 Subject: [PATCH 043/178] [DOC] Define Potential/Difinitive controlling party --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 5f6f0347..63fff480 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -234,11 +234,11 @@
      Potential controlling party
      -
      +
      An XMPP entity to which an offer to control an incoming call may be sent.
      Difinitive controlling party
      -
      +
      The XMPP entity which gains a lock on control of a session, either by requesting the session's creation, or being the first respondent to an offer.
       From b744d6e61295fcf5327d948c0972ff7a96521883 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 13:40:43 +0000 Subject: [PATCH 044/178] [DOC] Explain the many elements of a rayo system --- extensions/inbox/rayo.xml | 37 +++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 63fff480..1ad94e0e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -254,14 +254,35 @@       - - - - - - - -

      +

      A complete Rayo deployment has several elements and interacting entities which must be understood.

      + + +

      A Rayo server is an entity which is capable of receiving and intiating calls and being party to their media stream, while exposing a Rayo interface to a client in order to permit control over its calls. The Rayo server may handle calls in any way supported by the implementation, such as SIP, Jingle, etc, and should expose a full XMPP domain at the root level of the service deployment (eg shakespeare.lit).

      +

      The Rayo server is responsible for keeping track of valid clients, routing calls to the correct potential controlling parties, performing authorization measures on received stanzas, etc.

      +

      For the purposes of this specification, complex server-side deployments such as clusters, proxies, gateways, protocol translators, etc are not considered. Further details of such concepts may be found in their relevant specifications.

      +       + +

      A Rayo client is an entity which implements the Rayo protocol for the purpose of asserting control over calls made available by a Rayo server. The method by which such control measures are determined is outside the scope of this document, but may be the result of human interaction or some automated decision-making process.

      +

      A Rayo client is responsible for indicating its availability to a Rayo server and responding to offer messages appropriately.

      +       + +

      A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a single session. It is usually a simple alias for the main server process.

      +

      A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client.

      +

      Calls have separate presence from the root domain of the service and thus appear to be separate entities.

      +       + +

      A Rayo call is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

      +

      A Rayo mixer is responsible for sending its events to and receiving commands from a client, and may have some components executed on it directly.

      +

      Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

      +       + +

      A Rayo command is a simple combination of request and response and may be issued directly to the service, or to a call or mixer. Commands are executed serially and are generally very short-lived.

      +       + +

      Components extend the Rayo protocol by providing additional media and call control functionality.

      + +

      Components are started by sending a specialized command to a call or mixer. Unlike basic commands, components have a lifecycle. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

      +       From f9956bf888d30d7409fd72870dc2040191b4c0cd Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 13:48:35 +0000 Subject: [PATCH 045/178] [FORMATTING] Bolden some list items --- extensions/inbox/rayo.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1ad94e0e..25f85d45 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -195,13 +195,13 @@

      Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have at least one or more of the following drawbacks:

        -
      • Totally ground-up wire protocol requiring implementation all the way down to the socket
        • -
      • Platform/vendor/hardware specific
        • -
      • Synchronous interface
        • -
      • Inconsistent - evolved, rather than designed
        • -
      • Lacking in scaleability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
        • -
      • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
        • -
      • Inextensible
        • +
      • Totally ground-up wire protocol requiring implementation all the way down to the socket
        • +
      • Platform/vendor/hardware specific
        • +
      • Synchronous interface
        • +
      • Inconsistent - evolved, rather than designed
        • +
      • Lacking in scaleability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
        • +
      • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
        • +
      • Inextensible

      Rayo has been designed with these failings in mind, and intends to address many concerns not addressed by these earlier attempts. The following considerations were made:

      From 92b1853c668db120c3c8576c32057eaf900c932b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 16:02:57 +0000 Subject: [PATCH 046/178] [DOC] Add notes on addressing scheme --- extensions/inbox/rayo.xml | 99 ++++++++++++++++++++++++++++----------- 1 file changed, 72 insertions(+), 27 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 25f85d45..e29a30e2 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -256,37 +256,82 @@

      A complete Rayo deployment has several elements and interacting entities which must be understood.

      - -

      A Rayo server is an entity which is capable of receiving and intiating calls and being party to their media stream, while exposing a Rayo interface to a client in order to permit control over its calls. The Rayo server may handle calls in any way supported by the implementation, such as SIP, Jingle, etc, and should expose a full XMPP domain at the root level of the service deployment (eg shakespeare.lit).

      -

      The Rayo server is responsible for keeping track of valid clients, routing calls to the correct potential controlling parties, performing authorization measures on received stanzas, etc.

      -

      For the purposes of this specification, complex server-side deployments such as clusters, proxies, gateways, protocol translators, etc are not considered. Further details of such concepts may be found in their relevant specifications.

      -       - -

      A Rayo client is an entity which implements the Rayo protocol for the purpose of asserting control over calls made available by a Rayo server. The method by which such control measures are determined is outside the scope of this document, but may be the result of human interaction or some automated decision-making process.

      -

      A Rayo client is responsible for indicating its availability to a Rayo server and responding to offer messages appropriately.

      -       - -

      A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a single session. It is usually a simple alias for the main server process.

      -

      A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client.

      -

      Calls have separate presence from the root domain of the service and thus appear to be separate entities.

      -       - -

      A Rayo call is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

      -

      A Rayo mixer is responsible for sending its events to and receiving commands from a client, and may have some components executed on it directly.

      -

      Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

      -       - -

      A Rayo command is a simple combination of request and response and may be issued directly to the service, or to a call or mixer. Commands are executed serially and are generally very short-lived.

      + + +

      A Rayo server is an entity which is capable of receiving and intiating calls and being party to their media stream, while exposing a Rayo interface to a client in order to permit control over its calls. The Rayo server may handle calls in any way supported by the implementation, such as SIP, Jingle, etc, and should expose a full XMPP domain at the root level of the service deployment (eg shakespeare.lit).

      +

      The Rayo server is responsible for keeping track of valid clients, routing calls to the correct potential controlling parties, performing authorization measures on received stanzas, etc.

      +

      For the purposes of this specification, complex server-side deployments such as clusters, proxies, gateways, protocol translators, etc are not considered. Further details of such concepts may be found in their relevant specifications.

      +       + +

      A Rayo client is an entity which implements the Rayo protocol for the purpose of asserting control over calls made available by a Rayo server. The method by which such control measures are determined is outside the scope of this document, but may be the result of human interaction or some automated decision-making process.

      +

      A Rayo client is responsible for indicating its availability to a Rayo server and responding to offer messages appropriately.

      +       + +

      A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a single session. It is usually a simple alias for the main server process.

      +

      A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client.

      +

      Calls have separate presence from the root domain of the service and thus appear to be separate entities.

      +       + +

      A Rayo call is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

      +

      A Rayo mixer is responsible for sending its events to and receiving commands from a client, and may have some components executed on it directly.

      +

      Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

      +       + +

      A Rayo command is a simple combination of request and response and may be issued directly to the service, or to a call or mixer. Commands are executed serially and are generally very short-lived.

      +       + +

      Components extend the Rayo protocol by providing additional media and call control functionality.

      + +

      Components are started by sending a specialized command to a call or mixer. Unlike basic commands, components have a lifecycle. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

      +       - -

      Components extend the Rayo protocol by providing additional media and call control functionality.

      -

      Components are started by sending a specialized command to a call or mixer. Unlike basic commands, components have a lifecycle. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

      + +

      All of the actors described in the previous section (with the exception of commands) are represented by XMPP entities with a JID of their own. Thus, a scheme for determining the JIDs of each of these entities is required. The following is the required naming scheme for Rayo deployments.

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ActorJID formatExample JID
      Server[service domain]shakespeare.lit
      Clientany JIDjuliet@capulet.lit/balcony
      Call[call ID]@[call sub-domain].[service domain]f88eh2@call.shakespeare.lit
      Mixer[mixer name]@[mixer sub-domain].[service domain]conf1@mixer.shakespeare.lit
      Call Component[call ID]@[call sub-domain].[service domain]/[component ID]f88eh2@call.shakespeare.lit/8f83jf
      Mixer Component[mixer name]@[mixer sub-domain].[service domain]/[component ID]conf1@mixer.shakespeare.lit/932eu
      Server Component[service domain]/[component ID]shakespeare.lit/f3fg4
             - - - From 0a9476be2545fb4c9a6e832c42d83ef180d692fc Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 16:17:29 +0000 Subject: [PATCH 047/178] [DOC] Notes on where commands should be directed Finishes #7 --- extensions/inbox/rayo.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index e29a30e2..d1ab65b0 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -330,6 +330,7 @@ shakespeare.lit/f3fg4 +

      Commands should be addressed to the entity on which they should be enacted. Individual commands only apply to certain object (for example instructing a component to hangup will return an error). In general, commands may be sent from a client to the service, a call, a mixer or a component. Events may be sent from a call, a mixer or a component to a client.

             From 206b5c969e8394bfc3292af16ce3d384119f1114 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 16:20:24 +0000 Subject: [PATCH 048/178] [DOC] Notes on how Rayo elements should be enclosed in presence/iq --- extensions/inbox/rayo.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index d1ab65b0..24b6e8ee 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -332,6 +332,14 @@

      Commands should be addressed to the entity on which they should be enacted. Individual commands only apply to certain object (for example instructing a component to hangup will return an error). In general, commands may be sent from a client to the service, a call, a mixer or a component. Events may be sent from a call, a mixer or a component to a client.

      + + +

      Rayo defines several events and commands which may be executed on one of the above actors. These payloads must be sent within an XMPP primitive element, and the rules are as such:

      +
        +
      • Events: Sent as directed presence from the entity producing the event to a client.
        • +
      • Commands: Sent as an <iq/> 'set' from the client to the entity to be acted on. Responses returned as an <iq/> 'result' or 'error'.
        • +
      +       From 6a64e1976dab7462c0fdc9d64dc4b4ee125ab0b2 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 16:56:16 +0000 Subject: [PATCH 049/178] [FORMATTING] Remove duplication of shared types between all schema Fixes #3 --- extensions/inbox/rayo.xml | 222 ++++++++------------------------------ 1 file changed, 43 insertions(+), 179 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 24b6e8ee..725dea5a 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1346,7 +1346,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -1355,7 +1356,7 @@ - + Instructs a component to come to an end before it completes naturally. @@ -1383,24 +1384,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]>       @@ -1410,7 +1393,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -1455,24 +1439,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> @@ -1482,7 +1448,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -1499,7 +1466,7 @@ - + Indicates some offset through which the output should be skipped before rendering begins. @@ -1513,7 +1480,7 @@ - + Indicates the duration of silence that should space repeats of the rendered document. @@ -1527,7 +1494,7 @@ - + Indicates the maximum amount of time for which the output should be allowed to run before being terminated. Includes repeats. @@ -1541,7 +1508,7 @@ - + Instructs the server to cease rendering output at the current marker and permit resumption from the same point. @@ -1550,7 +1517,7 @@ - + Instructs the server to continue rendering the output from the last pause marker. @@ -1573,7 +1540,7 @@ - + Indicates the duration of audio to skip through. @@ -1584,7 +1551,7 @@ - + Instructs the server to increase the rate of output by a unit amount. @@ -1593,7 +1560,7 @@ - + Instructs the server to decrease the rate of output by a unit amount. @@ -1602,7 +1569,7 @@ - + Instructs the server to increase the volume of output by a unit amount. @@ -1611,7 +1578,7 @@ - + Instructs the server to decrease the volume of output by a unit amount. @@ -1619,24 +1586,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> @@ -1646,7 +1595,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -1655,7 +1605,7 @@ - + Indicates that the output component came to an end as a result of reaching the end of the document to be rendered. @@ -1664,7 +1614,7 @@ - + Indicates that the output component came to an end due to the maximum time limit being reached. @@ -1672,24 +1622,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> @@ -1699,7 +1631,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -1765,14 +1698,14 @@ - + Indicates the amount of time preceding input which may expire before a timeout is triggered. - + Indicates (in the case of DTMF input) the amount of time between input digits which may expire before a timeout is triggered. @@ -1793,7 +1726,7 @@ - + Indicates the maximum period of silence which may be encountered during input gathering before a timeout is triggered. @@ -1814,24 +1747,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> @@ -1841,7 +1756,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -1862,7 +1778,7 @@ - + Indicates that the component came to an end because the initial timeout was triggered. @@ -1871,7 +1787,7 @@ - + Indicates that the component came to an end because the inter-digit timeout was triggered. @@ -1880,7 +1796,7 @@ - + Indicates that the component came to an end because the max-silence timeout was triggered. @@ -1889,7 +1805,7 @@ - + Indicates that the component came to an end because the minimum confidence threshold was not reached. @@ -1898,7 +1814,7 @@ - + Indicates that the component came to an end because input was received which did not match any of the specified grammars. @@ -1944,24 +1860,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> @@ -1971,7 +1869,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -2008,21 +1907,21 @@ - + Indicates the maximum duration for the recording. - + Controls how long the recognizer should wait after the end of the prompt for the caller to speak before sending a Recorder event. - + Controls the length of a period of silence after callers have spoken to conclude they finished. @@ -2059,7 +1958,7 @@ - + Instructs the server to cease recording input but to leave the destination open for appending to permit resumption from the same point. @@ -2068,7 +1967,7 @@ - + Instructs the server to continue recording input, appending to the same destination. @@ -2076,24 +1975,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> @@ -2103,7 +1984,8 @@ + elementFormDefault="qualified" + xmlns:core="urn:xmpp:rayo:1"> @@ -2156,7 +2038,7 @@ - + Indicates the duration of the completed recording. @@ -2172,24 +2054,6 @@ - - - - - - - - - - - - - Value is a duration in milleseconds - - - - - ]]> From 721e856ebb03612cd409942ca1c457c2298a144e Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 17:22:14 +0000 Subject: [PATCH 050/178] [FEATURE] Use a timeoutType for all timeout attributes * Limits to min -1 * Documents -1 as a NULL value --- extensions/inbox/rayo.xml | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 725dea5a..a16edc22 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1137,7 +1137,7 @@ - + Indicates the maximum time allowed for a response to be provided by the third party before the call should be considered to have come to an end. @@ -1337,6 +1337,19 @@ + + + + + A value of -1 indicates no timeout + + + + + + + + ]]> @@ -1494,7 +1507,7 @@ - + Indicates the maximum amount of time for which the output should be allowed to run before being terminated. Includes repeats. @@ -1698,14 +1711,14 @@ - + Indicates the amount of time preceding input which may expire before a timeout is triggered. - + Indicates (in the case of DTMF input) the amount of time between input digits which may expire before a timeout is triggered. @@ -1726,7 +1739,7 @@ - + Indicates the maximum period of silence which may be encountered during input gathering before a timeout is triggered. @@ -1907,21 +1920,21 @@ - + Indicates the maximum duration for the recording. - + Controls how long the recognizer should wait after the end of the prompt for the caller to speak before sending a Recorder event. - + Controls the length of a period of silence after callers have spoken to conclude they finished. From 87bdd4741954a939f30e83f3756257763bc87aa9 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 17:30:12 +0000 Subject: [PATCH 051/178] [FEATURE] Restrict some attributes to token values --- extensions/inbox/rayo.xml | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a16edc22..f95baf05 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1158,7 +1158,7 @@ - + Instructs the server to join the media streams of the call and the specified party, given direction and media negotiation parameters. @@ -1167,14 +1167,14 @@ - + Indicates the direction in which the media should flow between the call and the 3rd party. - + @@ -1199,14 +1199,14 @@ - + Indicates the manner in which the server should negotiate media between the two parties. - + @@ -1257,14 +1257,14 @@ - + Indicates the 3rd party call ID to which the target call should be joined. May not be set if the mixer-name attribute is set. - + Indicates the mixer name to which the target call should be joined. May not be set if the call-id attribute is set. @@ -1292,7 +1292,7 @@ - + Indicates the ID of the call which has triggered the speech detector. @@ -1309,7 +1309,7 @@ - + Gives the ID of the new resource. @@ -1546,12 +1546,18 @@ - + Indicates the direction in which the play marker should be moved through the rendered audio. + + + + + + @@ -1690,21 +1696,21 @@ - + - + Indicates a terminator token which, when encountered, should cause the input detection to cease. - + Indicates the name of the particular input processor to be engaged. Usually only applies to speech input, in order to specify the recognition language. @@ -1844,7 +1850,7 @@ - + @@ -1899,7 +1905,7 @@ - + File format used during recording. From b8de745a80000f0658dfe74f6fb256c4d99856de Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 17:30:56 +0000 Subject: [PATCH 052/178] [FEATURE] Restrict some values to values between 0-1 --- extensions/inbox/rayo.xml | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f95baf05..6b08ac23 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1350,6 +1350,14 @@ + + + + + + + + ]]> @@ -1731,14 +1739,14 @@ - + - + Indicates the confidence threshold, below which a match is to be considered unreliable. @@ -1856,7 +1864,7 @@ - + Indicates the confidence with which the match has been made. From e1ca0bf478055f9a65c95bbf3ac432fb0e9a94ed Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 17:31:12 +0000 Subject: [PATCH 053/178] [FEATURE] Restrict some values to be positive only --- extensions/inbox/rayo.xml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 6b08ac23..457b596f 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1508,7 +1508,7 @@ - + Indicates the number of times the output should be played. @@ -1567,12 +1567,17 @@ - + Indicates the duration of audio to skip through. + + + + + From 2276ffadb176614a1122e4eb755706bb8c6d91c1 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 17:31:30 +0000 Subject: [PATCH 054/178] [DOC] Add documentation for sensitivity attribute on Input --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 457b596f..448efbc1 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1747,7 +1747,7 @@ - + Indicates how sensitive the interpreter should be to loud versus quiet input. Higher values represent greater sensitivity. From e52f3395f65b5eac660f368154133b4392c01886 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Jan 2012 17:41:51 +0000 Subject: [PATCH 055/178] [FEATURE] Output command should include the document in a child element Fixes #5 --- extensions/inbox/rayo.xml | 76 +++++++++++++++++++++------------------ 1 file changed, 41 insertions(+), 35 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 448efbc1..84d386f5 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1486,45 +1486,51 @@ - - - - - Indicates some offset through which the output should be skipped before rendering begins. - - - - - - - Indicates wether or not the component should be started in a paused state to be resumed at a later point. - - - - - - - Indicates the duration of silence that should space repeats of the rendered document. - - - - - - - Indicates the number of times the output should be played. - - - - + + + + Indicates some offset through which the output should be skipped before rendering begins. + + + + + + + Indicates wether or not the component should be started in a paused state to be resumed at a later point. + + + + + + + Indicates the duration of silence that should space repeats of the rendered document. + + + + + + + Indicates the number of times the output should be played. + + + + + + + Indicates the maximum amount of time for which the output should be allowed to run before being terminated. Includes repeats. + + + + + + - Indicates the maximum amount of time for which the output should be allowed to run before being terminated. Includes repeats. + An SSML document for rendering (contained within CDATA). - - - - + + From f12dbcc6201f5497961a20e3c7b7b66cbcfba892 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 11:21:16 +0000 Subject: [PATCH 056/178] [CS] Remove irrelevant comments from implementation notes * These issues will be addressed in further specifications --- extensions/inbox/rayo.xml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 84d386f5..e7965ff4 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -835,9 +835,7 @@ - - - + From 927f81db627c0912b907d75b4137e607ed4a0841 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 11:26:37 +0000 Subject: [PATCH 057/178] [DOC] Add notes on extending Rayo --- extensions/inbox/rayo.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index e7965ff4..a215581b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -832,7 +832,9 @@

      In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

       - +

      Rayo is a protocol designed for extensibility. Rayo implementations and deployments have great flexibility in the way they map the Rayo protocol to their underlying transport and media layers, and the functionality they provide around the Rayo interface to the system.

      + +

      Further commands and components may also be added to the Rayo protocol in order to extend its capabilities. Such extensions should be submitted to the XSF as ProtoXEPs and use namespaces aligning with the core component namespaces.

       From eb00e496c3ada5b23fc4ce07cac69c6095222408 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 11:32:50 +0000 Subject: [PATCH 058/178] [DOC] Better abstract --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a215581b..2b341ce4 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -7,7 +7,7 @@
      Rayo - This specification describes the Rayo third-party call control protocol. + This specification defines an XMPP protocol extension for the third-party control of telephone calls and other similar media sessions. The protocol includes support for session management/signaling, as well as advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. The protocol serves a different purpose from that of first-party protocols such as Jingle or SIP, and is compatible with those protocols. This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. From 22c7da26d2209bf34afc82d4466a178aed4f6efb Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 17:13:08 +0000 Subject: [PATCH 059/178] [FEATURE] Complete the schema for the header element * Name attribute type (token) * Documentation * Attribute Inclusion --- extensions/inbox/rayo.xml | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2b341ce4..f7c53f6c 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -902,8 +902,20 @@ - - + + + + A token giving the name by which the header may be known. + + + + + + + The string value of the named header. + + + From 2bf82cfdf9a49b86854a7a2d384f8ce5db6a1177 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 18:00:08 +0000 Subject: [PATCH 060/178] [DOC] Bring the formal definition up to date with the core schema --- extensions/inbox/rayo.xml | 346 +++++++++++++++++++++++++++++++++----- 1 file changed, 301 insertions(+), 45 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f7c53f6c..5c0a864e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -365,60 +365,112 @@ - - - -

      The offer element MAY be empty or contain one or more header elements (for which see Header Element).

      -

      The attributes of the offer element are as follows.

      - + + +

      The header element MUST be empty.

      +

      The attributes of the header element are as follows.

      +
      - - + + - - + +
      Attribute Definition Inclusion
      toA valid Rayo URI indicating the target of the call as described under Call target/source URI.nameA token giving the name by which the header may be known. REQUIRED
      fromA valid Rayo URI indicating the source of the call as described under Call target/source URI.valueThe string value of the named header. REQUIRED
      - -

      The header element MUST be empty.

      -

      The attributes of the header element are as follows.

      - + + +

      Informs the recipient that a new call is available for control and invites it to take control using progress commands below.

      +

      The offer element MAY contain one or more header elements.

      +

      The attributes of the offer element are as follows.

      +
      - - + + - - - + + +
      Attribute Definition Inclusion
      nameA string representing the name by which the header may be known.toThe target URI for the call. May me a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. REQUIRED
      valueA string value for the named header.REQUIREDfromThe caller ID URI for the call. May be a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism.OPTIONAL
      + + +

      Indication that an outbound call has begun ringing, or accepted by the remote party.

      +

      The ringing element MAY contain one or more header elements.

      +

      The ringing element has no attributes.

      +       + + +

      Indication that an outbound call has been answered and that the 3rd party negotiation has completed. At this point, the media stream should be open.

      +

      The answered element MAY contain one or more header elements.

      +

      The answered element has no attributes.

      +       + + +

      Indication that the call has come to an end, giving the reason.

      +

      The end element MUST contain a single end reason element (for which see End Reason Element). It MAY also contain one or more header elements.

      +

      The end element has no attributes.

      + + +

      The following are valid end reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

      + +
      + +
      <hungup/>
      +
      Indication that the call ended due to a normal hangup by either party.
      +       + +
      <timeout/>
      +
      Indication that the call ended due to a timeout in contacting the remote party.
      +       + +
      <busy/>
      +
      Indication that the call ended due to being rejected by the remote party subsequent to being accepted.
      +       + +
      <reject/>
      +
      Indication that the call ended due to being rejected by the remote party before being accepted.
      +       + +
      <error/>
      +
      Indication that the call ended due to a system error.
      +       +
      +       +       + -

      The accept element MAY be empty or contain one or more header elements (for which see Header Element).

      +

      Instructs the server to send notification to the calling party that the call will be dealt with and that ringing may begin.

      +

      The accept element MAY contain one or more header elements.

      The accept element has no attributes.

       + -

      The answer element MAY be empty or contain one or more header elements (for which see Header Element).

      +

      Instructs the server to pick up an incoming call and connect the media stream.

      +

      The answer element MAY contain one or more header elements.

      The answer element has no attributes.

       + -

      The redirect element MAY be empty or contain one or more header elements (for which see Header Element).

      +

      Instructs the calling party that the call will not be accepted and that instead it should try to call the URI indicated in the command.

      +

      The redirect element MAY contain one or more header elements.

      The attributes of the redirect element are as follows.

      @@ -428,52 +480,249 @@ - +
      toA valid Rayo URI indicating the new target for the call as described under Call target/source URI.The new target URI for the call to be redirected to. REQUIRED
      + -

      The reject element MUST contain a single reject reason element (for which see Reject Reason Element). It MAY also contain one or more header elements (for which see Header Element).

      +

      Instructs the server to reject the call with a given reason.

      +

      The reject element MUST contain a single reject reason element (for which see Reject Reason Element). It MAY also contain one or more header elements.

      The reject element has no attributes.

      + + +

      The following are valid end reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

      + +
      + +
      <decline/>
      +
      Indicates that the controlling party refused the call for an unspecified reason, such as access control.
      +       + +
      <busy/>
      +
      Indicates that the controlling party refused the call due to excess load.
      +       + +
      <error/>
      +
      Indicates that the controlling party refused the call because some error occurred.
      +       +
      +       + + +

      Instructs the server to bring the call to an end naturally.

      +

      The hangup element MAY contain one or more header elements.

      +

      The hangup element has no attributes.

      +       + -

      The dial element MAY be empty or contain one or more header elements (for which see Header Element).

      +

      Instructs the server to create a new call and surrender control of it to the requesting party.

      +

      The dial element MAY contain one or more header elements. It MAY contain one or more join elements, instructing the server to join the new call in the indicated manner rather than the default (join to the local media server).

      The attributes of the dial element are as follows.

      + - + + - - + + + + + + + + +
      Attribute Definition InclusionDefault
      toA valid Rayo URI indicating the target of the call as described under Call target/source URI.Indicates the party to whom the call should be directed. REQUIRED
      fromA valid Rayo URI indicating the source of the call as described under Call target/source URI.REQUIREDIndicates the caller ID with which the call should appear to originate.OPTIONAL
      timeoutIndicates the maximum time allowed for a response to be provided by the third party before the call should be considered to have come to an end.OPTIONAL-1
      - -

      The ringing element MAY be empty or contain one or more header elements (for which see Header Element).

      -

      The ringing element has no attributes.

      + + +

      Instructs the server to join the media streams of the call and the specified party, given direction and media negotiation parameters.

      +

      The join element MUST be empty.

      +

      The attributes of the join element are as follows.

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      AttributeDefinitionInclusionDefault
      direction +

      Indicates the direction in which the media should flow between the call and the 3rd party. Must be one of the following values:

      +
        +
      • "duplex" - Indicates that media should flow in both directions between the parties.
        • +
      • "send" - Indicates that media should only flow from the target call to the third party.
        • +
      • "recv" - Indicates that media should only flow from the third party to the target call.
        • +
      +       		OPTIONALduplex
      media +

      Indicates the manner in which the server should negotiate media between the two parties. Must be one of the following values:

      +
        +
      • "bridge" - Instructs the server to bridge the parties media streams via its local media server.
        • +
      • "direct" - Instructs the server to have the parties negotiate media directly with one another.
        • +
      +       		OPTIONALbridge
      call-idIndicates the 3rd party call ID to which the target call should be joined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set
      mixer-nameIndicates the mixer name to which the target call should be joined.REQUIRED unless call-id is set. MUST NOT be set if call-id is set.
       - -

      The answered element MAY be empty or contain one or more header elements (for which see Header Element).

      -

      The answered element has no attributes.

      + + +

      Instructs the server to unjoin the media streams of the call and the specified party.

      +

      The unjoin element MUST be empty.

      +

      The attributes of the unjoin element are as follows.

      + + + + + + + + + + + + + + + + +
      AttributeDefinitionInclusion
      call-idIndicates the 3rd party call ID from which the target call should be unjoined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set
      mixer-nameIndicates the mixer name from which the target call should be unjoined.REQUIRED unless call-id is set. MUST NOT be set if call-id is set.
       - -

      The end element MUST contain a single end reason element (for which see End Reason Element). It MAY also contain one or more header elements (for which see Header Element).

      -

      The end element has no attributes.

      + + +

      Indicates that the call was successfully joined to the specified party.

      +

      The joined element MUST be empty.

      +

      The attributes of the joined element are as follows.

      + + + + + + + + + + + + + + + + +
      AttributeDefinitionInclusion
      call-idIndicates the 3rd party call ID to which the target call was joined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set
      mixer-nameIndicates the mixer name to which the target call was joined.REQUIRED unless call-id is set. MUST NOT be set if call-id is set.
       - -

      The hangup element MAY contain one or more header elements (for which see Header Element).

      -

      The hangup element has no attributes.

      + + +

      Indicates that the call ceased to be joined to the specified party.

      +

      The unjoined element MUST be empty.

      +

      The attributes of the unjoined element are as follows.

      + + + + + + + + + + + + + + + + +
      AttributeDefinitionInclusion
      call-idIndicates the 3rd party call ID from which the target call was unjoined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set
      mixer-nameIndicates the mixer name from which the target call was unjoined.REQUIRED unless call-id is set. MUST NOT be set if call-id is set.
       + + +

      Indicates that a call joined to a mixer with which the controlling party has an events subscription has activated a speech detector, providing its ID.

      +

      The started-speaking element MUST be empty.

      +

      The attributes of the started-speaking element are as follows.

      + + + + + + + + + + + +
      AttributeDefinitionInclusion
      call-idIndicates the ID of the call which has triggered the speech detector.REQUIRED
      +       + + +

      Indicates that a call joined to a mixer with which the controlling party has an events subscription has ceased activation of a speech detector, providing its ID.

      +

      The stopped-speaking element MUST be empty.

      +

      The attributes of the stopped-speaking element are as follows.

      + + + + + + + + + + + +
      AttributeDefinitionInclusion
      call-idIndicates the ID of the call which has triggered the speech detector.REQUIRED
      +       + + +

      Used to give an indication of the identity of a newly created resource, either a call or a component.

      +

      The ref element MUST be empty.

      +

      The attributes of the ref element are as follows.

      + + + + + + + + + + + +
      AttributeDefinitionInclusion
      idGives the ID of the new resource.REQUIRED
      +       +

      An output component is used to instruct the server to generate audible output to a call or mixer.

      @@ -606,6 +855,7 @@       +

      An input component is used to instruct the server to gather media input from a call or mixer, using either DTMF or ASR.

      The input element MUST contain one or more grammar elements (for which see Grammar Element).

      @@ -929,14 +1179,14 @@ - The target URI for the call. May me a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. + The target URI for the call. May be a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. - The caller ID URI for the call. May me a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. + The caller ID URI for the call. May be a tel URI, SIP URI, a JID (for Jingle) or some other platform-specific addressing mechanism. @@ -980,7 +1230,7 @@ - Indicated to a call's controlling party that the call has come to an end, giving the reason. + Indication that the call has come to an end, giving the reason. @@ -1069,7 +1319,13 @@ - + + + + The new target URI for the call to be redirected to. + + + @@ -1161,7 +1417,7 @@ - Instructs the server to join the new call in the indicated mannor rather than the default (join to the local media server). + Instructs the server to join the new call in the indicated manner rather than the default (join to the local media server). From 343e859c4c354e397efa3be3d0ee4eb08d4df792 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 19:34:28 +0000 Subject: [PATCH 061/178] [DOC] Include generic component elements in formal definition --- extensions/inbox/rayo.xml | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 5c0a864e..c8039473 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -492,7 +492,7 @@

      The reject element has no attributes.

      -

      The following are valid end reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

      +

      The following are valid reject reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

      @@ -724,6 +724,38 @@ + + +

      Instructs a component to come to an end before it completes naturally.

      +

      The stop element MUST be empty.

      +

      The stop element has no attributes.

      +       + + +

      Indicates that the component has come to an end and no further processing will occurr. Gives the reason for the termination.

      +

      The complete element MUST contain exactly one child element, indicating the reason for the complete event being raised. The reason may be a core complete reason or a reason specific to a particular component.

      +

      The complete element has no attributes.

      + + +

      The following are valid complete reason elements. They all MAY contain further component-specific metadata elements, but they do not have any attributes.

      + +
      + +
      <stop/>
      +
      Indicates that the component came to an end because it was issued a stop command by the controlling party.
      +       + +
      <hangup/>
      +
      Indicates that the component came to an end because the call ended.
      +       + +
      <error/>
      +
      Indicates that the component came to an end because it encountered an error.
      +       +
      +       +       +

      An output component is used to instruct the server to generate audible output to a call or mixer.

      The output element MUST contain a single CDATA entitiy containing the SSML document to render.

      From 4aad790d8eeecf6dc261837e7554a86c2841eb13 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 26 Jan 2012 19:53:07 +0000 Subject: [PATCH 062/178] [DOC] Align the media output component formal definition and schema --- extensions/inbox/rayo.xml | 329 +++++++++++++++++++------------------- 1 file changed, 166 insertions(+), 163 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index c8039473..1c33eb4a 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -758,133 +758,136 @@

      An output component is used to instruct the server to generate audible output to a call or mixer.

      -

      The output element MUST contain a single CDATA entitiy containing the SSML document to render.

      -

      The attributes of the output element are as follows.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      AttributeDefinitionPossible ValuesDefaultInclusion
      interrupt-onThe type of media input to allow interrupting the output.any|dtmf|speech|nonenoneOPTIONAL
      start-offsetA positive integer in ms.0OPTIONAL
      start-pausedWether or not to start the output in the paused state, ready to be resumed.true|falsefalseOPTIONAL
      repeat-intervalThe amount of time to wait between successive repetitions of the document.A positive integer in ms.0OPTIONAL
      repeat-timesThe number of times to produce the requested output before considering it to be complete.A positive integer.1OPTIONAL
      max-timeThe maximum time the output should be allowed to run for before being force-terminated.A positive integer in ms.-1OPTIONAL
      voiceThe voice with which to speak the requested document.Any voice supported by the TTS engine.allisonOPTIONAL
      - -

      The input component supports the component Stop command, along with the following.

      - -

      Instructs the server to pause the media output, but not terminate the component.

      -

      The pause element MUST be empty.

      -

      The pause element has no attributes.

      -       - -

      Instructs the server to resume a paused output.

      -

      The resume element MUST be empty.

      -

      The resume element has no attributes.

      -       - -

      Instructs the server to increase the speed by a unit amount.

      -

      The speed-up element MUST be empty.

      -

      The speed-up element has no attributes.

      -       - -

      Instructs the server to reduce the speed by a unit amount.

      -

      The speed-down element MUST be empty.

      -

      The speed-down element has no attributes.

      -       - -

      Instructs the server to increase the volume by a unit amount.

      -

      The volume-up element MUST be empty.

      -

      The volume-up element has no attributes.

      -       - -

      Instructs the server to reduce the volume by a unit amount.

      -

      The volume-down element MUST be empty.

      -

      The volume-down element has no attributes.

      -       - -

      Instructs the server to move the play marker of the output forward or back in time before resuming output.

      -

      The seek element MUST be empty.

      -

      The attributes of the seek element are as follows.

      - - - - - - - - - - - - - - - - - - - -
      AttributeDefinitionPossible ValuesInclusion
      directionThe direction in time in which to move the current play marker.forward|backREQUIRED
      amountA time value by which to move the play marker, in millisecondsA positive integer, in ms.REQUIRED
      + + +

      Instructs the server to begin an output component executing on the target call or mixer with the specified document and parameters.

      +

      The output element MUST contain one or more document elements.

      +

      The attributes of the output element are as follows.

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      AttributeDefinitionPossible ValuesDefaultInclusion
      start-offsetIndicates some offset through which the output should be skipped before rendering begins.A positive integer in ms.0OPTIONAL
      start-pausedIndicates wether or not the component should be started in a paused state to be resumed at a later time.true|falsefalseOPTIONAL
      repeat-intervalIndicates the duration of silence that should space repeats of the rendered document.A positive integer in ms.0OPTIONAL
      repeat-timesIndicates the number of times the output should be played.An integer greater than 0.1OPTIONAL
      max-timeIndicates the maximum amount of time for which the output should be allowed to run before being terminated. Includes repeats.A positive integer in ms or -1 to disable.-1OPTIONAL
      + + +

      Instructs the server to cease rendering output at the current marker and permit resumption from the same point.

      +

      The document element MUST contain a document for output rendering enclosed within CDATA.

      +

      The document element has no attributes.

             - - -

      The complete element MUST contain a valid completion reason element. Possible completion reasons are as follows, in addition to the standard component completion reasons.

      - -

      Indicates that the output was completed successfully.

      -

      The nomatch element MUST be empty.

      -

      The nomatch element has no attributes.

      -       -       + + +

      Instructs the server to continue rendering the output from the last pause marker.

      +

      Instructs the server to pause the media output, but not terminate the component.

      +

      The pause element MUST be empty.

      +

      The pause element has no attributes.

      +       + + +

      Instructs the server to resume a paused output.

      +

      The resume element MUST be empty.

      +

      The resume element has no attributes.

      +       + + +

      Instructs the server to increase the rate of output by a unit amount.

      +

      The speed-up element MUST be empty.

      +

      The speed-up element has no attributes.

      +       + + +

      Instructs the server to decrease the rate of output by a unit amount.

      +

      The speed-down element MUST be empty.

      +

      The speed-down element has no attributes.

      +       + + +

      Instructs the server to increase the volume of output by a unit amount.

      +

      The volume-up element MUST be empty.

      +

      The volume-up element has no attributes.

      +       + + +

      Instructs the server to decrease the volume of output by a unit amount.

      +

      The volume-down element MUST be empty.

      +

      The volume-down element has no attributes.

      +       + + +

      Instructs the server to move the play marker of the output forward or back in time before resuming output.

      +

      The seek element MUST be empty.

      +

      The attributes of the seek element are as follows.

      + + + + + + + + + + + + + + + + + + + +
      AttributeDefinitionPossible ValuesInclusion
      directionIndicates the direction in time in which to move the play marker.forward|backREQUIRED
      amountIndicates the duration by which to move the play marker.A positive integer, in ms.REQUIRED
      +       + + +

      Indicates that the output component came to an end as a result of reaching the end of the document to be rendered.

      +

      The finish element MUST be empty.

      +

      The finish element has no attributes.

      +       + + +

      Indicates that the output component came to an end due to the maximum time limit being reached.

      +

      The max-time element MUST be empty.

      +

      The max-time element has no attributes.

             @@ -1796,7 +1799,7 @@ - Indicates wether or not the component should be started in a paused state to be resumed at a later point. + Indicates wether or not the component should be started in a paused state to be resumed at a later time. @@ -1826,7 +1829,7 @@ - An SSML document for rendering (contained within CDATA). + An document for rendering (contained within CDATA). @@ -1852,42 +1855,6 @@ - - - - - Instructs the server to instantly proceed by a specified amount through the rendered document without producing output. - - - - - - - Indicates the direction in which the play marker should be moved through the rendered audio. - - - - - - - - - - - - - Indicates the duration of audio to skip through. - - - - - - - - - - - @@ -1924,6 +1891,42 @@ + + + + + Instructs the server to move the play marker of the output forward or back in time before resuming output. + + + + + + + Indicates the direction in time in which to move the play marker. + + + + + + + + + + + + + Indicates the duration by which to move the play marker. + + + + + + + + + + + ]]>       From b0258f1c7e90a4d2e98dc03611b3b422e3e90140 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 11:36:39 +0000 Subject: [PATCH 063/178] [DOC] Align the media input component formal definition and schema --- extensions/inbox/rayo.xml | 371 +++++++++++++++++++------------------- 1 file changed, 184 insertions(+), 187 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1c33eb4a..2ebeaca3 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -893,90 +893,10 @@

      An input component is used to instruct the server to gather media input from a call or mixer, using either DTMF or ASR.

      -

      The input element MUST contain one or more grammar elements (for which see Grammar Element).

      -

      The attributes of the input element are as follows.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      AttributeDefinitionPossible ValuesDefaultInclusion
      modeThe method by which to collect input.any|dtmf|speechanyOPTIONAL
      hotword-timeoutThe amount of time for which to discard invalid input, awaiting a match.A positive integer in ms, or -1 to disable.-1OPTIONAL
      partial-matchWether or not the component should trigger match events whenever a partial match is detected.true|falsefalseOPTIONAL
      terminatorThe terminator digit by which to force completion of the grammar.0-9,#,*noneOPTIONAL
      recognizerAny valid ISO 639‑3 language codeen-USOPTIONAL
      initial-timeoutThe timeout to be applied before the first digit is captured in the case of DTMF input, or before the beginning of an utterance is detected.Any positive integer in miliseconds, or -1 for no timeout.-1OPTIONAL
      inter-digit-timeoutThe timeout to be applied between the first and subsequent captured digits.Any positive integer in miliseconds, or -1 for no timeout.-1OPTIONAL
      sensitivityA decimal value between 0 and 1.OPTIONAL
      min-confidenceA decimal value between 0 and 1.OPTIONAL
      max-silenceThe maximum period of silence permitted before a timeout is triggered.Any positive integer in miliseconds, or -1 for no timeout.-1OPTIONAL
      - -

      The grammar element defines the grammar by which input should be matched.

      -

      The grammar element MUST have either a url attribute set OR a content type and a body.

      + + +

      Instructs the server to begin an input detector of the specified mode, with certain attributes, governed by the rules provided in one or more grammar documents.

      +

      The input element MUST contain one or more grammar elements.

      The attributes of the input element are as follows.

      @@ -987,89 +907,166 @@ - - - - - + + + + + - - - + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Inclusion
      urlA URL to a grammar definition.Any valid URI scheme supported by the server (eg HTTP).noneREQUIRED unless content-type and content are setmodeThe method by which to collect input.any|dtmf|speechanyOPTIONAL
      content-typeThe content type of the grammar contained within the grammar element.application/grammar+voxeo|application/grammar+grxmlterminatorIndicates a terminator token which, when encountered, should cause the input detection to cease.A token string noneREQUIRED unless url is setOPTIONAL
      recognizerIndicates the name of the particular input processor to be engaged. Usually only applies to speech input, in order to specify the recognition language.Any valid ISO 639‑3 language codeen-USOPTIONAL
      initial-timeoutIndicates the amount of time preceding input which may expire before a timeout is triggered.Any positive integer in miliseconds, or -1 to disable.-1OPTIONAL
      inter-digit-timeoutIndicates (in the case of DTMF input) the amount of time between input digits which may expire before a timeout is triggered.Any positive integer in miliseconds, or -1 to disable.-1OPTIONAL
      sensitivityIndicates how sensitive the interpreter should be to loud versus quiet input. Higher values represent greater sensitivity.A decimal value between 0 and 1.0.5OPTIONAL
      min-confidenceIndicates the confidence threshold, below which a match is to be considered unreliable.A decimal value between 0 and 1.0OPTIONAL
      max-silenceIndicates the maximum period of silence which may be encountered during input gathering before a timeout is triggered.Any positive integer in miliseconds, or -1 to disable.-1OPTIONAL
      -       - -

      The input component supports only the component Stop command.

      -       - - -

      Indicates that the input received triggered a match with the specified grammar, and provides results. This constitutes a partial match, and does not signal the end of the grammar.

      -

      The match element MUST contain valid interpretation and utterance elements.

      -

      The attributes of the match element are as follows.

      - + + +

      Provides the grammar document by which the input detection should be governed.

      +

      The grammar element MUST have either a url attribute set OR a content type and a body.

      +

      The attributes of the input element are as follows.

      +
      + - - - - + + + + + - - - - + + + + +
      Attribute Definition Possible ValuesDefault Inclusion
      modeThe method by which detection occurred.speech|dtmfREQUIREDurlProvides a URI at which the grammar document is available.Any valid URI scheme supported by the server (eg HTTP).noneREQUIRED unless content-type and content are set
      confidenceThe confidence with which the interpretation matches the utteranceA decimal value between 0 and 1.REQUIREDcontent-typeIndicates the content type of the grammar document provided as CDATA.A grammar content type tokenapplication/grammar+grxmlREQUIRED unless url is set
      - -

      The complete element MUST contain a valid completion reason element. Possible completion reasons are as follows, in addition to the standard component completion reasons.

      - -

      Indicates that the input received matches the specified grammar, and provides results.

      -

      The success element MUST contain valid interpretation and utterance elements.

      -

      The attributes of the success element are as follows.

      - - - - - - - - - - - - - - - - - - - -
      AttributeDefinitionPossible ValuesInclusion
      modeThe method by which detection occurred.speech|dtmfREQUIRED
      confidenceThe confidence with which the interpretation matches the utteranceA decimal value between 0 and 1.REQUIRED
      -       - -

      Indicates that the input received did not match the specified grammar.

      -

      The nomatch element MUST be empty.

      -

      The nomatch element has no attributes.

      -       - -

      Indicates that the component did not receive any input.

      -

      The noinput element MUST be empty.

      -

      The noinput element has no attributes.

      -       +       + + +

      Provides the result of a match between the input received and the specified grammar.

      +

      The match element MUST contain valid interpretation and utterance elements.

      +

      The attributes of the match element are as follows.

      + + + + + + + + + + + + + + + + + + + +
      AttributeDefinitionPossible ValuesInclusion
      modeIndicates the mode by which the match occurred.speech|dtmfREQUIRED
      confidenceIndicates the confidence with which the match has been made.A decimal value between 0 and 1.REQUIRED
      + + +

      Provides the result of the grammar match after any symantic processing which may have been performed.

      +

      The interpretation element SHOULD contain an interpretation as CDATA.

      +

      The interpretation element has no attributes.

      +       + + +

      Provides the raw string of the detected input.

      +

      The utterance element SHOULD contain an utterance as textual content.

      +

      The utterance element has no attributes.

             + + +

      Indicates that the component came to an end due to one of its grammars matching the received input.

      +

      The finish element MUST contain a valid match element.

      +

      The finish element has no attributes.

      +       + + +

      Indicates that the component came to an end because the initial timeout was triggered.

      +

      The initial-timeout element MUST be empty.

      +

      The initial-timeout element has no attributes.

      +       + + +

      Indicates that the component came to an end because the inter-digit timeout was triggered.

      +

      The inter-digit-timeout element MUST be empty.

      +

      The inter-digit-timeout element has no attributes.

      +       + + +

      Indicates that the component came to an end because the max-silence timeout was triggered.

      +

      The max-silence element MUST be empty.

      +

      The max-silence element has no attributes.

      +       + + +

      Indicates that the component came to an end because the minimum confidence threshold was not reached.

      +

      The min-confidence element MUST be empty.

      +

      The min-confidence element has no attributes.

      +       + + +

      Indicates that the component came to an end because input was received which did not match any of the specified grammars.

      +

      The nomatch element MUST be empty.

      +

      The nomatch element has no attributes.

      +       @@ -2014,7 +2011,7 @@ - Indicates the particular variety of input detector to be started. + The method by which to collect input. @@ -2106,6 +2103,44 @@ + + + + + + Indicates the mode by which the match occurred. + + + + + + + + + + + + + Indicates the confidence with which the match has been made. + + + + + + + Provides the result of the grammar match after any symantic processing which may have been performed. + + + + + + + Provides the raw string of the detected input. + + + + + @@ -2163,44 +2198,6 @@ - - - - - - Indicates the mode by which the match occurred. - - - - - - - - - - - - - Indicates the confidence with which the match has been made. - - - - - - - Provides the result of the grammar match after any symantic processing which may have been performed. - - - - - - - Provides the raw string of the detected input. - - - - - ]]> From 48713cd161020dc0fea6696cdf7863abfcc529a7 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 12:00:56 +0000 Subject: [PATCH 064/178] [DOC] Add formal definition for the record component --- extensions/inbox/rayo.xml | 198 +++++++++++++++++++++++++++++++++----- 1 file changed, 172 insertions(+), 26 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2ebeaca3..7caa65ac 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1068,6 +1068,152 @@

      The nomatch element has no attributes.

      + + +

      A record component is used to instruct the server to record audible or visual media for temporary or permanent storage.

      + + +

      Instructs the server to begin recording input to the call to a file.

      +

      The record element MAY contain one or more hint elements.

      +

      The attributes of the record element are as follows.

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      AttributeDefinitionPossible ValuesDefaultInclusion
      formatFile format used during recording.A valid format token, such as 'mp3', 'wav', 'h264'. Implementation specific.mp3OPTIONAL
      start-beepIndicates whether subsequent record will be preceded with a beep.true|falsefalseOPTIONAL
      start-pausedWhether subsequent record will start in PAUSE mode.true|falsefalseOPTIONAL
      max-durationIndicates the maximum duration for the recording.Any positive integer in miliseconds, or -1 to disable.-1OPTIONAL
      initial-timeoutControls how long the recognizer should wait after the end of the prompt for the caller to speak before sending a Recorder event.Any positive integer in miliseconds, or -1 to disable.-1OPTIONAL
      final-timeoutControls the length of a period of silence after callers have spoken to conclude they finished.Any positive integer in miliseconds, or -1 to disable.-1OPTIONAL
      + + +

      Optional format-specific encoding hint

      +

      The hint element MUST be empty.

      +

      The attributes of the hint element are as follows.

      + + + + + + + + + + + + + + + + +
      AttributeDefinitionInclusion
      nameThe name of the hint value as expected by the recorder.REQUIRED
      valueThe value of the hint provided.REQUIRED
      +       +       + + +

      Instructs the server to cease recording input but to leave the destination open for appending to permit resumption from the same point.

      +

      The pause element MUST be empty.

      +

      The pause element has no attributes.

      +       + + +

      Instructs the server to continue recording input, appending to the same destination.

      +

      The resume element MUST be empty.

      +

      The resume element has no attributes.

      +       + + +

      Provides the result of a recording, as a reference to its location.

      +

      The recording element MUST be empty.

      +

      The attributes of the recording element are as follows.

      + + + + + + + + + + + + + + + + + + + + + + + + + +
      AttributeDefinitionPossible ValuesInclusion
      uriIndicates the URI at which the recording is made available.A valid URIREQUIRED
      durationIndicates the duration of the completed recording.A positive integer in milliseconds.REQUIRED
      sizeIndicates the filesize of the completed recording.A positive integer in bytes.REQUIRED
      +       + + +

      Indicates that the component came to an end due to the max duration being reached.

      +

      The max-duration element MUST contain a valid recording element.

      +

      The max-duration element has no attributes.

      +       + + +

      Indicates that the component came to an end due to no input being detected before the initial-timeout.

      +

      The initial-timeout element MUST contain a valid recording element.

      +

      The initial-timeout element has no attributes.

      +       + + +

      Indicates that the component came to an end because no input had been detected for the final timeout duration.

      +

      The final-timeout element MUST contain a valid recording element.

      +

      The final-timeout element has no attributes.

      +       +       @@ -2331,6 +2477,31 @@ + + + + + + Indicates the URI at which the recording is made available. + + + + + + + Indicates the duration of the completed recording. + + + + + + + Indicates the filesize (in bytes) of the completed recording. + + + + + @@ -2347,7 +2518,7 @@ - Indicates that the component came to an end due to no input being detected before the initial-timeout + Indicates that the component came to an end due to no input being detected before the initial-timeout. @@ -2367,31 +2538,6 @@ - - - - - - Indicates the URI at which the recording is made available. - - - - - - - Indicates the duration of the completed recording. - - - - - - - Indicates the filesize (in bytes) of the completed recording. - - - - - ]]> From ff353e58174ec105496cfa1d2259eb31b16117bb Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 12:01:25 +0000 Subject: [PATCH 065/178] [BUGFIX] Typos --- extensions/inbox/rayo.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 7caa65ac..022a5eeb 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -964,11 +964,11 @@ - +

      Provides the grammar document by which the input detection should be governed.

      The grammar element MUST have either a url attribute set OR a content type and a body.

      -

      The attributes of the input element are as follows.

      - +

      The attributes of the grammar element are as follows.

      +
      From bf897563c45bfa85bd782fc2b38721debdd05088 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 12:21:52 +0000 Subject: [PATCH 066/178] [FORMATTING] Refer to all elements as in the formal definition --- extensions/inbox/rayo.xml | 200 +++++++++++++++++++------------------- 1 file changed, 100 insertions(+), 100 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 022a5eeb..ef18efac 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -367,8 +367,8 @@ -

      The header element MUST be empty.

      -

      The attributes of the header element are as follows.

      +

      The <header/> element MUST be empty.

      +

      The attributes of the <header/> element are as follows.

      Attribute Definition
      @@ -390,8 +390,8 @@

      Informs the recipient that a new call is available for control and invites it to take control using progress commands below.

      -

      The offer element MAY contain one or more header elements.

      -

      The attributes of the offer element are as follows.

      +

      The <offer/> element MAY contain one or more <header/> elements.

      +

      The attributes of the <offer/> element are as follows.

      Attribute
      @@ -413,20 +413,20 @@

      Indication that an outbound call has begun ringing, or accepted by the remote party.

      -

      The ringing element MAY contain one or more header elements.

      -

      The ringing element has no attributes.

      +

      The <ringing/> element MAY contain one or more <header/> elements.

      +

      The <ringing/> element has no attributes.

      Indication that an outbound call has been answered and that the 3rd party negotiation has completed. At this point, the media stream should be open.

      -

      The answered element MAY contain one or more header elements.

      -

      The answered element has no attributes.

      +

      The <answered/> element MAY contain one or more <header/> elements.

      +

      The <answered/> element has no attributes.

      Indication that the call has come to an end, giving the reason.

      -

      The end element MUST contain a single end reason element (for which see End Reason Element). It MAY also contain one or more header elements.

      -

      The end element has no attributes.

      +

      The <end/> element MUST contain a single end reason element. It MAY also contain one or more <header/> elements.

      +

      The <end/> element has no attributes.

      The following are valid end reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

      @@ -458,20 +458,20 @@

      Instructs the server to send notification to the calling party that the call will be dealt with and that ringing may begin.

      -

      The accept element MAY contain one or more header elements.

      -

      The accept element has no attributes.

      +

      The <accept/> element MAY contain one or more <header/> elements.

      +

      The <accept/> element has no attributes.

      Instructs the server to pick up an incoming call and connect the media stream.

      -

      The answer element MAY contain one or more header elements.

      -

      The answer element has no attributes.

      +

      The <answer/> element MAY contain one or more <header/> elements.

      +

      The <answer/> element has no attributes.

      Instructs the calling party that the call will not be accepted and that instead it should try to call the URI indicated in the command.

      -

      The redirect element MAY contain one or more header elements.

      -

      The attributes of the redirect element are as follows.

      +

      The <redirect/> element MAY contain one or more <header/> elements.

      +

      The attributes of the <redirect/> element are as follows.

      Attribute
      @@ -488,8 +488,8 @@

      Instructs the server to reject the call with a given reason.

      -

      The reject element MUST contain a single reject reason element (for which see Reject Reason Element). It MAY also contain one or more header elements.

      -

      The reject element has no attributes.

      +

      The <reject/> element MUST contain a single reject reason element. It MAY also contain one or more <header/> elements.

      +

      The <reject/> element has no attributes.

      The following are valid reject reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

      @@ -513,14 +513,14 @@

      Instructs the server to bring the call to an end naturally.

      -

      The hangup element MAY contain one or more header elements.

      -

      The hangup element has no attributes.

      +

      The <hangup/> element MAY contain one or more <header/> elements.

      +

      The <hangup/> element has no attributes.

      Instructs the server to create a new call and surrender control of it to the requesting party.

      -

      The dial element MAY contain one or more header elements. It MAY contain one or more join elements, instructing the server to join the new call in the indicated manner rather than the default (join to the local media server).

      -

      The attributes of the dial element are as follows.

      +

      The <dial/> element MAY contain one or more <header/> elements. It MAY contain one or more <join/> elements, instructing the server to join the new call in the indicated manner rather than the default (join to the local media server).

      +

      The attributes of the <dial/> element are as follows.

      Attribute
      @@ -551,8 +551,8 @@

      Instructs the server to join the media streams of the call and the specified party, given direction and media negotiation parameters.

      -

      The join element MUST be empty.

      -

      The attributes of the join element are as follows.

      +

      The <join/> element MUST be empty.

      +

      The attributes of the <join/> element are as follows.

      Attribute
      @@ -602,8 +602,8 @@

      Instructs the server to unjoin the media streams of the call and the specified party.

      -

      The unjoin element MUST be empty.

      -

      The attributes of the unjoin element are as follows.

      +

      The <unjoin/> element MUST be empty.

      +

      The attributes of the <unjoin/> element are as follows.

      Attribute
      @@ -625,8 +625,8 @@

      Indicates that the call was successfully joined to the specified party.

      -

      The joined element MUST be empty.

      -

      The attributes of the joined element are as follows.

      +

      The <joined/> element MUST be empty.

      +

      The attributes of the <joined/> element are as follows.

      Attribute
      @@ -648,8 +648,8 @@

      Indicates that the call ceased to be joined to the specified party.

      -

      The unjoined element MUST be empty.

      -

      The attributes of the unjoined element are as follows.

      +

      The <unjoined/> element MUST be empty.

      +

      The attributes of the <unjoined/> element are as follows.

      Attribute
      @@ -671,8 +671,8 @@

      Indicates that a call joined to a mixer with which the controlling party has an events subscription has activated a speech detector, providing its ID.

      -

      The started-speaking element MUST be empty.

      -

      The attributes of the started-speaking element are as follows.

      +

      The <started-speaking/> element MUST be empty.

      +

      The attributes of the <started-speaking/> element are as follows.

      Attribute
      @@ -689,8 +689,8 @@

      Indicates that a call joined to a mixer with which the controlling party has an events subscription has ceased activation of a speech detector, providing its ID.

      -

      The stopped-speaking element MUST be empty.

      -

      The attributes of the stopped-speaking element are as follows.

      +

      The <stopped-speaking/> element MUST be empty.

      +

      The attributes of the <stopped-speaking/> element are as follows.

      Attribute
      @@ -707,8 +707,8 @@

      Used to give an indication of the identity of a newly created resource, either a call or a component.

      -

      The ref element MUST be empty.

      -

      The attributes of the ref element are as follows.

      +

      The <ref/> element MUST be empty.

      +

      The attributes of the <ref/> element are as follows.

      Attribute
      @@ -727,14 +727,14 @@

      Instructs a component to come to an end before it completes naturally.

      -

      The stop element MUST be empty.

      -

      The stop element has no attributes.

      +

      The <stop/> element MUST be empty.

      +

      The <stop/> element has no attributes.

      Indicates that the component has come to an end and no further processing will occurr. Gives the reason for the termination.

      -

      The complete element MUST contain exactly one child element, indicating the reason for the complete event being raised. The reason may be a core complete reason or a reason specific to a particular component.

      -

      The complete element has no attributes.

      +

      The <complete/> element MUST contain exactly one child element, indicating the reason for the complete event being raised. The reason may be a core complete reason or a reason specific to a particular component.

      +

      The <complete/> element has no attributes.

      The following are valid complete reason elements. They all MAY contain further component-specific metadata elements, but they do not have any attributes.

      @@ -761,8 +761,8 @@

      Instructs the server to begin an output component executing on the target call or mixer with the specified document and parameters.

      -

      The output element MUST contain one or more document elements.

      -

      The attributes of the output element are as follows.

      +

      The <output/> element MUST contain one or more <document/> elements.

      +

      The attributes of the <output/> element are as follows.

      Attribute
      @@ -810,52 +810,52 @@

      Instructs the server to cease rendering output at the current marker and permit resumption from the same point.

      -

      The document element MUST contain a document for output rendering enclosed within CDATA.

      -

      The document element has no attributes.

      +

      The <document/> element MUST contain a document for output rendering enclosed within CDATA.

      +

      The <document/> element has no attributes.

      Instructs the server to continue rendering the output from the last pause marker.

      Instructs the server to pause the media output, but not terminate the component.

      -

      The pause element MUST be empty.

      -

      The pause element has no attributes.

      +

      The <pause/> element MUST be empty.

      +

      The <pause/> element has no attributes.

      Instructs the server to resume a paused output.

      -

      The resume element MUST be empty.

      -

      The resume element has no attributes.

      +

      The <resume/> element MUST be empty.

      +

      The <resume/> element has no attributes.

      Instructs the server to increase the rate of output by a unit amount.

      -

      The speed-up element MUST be empty.

      -

      The speed-up element has no attributes.

      +

      The <speed-up/> element MUST be empty.

      +

      The <speed-up/> element has no attributes.

      Instructs the server to decrease the rate of output by a unit amount.

      -

      The speed-down element MUST be empty.

      -

      The speed-down element has no attributes.

      +

      The <speed-down/> element MUST be empty.

      +

      The <speed-down/> element has no attributes.

      Instructs the server to increase the volume of output by a unit amount.

      -

      The volume-up element MUST be empty.

      -

      The volume-up element has no attributes.

      +

      The <volume-up/> element MUST be empty.

      +

      The <volume-up/> element has no attributes.

      Instructs the server to decrease the volume of output by a unit amount.

      -

      The volume-down element MUST be empty.

      -

      The volume-down element has no attributes.

      +

      The <volume-down/> element MUST be empty.

      +

      The <volume-down/> element has no attributes.

      Instructs the server to move the play marker of the output forward or back in time before resuming output.

      -

      The seek element MUST be empty.

      -

      The attributes of the seek element are as follows.

      +

      The <seek/> element MUST be empty.

      +

      The attributes of the <seek/> element are as follows.

      Attribute
      @@ -880,14 +880,14 @@

      Indicates that the output component came to an end as a result of reaching the end of the document to be rendered.

      -

      The finish element MUST be empty.

      -

      The finish element has no attributes.

      +

      The <finish/> element MUST be empty.

      +

      The <finish/> element has no attributes.

      Indicates that the output component came to an end due to the maximum time limit being reached.

      -

      The max-time element MUST be empty.

      -

      The max-time element has no attributes.

      +

      The <max-time/> element MUST be empty.

      +

      The <max-time/> element has no attributes.

       @@ -896,8 +896,8 @@

      Instructs the server to begin an input detector of the specified mode, with certain attributes, governed by the rules provided in one or more grammar documents.

      -

      The input element MUST contain one or more grammar elements.

      -

      The attributes of the input element are as follows.

      +

      The <input/> element MUST contain one or more <grammar/> elements.

      +

      The attributes of the <input/> element are as follows.

      Attribute
      @@ -966,8 +966,8 @@

      Provides the grammar document by which the input detection should be governed.

      -

      The grammar element MUST have either a url attribute set OR a content type and a body.

      -

      The attributes of the grammar element are as follows.

      +

      The <grammar/> element MUST have either a url attribute set OR a content type and a body.

      +

      The attributes of the <grammar/> element are as follows.

      Attribute
      @@ -996,8 +996,8 @@

      Provides the result of a match between the input received and the specified grammar.

      -

      The match element MUST contain valid interpretation and utterance elements.

      -

      The attributes of the match element are as follows.

      +

      The <match/> element MUST contain valid <interpretation/> and <utterance/> elements.

      +

      The attributes of the <match/> element are as follows.

      Attribute
      @@ -1021,51 +1021,51 @@

      Provides the result of the grammar match after any symantic processing which may have been performed.

      -

      The interpretation element SHOULD contain an interpretation as CDATA.

      -

      The interpretation element has no attributes.

      +

      The <interpretation/> element SHOULD contain an interpretation as CDATA.

      +

      The <interpretation/> element has no attributes.

      Provides the raw string of the detected input.

      -

      The utterance element SHOULD contain an utterance as textual content.

      -

      The utterance element has no attributes.

      +

      The <utterance/> element SHOULD contain an utterance as textual content.

      +

      The <utterance/> element has no attributes.

      Indicates that the component came to an end due to one of its grammars matching the received input.

      -

      The finish element MUST contain a valid match element.

      -

      The finish element has no attributes.

      +

      The <finish/> element MUST contain a valid match element.

      +

      The <finish/> element has no attributes.

      Indicates that the component came to an end because the initial timeout was triggered.

      -

      The initial-timeout element MUST be empty.

      -

      The initial-timeout element has no attributes.

      +

      The <initial-timeout/> element MUST be empty.

      +

      The <initial-timeout/> element has no attributes.

      Indicates that the component came to an end because the inter-digit timeout was triggered.

      -

      The inter-digit-timeout element MUST be empty.

      -

      The inter-digit-timeout element has no attributes.

      +

      The <inter-digit-timeout/> element MUST be empty.

      +

      The <inter-digit-timeout/> element has no attributes.

      Indicates that the component came to an end because the max-silence timeout was triggered.

      -

      The max-silence element MUST be empty.

      -

      The max-silence element has no attributes.

      +

      The <max-silence/> element MUST be empty.

      +

      The <max-silence/> element has no attributes.

      Indicates that the component came to an end because the minimum confidence threshold was not reached.

      -

      The min-confidence element MUST be empty.

      -

      The min-confidence element has no attributes.

      +

      The <min-confidence/> element MUST be empty.

      +

      The <min-confidence/> element has no attributes.

      Indicates that the component came to an end because input was received which did not match any of the specified grammars.

      -

      The nomatch element MUST be empty.

      -

      The nomatch element has no attributes.

      +

      The <nomatch/> element MUST be empty.

      +

      The <nomatch/> element has no attributes.

       @@ -1074,8 +1074,8 @@

      Instructs the server to begin recording input to the call to a file.

      -

      The record element MAY contain one or more hint elements.

      -

      The attributes of the record element are as follows.

      +

      The <record/> element MAY contain one or more <hint/> elements.

      +

      The attributes of the <record/> element are as follows.

      Attribute
      @@ -1130,8 +1130,8 @@

      Optional format-specific encoding hint

      -

      The hint element MUST be empty.

      -

      The attributes of the hint element are as follows.

      +

      The <hint/> element MUST be empty.

      +

      The attributes of the <hint/> element are as follows.

      Attribute
      @@ -1154,20 +1154,20 @@

      Instructs the server to cease recording input but to leave the destination open for appending to permit resumption from the same point.

      -

      The pause element MUST be empty.

      -

      The pause element has no attributes.

      +

      The <pause/> element MUST be empty.

      +

      The <pause/> element has no attributes.

      Instructs the server to continue recording input, appending to the same destination.

      -

      The resume element MUST be empty.

      -

      The resume element has no attributes.

      +

      The <resume/> element MUST be empty.

      +

      The <resume/> element has no attributes.

      Provides the result of a recording, as a reference to its location.

      -

      The recording element MUST be empty.

      -

      The attributes of the recording element are as follows.

      +

      The <recording/> element MUST be empty.

      +

      The attributes of the <recording/> element are as follows.

      Attribute
      @@ -1198,20 +1198,20 @@

      Indicates that the component came to an end due to the max duration being reached.

      -

      The max-duration element MUST contain a valid recording element.

      -

      The max-duration element has no attributes.

      +

      The <max-duration/> element MUST contain a valid recording element.

      +

      The <max-duration/> element has no attributes.

      Indicates that the component came to an end due to no input being detected before the initial-timeout.

      -

      The initial-timeout element MUST contain a valid recording element.

      -

      The initial-timeout element has no attributes.

      +

      The <initial-timeout/> element MUST contain a valid recording element.

      +

      The <initial-timeout/> element has no attributes.

      Indicates that the component came to an end because no input had been detected for the final timeout duration.

      -

      The final-timeout element MUST contain a valid recording element.

      -

      The final-timeout element has no attributes.

      +

      The <final-timeout/> element MUST contain a valid recording element.

      +

      The <final-timeout/> element has no attributes.

       From 0dc3409fd32e6f2a4cea8d273ed62fc6b0b9a9c2 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 12:22:06 +0000 Subject: [PATCH 067/178] [BUGFIX] Fix some formal definition documentation --- extensions/inbox/rayo.xml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ef18efac..6bd3810d 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -809,21 +809,20 @@
      Attribute
      -

      Instructs the server to cease rendering output at the current marker and permit resumption from the same point.

      +

      Presents a document for rendering by the output engine.

      The <document/> element MUST contain a document for output rendering enclosed within CDATA.

      The <document/> element has no attributes.

       -

      Instructs the server to continue rendering the output from the last pause marker.

      Instructs the server to pause the media output, but not terminate the component.

      The <pause/> element MUST be empty.

      The <pause/> element has no attributes.

       -

      Instructs the server to resume a paused output.

      +

      Instructs the server to continue rendering the output from the last pause marker.

      The <resume/> element MUST be empty.

      The <resume/> element has no attributes.

       From 57585bef4a356ac314cc006336526b01fe4eb91a Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 12:30:22 +0000 Subject: [PATCH 068/178] [DOC] Introduce the features of rayo --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 6bd3810d..ee4dd4e1 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -182,7 +182,7 @@ ]]>       -

      +

      The protocol defined herein is designed to provide the following features:

      1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Evey attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
      2. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
        3. From 3d8bb8693e50d34ec47f5110ed2040ceeb956830 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Jan 2012 12:39:51 +0000 Subject: [PATCH 069/178] [DOC] Add session flow notes on client availability --- extensions/inbox/rayo.xml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ee4dd4e1..84955b37 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -342,6 +342,26 @@ +

        This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise.

        + + +

        In order for a Rayo client to be considered a potential controlling party for incoming sessions, it MUST first notify the Rayo server that it is available for the receipt of calls. This is done by sending directed presence to the Rayo server with a <show/> element containing 'chat' as in the example:

        + + chat + +]]> + +

        Conversely, when a Rayo client wishes not to be considered a potential controlling party, it SHOULD send directed presence to the Rayo server with a <show/> element containing 'dnd' as in the example:

        + + dnd + +]]> +         + From 8ef1ee7ee566e6d4a04406227bf5e7cc51bed8fb Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sat, 28 Jan 2012 16:36:20 +0000 Subject: [PATCH 070/178] [DOC] Add some comments as a template for the session flow section --- extensions/inbox/rayo.xml | 53 +++++++++++++++++++++++++++++++++++---- 1 file changed, 48 insertions(+), 5 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 84955b37..31846e99 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -364,24 +364,67 @@ - + - + - + - + - +         From e4901497db1b4d28e5bc34c63a2c80b6c257ce64 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sat, 14 Apr 2012 11:11:57 +0100 Subject: [PATCH 071/178] Session flow of basic outbound calls --- extensions/inbox/rayo.xml | 164 +++++++++++++++++++++++++++++++++++--- 1 file changed, 153 insertions(+), 11 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 31846e99..23d0c4ce 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -363,6 +363,159 @@ +

        Sessions may be established either at the request of the Rayo client (an outbound call) or as a result of a 3rd party request (an inbound call). Each scenario differs in the Rayo protocol only up to the point at which the session is established and media begins to flow. First we shall examine the sequence of stanzas passed between server and client in each of these scenarios.

        + + +

        In order for a client to establish a new outbound call, it MUST first send a dial command to the server, indicating the proposed target for the call, its apparent source, and any meta-data to send to the target as headers.

        + + + +
        +
        + + + ]]> + +

        On successfully receiving and parsing the dial command, the server SHOULD perform its own proprietary authorization measures to ensure that only desireable outbound sessions are created. If it is established that the command should not be allowed, the server MUST return an error giving an authorization reason.

        + + +

        There are several reasons why the server might immediately return an error instead of acknowledging the creation of a new call:

        +
          +
        • The client is unknown to the server and the server does not permit session creation by unknown clients.
          • +
        • The client is not authorized to create this new session.
          • +
        • The server does not support outbound calls.
          • +
        • The server does not have sufficient resources to create a new session.
          • +
        • The dial command was malformed.
          • +
        + +

        If the client is unknown to the server and the server does not permit session creation by unknown clients, the server MUST return a <registration-required/> error with a type of 'auth'.

        + + +
        +
        + + + + + + ]]> + +

        If the client is not authorized (as determined by an implementation/deployment-specific algorithm) to create a new outbound session given the parameters provided, the server MUST return a <not-authorized/> error with a type of 'auth'.

        + + +
        +
        + + + + + + ]]> + +

        If the server does not support outbound calls, the server MUST return a <feature-not-implemented/> error with a type of 'cancel'.

        + + +
        +
        + + + + + + ]]> + +

        If the server does not have sufficient resources to create a new session, the server MUST return a <resource-constraint/> error with a type of 'wait'.

        + + +
        +
        + + + + + + ]]> + +

        If the dial command was malformed, the server MUST return a <not-acceptable/> error with a type of 'modify'.

        + + +
        +
        + + + + + + ]]> + + +

        If the command is successfull and the call is queued, however, confirmation of such should be sent to the client, including a reference to the unique ID of the call. This call ID may be used to execute commands and filter events for the duration of the session.

        + + + + ]]> + +

        Once the server receives notification that the session has been accepted by the third party, it should send a ringing event to the client to indicate such:

        + + + + ]]> + +

        Similarly, once the server receives notification that the session has been answered and that media is flowing, it should send an answered event to the client to indicate such:

        + + + + ]]> + + + + - - - - From 29f0380b595b5ef686311fa6027f80965c1aa690 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 15 Apr 2012 18:05:42 +0100 Subject: [PATCH 072/178] Document incoming call procedure --- extensions/inbox/rayo.xml | 56 ++++++++++++++++++++++++++++----------- 1 file changed, 40 insertions(+), 16 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 23d0c4ce..c1dd418c 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -233,11 +233,11 @@
        Components extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/> event
        -
        Potential controlling party
        +
        Potential controlling party (PCP)
        An XMPP entity to which an offer to control an incoming call may be sent.
         -
        Difinitive controlling party
        +
        Difinitive controlling party (DCP)
        The XMPP entity which gains a lock on control of a session, either by requesting the session's creation, or being the first respondent to an offer.
      @@ -517,25 +517,49 @@       - +

      When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it MUST then remove any parties whom it can identify as being temporarily inappropropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available. If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

      + +

      If the server can identify active Potential Controlling Parties, it MUST offer them control of the call simultaneously. The server must broadcast an offer on behalf of the call to all Potential Controlling Parties, using applicable to/from/header data from the incoming session.

      + + +
      +
      + + + ]]> + +

      Once the server has offered control, it MUST wait indefinitely for a response from a PCP. The server SHOULD monitor the availability of PCPs to whom offers have been sent. If they all cease to be PCPs (eg by going offline) then the call should be rejected in the same way as if there had not been any available PCPs to begin with.

      + +

      If an offered PCP executes a command against the call, by sending a command node to the call's JID inside an IQ 'set', the server should execute the following routine:

      +
        +
      1. If the call does not have a DCP, set it to the PCP from which the command originated.
        2. +
      2. If the call has a DCP, and the command did not originate from the DCP, return a (INSERT ERROR TYPE HERE AND FIX EXAMPLE) error in response to the command of the following format: + + + + + + + ]]> + otherwise; +
        3. +
      3. If the command is an accept command, notify the remote calling party that the call has been accepted. Return an empty IQ result to the command issuing party to confirm successful execution.
        4. +
      4. If the command is an answer command, notify the remote calling party that the call has been answered and negotiate media between the calling party and the server's local media server. Return an empty IQ result to the command issuing party to confirm successful execution.
        5. +
      + +

      If a client can determine a more appropriate target for an incoming call, it may wish to relay this information to the caller in the form of a URI (eg SIP). The client MUST do this before accepting a call. The target URI must be specified in the 'to' attribute of the redirect element.

      + + +
      +
      + + + ]]> + +

      The server should send an appropriate redirection instruction to the underlying session.

      + +

      If the server is able to successfully relay the redirection to the calling party, it should send an empty IQ result to confirm the command has completed execution:

      + + ]]> + +

      If the server is unable to perform the redirect because the call has already been accepted, it should return a not-allowed (cancel) error indicating such:

      + + +
      +
      + + + + + + ]]> + + + +

      If a client cannot handle an incoming call, it SHOULD reject it. The client MUST do this before accepting the call. The target URI must be specified in the 'to' attribute of the redirect element.

      + + +
      + + + ]]> + +

      The server should reject the underlying session. If the server is able to do so successfully, it should send an empty IQ result to confirm the command has completed execution:

      + + ]]> + +

      If the server is unable to perform the rejection because the call has already been accepted, it should return a not-allowed (cancel) error indicating such:

      + + +
      + + + + + + ]]> + + + + + From 420f34eede8320ee6e6116315b3ee0094c0226fa Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 14:02:37 +0200 Subject: [PATCH 075/178] Add blurb to session termination section --- extensions/inbox/rayo.xml | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 13cd18cb..45a3bf8e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -585,6 +585,21 @@ +

      Session termination may occurr by one of several methods:

      +
        +
      • An inbound call may be redirected by a PCP to some other target.
        • +
      • An inbound call may be rejected by a PCP.
        • +
      • An inbound call may be rejected by the remote party.
        • +
      • An active call, whether inbound or outbound, may be hung up (gracefully ended) by a DCP.
        • +
      • An active call may be hung up (gracefully ended) by the remote party.
        • +
      + +

      A call end notification will be dispatched to the PCP if one of the following conditions is met:

      +
        +
      • The call has been accepted and has a PCP.
        • +
      • The call is outbound and implicitly has a PCP (the requesting party).
        • +
      +

      If a client can determine a more appropriate target for an incoming call, it may wish to relay this information to the caller in the form of a URI (eg SIP). The client MUST do this before accepting a call. The target URI must be specified in the 'to' attribute of the redirect element.

       + + + +       From 47fb91c82c9c1bedc9ef4f825521ba3c1bb3d276 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 14:04:42 +0200 Subject: [PATCH 076/178] Fix links since doesn't work --- extensions/inbox/rayo.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 45a3bf8e..57b971e9 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -587,14 +587,14 @@

      Session termination may occurr by one of several methods:

        -
      • An inbound call may be redirected by a PCP to some other target.
        • -
      • An inbound call may be rejected by a PCP.
        • +
      • An inbound call may be redirected by a PCP to some other target.
        • +
      • An inbound call may be rejected by a PCP.
      • An inbound call may be rejected by the remote party.
        • -
      • An active call, whether inbound or outbound, may be hung up (gracefully ended) by a DCP.
        • +
      • An active call, whether inbound or outbound, may be hung up (gracefully ended) by a DCP.
      • An active call may be hung up (gracefully ended) by the remote party.
      -

      A call end notification will be dispatched to the PCP if one of the following conditions is met:

      +

      A call end notification will be dispatched to the PCP if one of the following conditions is met:

      • The call has been accepted and has a PCP.
      • The call is outbound and implicitly has a PCP (the requesting party).
        • From 9c9b69ae12d6386f60d732a26160c85eacd2957b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 14:14:49 +0200 Subject: [PATCH 077/178] Typo and reordering --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 57b971e9..714f3a9c 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -589,9 +589,9 @@
        • An inbound call may be redirected by a PCP to some other target.
        • An inbound call may be rejected by a PCP.
          • -
        • An inbound call may be rejected by the remote party.
        • An active call, whether inbound or outbound, may be hung up (gracefully ended) by a DCP.
        • An active call may be hung up (gracefully ended) by the remote party.
          • +
        • An outbound call may be rejected by the remote party.

        A call end notification will be dispatched to the PCP if one of the following conditions is met:

        From 1dcb8eb69cb6090cfbbe88a3d9306ede76e9121c Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 14:28:17 +0200 Subject: [PATCH 078/178] Detail procedure for call hangup --- extensions/inbox/rayo.xml | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 714f3a9c..2083c85e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -681,10 +681,32 @@ - +

        If a client wishes to end a call it should send a hangup command to the call instructing it to do so:

        + + +
        + + + ]]> + +

        The server should queue the call for immediate hangup and return a response indicating success of the command:

        + + ]]> + +

        The server MUST follow this sequence to hang up a call:

        +
          +
        • Terminate all components of the call, and components MUST send an end event indicating hangup as the cause.
          • +
        • Terminate all joins on the call, sending unjoined events.
          • +
        • Terminate the underlying session.
          • +
        From 04e594e89f1b2263b483c1b915fae7a53d19fbb2 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 14:31:44 +0200 Subject: [PATCH 079/178] Typo --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2083c85e..208c60cb 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -703,7 +703,7 @@

        The server MUST follow this sequence to hang up a call:

          -
        • Terminate all components of the call, and components MUST send an end event indicating hangup as the cause.
          • +
        • Terminate all components of the call, and components MUST send a complete event indicating hangup as the cause.
        • Terminate all joins on the call, sending unjoined events.
        • Terminate the underlying session.
        From f6a5da45c14fd1aa624fb53f0f636ac209c9558f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 15:19:09 +0200 Subject: [PATCH 080/178] Document end event and behaviour on call termination. --- extensions/inbox/rayo.xml | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 208c60cb..0f594657 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -710,7 +710,43 @@         - +

        The server MUST monitor a call's underlying session and react appropriately in the case that it comes to an end:

        +
          +
        • The server MUST determine the reason for the call ending to be one of the appropriate end reasons.
          • +
        • If the call ending was not a result of a hangup command from a client, the server MUST terminate all components on the call, which MUST send a complete event indicating hangup as the cause. The server MUST additionally terminate all joins on the call, sending unjoined events.
          • +
        • The server MUST send an end event (of type unavailable) on behalf of the call, specifying the above determined reason as a child element, to all JIDs to which an offer was sent or from which a command was received.
          • +
        • The server MUST NOT send any more events from a call which has ended and declared itself unavailable.
          • +
        • The server MUST respond to any commands sent to an ended call (or one which never existed) with an item-not-found (cancel) error.
          • +
        + + + + + + + ]]> + + + + + + + + + + + + ]]>         From d661fef68e998389a92e38a64bec71aa414e7e34 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 15:31:32 +0200 Subject: [PATCH 081/178] Typo --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0f594657..34954f6b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1675,7 +1675,7 @@
      • urn:xmpp:rayo:ext:1
      • urn:xmpp:rayo:ext:complete:1
      • urn:xmpp:rayo:output:1
        • -
      • urn:xmpp:rayo:output:complete"1
        • +
      • urn:xmpp:rayo:output:complete:1
      • urn:xmpp:rayo:input:1
      • urn:xmpp:rayo:input:complete:1
      • urn:xmpp:rayo:record:1
        • From 2d17405c6a5730f52b31628a7bc31ca1590e7b29 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 15:31:44 +0200 Subject: [PATCH 082/178] Add notes on spec compliance and returning errors --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 34954f6b..cd6b86cc 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1650,7 +1650,7 @@

        Further commands and components may also be added to the Rayo protocol in order to extend its capabilities. Such extensions should be submitted to the XSF as ProtoXEPs and use namespaces aligning with the core component namespaces.

        - +

        A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions.

         From 6a163bcd67af56cdd11b73f652bcf5b64c758dfe Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 17:30:13 +0200 Subject: [PATCH 083/178] Begin to document generic component execution concerns --- extensions/inbox/rayo.xml | 117 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 113 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index cd6b86cc..c0b7c867 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -559,16 +559,125 @@ +

        Components are long-lived elements of a call or mixer which may execute in paralell, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

        + +

        In the event that a call or mixer receives a command which triggers the execution of a component, it MUST use the normal command handling routine, and schedule the component for immediate execution and return a reference to the requesting client as confirmation of the component's completion. Additionally, the component JID MUST send available presence to the executing party:

        + + + + + ]]> + + + + + + + ]]> + +

        If a component execution command is received prior to the call being answered, the server MUST implicitly answer the underlying session and negotiate media as if an answer command had been received before it begins processing the component.

        + +

        The whole command MUST be parsed up-front, and any applicable validation performed before acknowledgement of the command.

        + + +

        There are several reasons why the server might immediately return an error instead of acknowledging the creation of a new component:

        +
          +
        • The server does not implement the component/command.
          • +
        • The server does not implement a particular option value for the command/component.
          • +
        • Some aspect of the component/command does not comply with this specification.
          • +
        • The server does not have sufficient resources to create a new component on this call/mixer.
          • +
        • The component would cause a resource conflict with another component on this call/mixer.
          • +
        + +

        If the server does not implement the command/component, it should return a feature-not-implemented (cancel) error:

        + + + + + + + ]]> + +

        If the server does not implement a particular option value for the command/component, it should return a feature-not-implemented (modify) error:

        + + + + + + + ]]> + +

        If the command does not meet the specification, the server should return a bad-request (modify) error:

        + + + + + + + ]]> + +

        If the server does not have sufficient resources to create the component, it should return a resource-constraint (wait) error:

        + + + + + + + ]]> + +

        If the server is not able to create the component due to a resource conflict with another component, it should return a resource-constraint (wait) error:

        + + + + + + + ]]> + +         + +

        Once acknowleged, the component MUST begin execution according to its particular specification. During its execution, it MAY emit events relevant to its progress, and an implementation MUST be cabable of emitting events specified for each component. Any events should be sent inside a directed presence element to the executing party.

        + + + + +         From c0594c590e288a7db22022af22017d44c2340faa Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 18 Apr 2012 17:59:34 +0200 Subject: [PATCH 084/178] Correct section headers --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index c0b7c867..c823af9f 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -587,7 +587,7 @@

        The whole command MUST be parsed up-front, and any applicable validation performed before acknowledgement of the command.

        - +

        There are several reasons why the server might immediately return an error instead of acknowledging the creation of a new component:

        • The server does not implement the component/command.
          • @@ -664,7 +664,7 @@ ]]> - +

          Once acknowleged, the component MUST begin execution according to its particular specification. During its execution, it MAY emit events relevant to its progress, and an implementation MUST be cabable of emitting events specified for each component. Any events should be sent inside a directed presence element to the executing party.

          From ebf16409938fce50dc59191d57f2c8e671b290c9 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 10:10:18 +0200 Subject: [PATCH 085/178] Reject end reason should be 'rejected' Fixes #15 --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index c823af9f..414e148d 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -940,7 +940,7 @@
          Indication that the call ended due to being rejected by the remote party subsequent to being accepted.
          -
          <reject/>
          +
          <rejected/>
          Indication that the call ended due to being rejected by the remote party before being accepted.
           @@ -1929,7 +1929,7 @@ - + Indication that the call ended due to being rejected by the remote party before being accepted. From 69b6f722e017f79bb061e92e0c60a3c87576a1a0 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 11:21:55 +0200 Subject: [PATCH 086/178] Complete generic component specification --- extensions/inbox/rayo.xml | 129 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 123 insertions(+), 6 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 414e148d..446195bd 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -668,12 +668,129 @@

          Once acknowleged, the component MUST begin execution according to its particular specification. During its execution, it MAY emit events relevant to its progress, and an implementation MUST be cabable of emitting events specified for each component. Any events should be sent inside a directed presence element to the executing party.

          - +

          During execution, the component MUST respond to commands addressed to it. Each component has its own set of commands, but all components have the 'stop' command in common. On receipt of the stop command, the component MUST acknowledge that it has been instructed to stop and gracefully cease its execution in whatever way is appropriate to the particular component.

          + + + + + + + ]]> + + +

          There are several reasons why a component might return an error instead of acknowledging a command:

          +
            +
          • The component does not implement the command.
            • +
          • The component does not implement a particular option value for the command.
            • +
          • Some aspect of the command does not comply with the components specification.
            • +
          • The command is not appropriate for the component at its current stage of execution.
            • +
          • The command is issued by a party other than that which created the component.
            • +
          + +

          If the component does not implement the command, it should return a feature-not-implemented (cancel) error:

          + + + + + + + ]]> + +

          If the component does not implement a particular option/value for the command, it should return a feature-not-implemented (modify) error:

          + + + + + + + ]]> + +

          If some aspect of the command does not comply with the component's spec, it should return a bad-request (modify) error:

          + + + + + + + ]]> + +

          If the command is not appropriate for the component's current stage of execution, it should return a unexpected-request (wait) error:

          + + + + + + + ]]> + +

          If the command is issued by a party other than the component creator, it should return a conflict (cancel) error:

          + + + + + + + ]]> + +           + +

          When the component ceases to execute, it MUST send a complete event with a valid reason to the requesting party as directed presence with a type of 'unavailable'.

          + + + + + + ]]> + +

          Once a component is completed, or if it did not exist, the server should return an item-not-found (cancel) error:

          + + + + + + + + + + + ]]> From e55fe1178c04cf4c9ce2618eb71f852c717b14d4 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 11:26:21 +0200 Subject: [PATCH 087/178] Move joining section above component execution --- extensions/inbox/rayo.xml | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 446195bd..b8a81099 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -558,6 +558,19 @@ + + + +

          Components are long-lived elements of a call or mixer which may execute in paralell, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

          @@ -797,19 +810,6 @@           - - - -

          Session termination may occurr by one of several methods:

            From 1ebff8acc3976d5bc557c27ca26c44d13170a6ff Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 11:34:14 +0200 Subject: [PATCH 088/178] Specify nested join behaviour --- extensions/inbox/rayo.xml | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b8a81099..b5ec0237 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -503,7 +503,7 @@ ]]> -

            Similarly, once the server receives notification that the session has been answered and that media is flowing, it should send an answered event to the client to indicate such:

            +

            Similarly, once the server receives notification that the session has been answered, it should negotiate media between the dialed party and its local media server. Once media negotiation is complete, it should send an answered event to the client to indicate such:

            @@ -511,9 +511,23 @@ ]]> - + +

            When sending a dial request, a client MAY specify a join target within the dial element:

            + + + + + + ]]> + +

            In this case, the server MUST treat the session creation in the same way as without the join element, until the point of media negotiation. Here, the server should negotiate media as specified by the join element, in accordance with the rules defined in joining calls. Media MUST NOT be negotiated with the local media server, unless the join specifies so. The join operation MUST behave as described in joining calls.

            +             From 6cbfb088ea8696f19017f7906fe72c55f6580159 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 13:32:23 +0200 Subject: [PATCH 089/178] Define basic join/unjoin behaviour * Fixes 12 --- extensions/inbox/rayo.xml | 202 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 192 insertions(+), 10 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b5ec0237..0302a2ca 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -573,16 +573,198 @@ - +

            Calls in a Rayo system are capable of having their media streams moved/manipulated. Once such manipulation is to join the media streams of two calls. In a scenario where callA and callB should be joined, the client MUST send a join command to either call (not both) specifying the call ID of the other call, like so:

            + + + + ]]> + +

            The server MUST join the media streams of the two calls and return an empty IQ result to confirm that the operation has been successful. Additionally, both calls MUST dispatch joined events specifying who they have been joined to:

            + + + + + + + + + + ]]> + +

            By default, the server MUST join the calls by bridging their audio through its local media server, with bidirectional media. In order to specify alternative behaviour, the client MAY specify a media option (either 'bridge' or 'direct') and/or a direction option (either 'duplex', 'send' or 'recv'), and the server MUST bridge accordingly.

            + + +

            There are several reasons why the call might return an error instead of acknowledging a join:

            +
              +
            • The specified join party does not exist or cannot be found.
              • +
            • The server does not have sufficient resources to complete the join.
              • +
            • The join command was malformed.
              • +
            • The specified media/direction options or their combination are not possible/supported.
              • +
            + +

            If the specified join party does not exist or cannot be found, the server MUST return a <service-unavailable/> error with a type of 'cancel'.

            + + + + + + + ]]> + +

            If the server does not have sufficient resources to complete the join, the server MUST return a <resource-constraint/> error with a type of 'wait'.

            + + + + + + + ]]> + +

            If the join command was malformed (eg no call ID specified), the server MUST return a <bad-request/> error with a type of 'modify'.

            + + + + + + + ]]> + +

            If the specified media/direction options or their combination are not possible/supported, the server MUST return a <not-acceptable/> error with a type of 'modify'.

            + + + + + + + ]]> +             + + +

            When the client wishes to terminate an existing join, it MUST send an unjoin command specifying the join to break (call-id).

            + + + + ]]> + +

            The server MUST unjoin the media streams of the two calls, rejoin both to the media server and return an empty IQ result to confirm that the operation has been successful:

            + + ]]> + +

            Optionally, if no join is specified on the unjoin command, all existing joins must be broken:

            + + + + + + ]]> + + +

            There are several reasons why the call might return an error instead of acknowledging an unjoin command:

            +
              +
            • The specified join does not exist.
              • +
            • The unjoin command was malformed.
              • +
            + +

            If the specified join does not exist, the server MUST return a <service-unavailable/> error with a type of 'cancel'.

            + + + + + + + ]]> + +

            If the unjoin command was malformed (eg an empty call ID specified), the server MUST return a <bad-request/> error with a type of 'modify'.

            + + + + + + + ]]> +             +             + + +

            Calls may be unjoined from other calls either in response to an unjoin command, as the result of one of the calls disconnecting, or as the result of an error. The server MUST monitor calls for being unjoined from another call, and emit an unjoined event when this is detected.

            + + + + + + + + ]]> +             + + + + + + + +             From bed140034e94c1d0a2bebc8cafbb50b35047ac67 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 13:49:22 +0200 Subject: [PATCH 090/178] Specify behaviour for concurrent joins --- extensions/inbox/rayo.xml | 78 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0302a2ca..0a89d2df 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -750,7 +750,85 @@             +

            If a client wishes to modify the parameters of a join, it MUST send a new join command to the target call with the new parameters. The server MUST renegotiate media using the new parameters, and acknowledge the command's completion. The server MUST NOT re-send joined events.

            + + + + + + + + + + + + + + + + + + + + ]]> + +

            Rayo calls SHOULD support being joined to more than one other call at a time, each join having different parameters. Creating a new join MUST NOT destroy existing joins. If a join is requested but cannot be created without destroying existing joins, the call MUST return a conflict (cancel) error.

            + + + + + + + + + + + + + + + + + + + + + + + + + ]]>             From be0bba2599ac49df3c6a3d5290f4856e927f7c01 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 13:50:00 +0200 Subject: [PATCH 091/178] Break mixers section out of joining --- extensions/inbox/rayo.xml | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0a89d2df..0e34cb6e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -830,21 +830,21 @@ ]]> - - - - + + + +

            Components are long-lived elements of a call or mixer which may execute in paralell, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

            From 1c54bf2f77bcc6936ee74d96e158b9e554865541 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 13:51:10 +0200 Subject: [PATCH 092/178] Fix header level --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0e34cb6e..5355a169 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -832,7 +832,7 @@             - + - +

            Components are long-lived elements of a call or mixer which may execute in paralell, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

            From a9fcd51fa7e2833d6792826e51778f36854f9603 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 14:12:39 +0200 Subject: [PATCH 093/178] Add acknowledgements * Anyone missing? * Fixes #14 --- extensions/inbox/rayo.xml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 5355a169..d2f4db30 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -3437,9 +3437,21 @@
          • To enable authenticated, federated, web-scale 3PCC on platforms with APIs only suitable for trusted internal use (Asterisk, FreeSWITCH, etc).
          - Initial development of the Rayo specification and its reference implementation was provided by Voxeo Labs and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols, as well as client library implementations in Node/CoffeeScript and Python. + Initial development of the Rayo specification and its reference implementation was sponsored by Voxeo Labs and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols, as well as client library implementations in Node/CoffeeScript and Python. +

          The authors would like to acknowledge the input of teams at Voxeo Labs, Mojo Lingo and Telefónica in the development of the initial specification.

          +

          Specific individuals who have contributed to the specification or to software significant to its completion include:

          +
            +
          • Ben Langfeld
            • +
          • Ben Klang
            • +
          • Jason Goecke
            • +
          • John Dyer
            • +
          • Jose de Castro
            • +
          • Juan de Bravo
            • +
          • Luca Pradovera
            • +
          • Martín Pérez
            • +
          From 08180452a94874c0d4882c3690465216034bf710 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 17:27:32 +0200 Subject: [PATCH 094/178] Document output component session flow * Add content-type/url to output document --- extensions/inbox/rayo.xml | 244 +++++++++++++++++++++++++++++++++++++- 1 file changed, 238 insertions(+), 6 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index d2f4db30..a9b2563a 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1079,7 +1079,195 @@ ]]> - + +

          Media output is a core concept in Rayo, and is provided by the output component. The component allows media to be rendered to a call or a mixer, using the server's local media server. The component is created using an <output/> command, containing one or more documents to render, along with a set of options to determine the nature of the rendering.

          + + + + + + + +

          + You have 4 new messages. + The first is from Stephanie Williams and arrived at 3:45pm. + + The subject is ski trip + +

          +           + ]]> +           +           + + ]]>           + +

          The server MUST validate that it has apropriate resources/mechanisms to render the requested document before acknowledging the component creation.

          + + +

          In the case that an output component is executed on a call joined to other calls or mixers, the output SHOULD be rendered only to the call and not the joined parties (also known as 'whisper'). In the case that an output component is executed on a mixer, the output should be rendered into the mixer, such that all participants receive the output (also known as 'announce').

          +           + + +

          The output component implements several commands for manipulating the output during its execution.

          + + +

          A client may instruct an output component to pause by sending a pause command. The server MUST cause the media server to pause rendering, maintaining position within the document and allowing for later resumption.

          + + + + + + + ]]> +           + + +

          A client may instruct an output component to resume rendering if it has previously been paused. The server MUST cause the media server to resume rendering at the last pause marker.

          + + + + + + + ]]> +           + + +

          A client may instruct an output component to increase the rendering rate by a unit amount, defined by the media server. The server MUST cause the media server to perform the rate increase and acknowledge the command.

          + + + + + + + ]]> +           + + +

          A client may instruct an output component to decrease the rendering rate by a unit amount, defined by the media server. The server MUST cause the media server to perform the rate decrease and acknowledge the command.

          + + + + + + + ]]> +           + + +

          A client may instruct an output component to increase the rendering volume by a unit amount, defined by the media server. The server MUST cause the media server to perform the volume increase and acknowledge the command.

          + + + + + + + ]]> +           + + +

          A client may instruct an output component to decrease the rendering volume by a unit amount, defined by the media server. The server MUST cause the media server to perform the volume decrease and acknowledge the command.

          + + + + + + + ]]> +           + + +

          A client may instruct an output component to move the play marker forward or back in time by a specified amount before resuming output. The server MUST cause the media to seek as instructed and acknowledge the command.

          +

          The attributes of the <seek/> element are as follows.

          + + + + + + ]]> +           +           + + +

          The output component does not provide any intermediate events.

          +           + + +

          The output completion reason MUST be one of the core Rayo reasons, finish (indicating that the document finished rendering naturally) or max-time (indicating that the maximum time was exceeded). Output component completion does not provide any metadata.

          + + + + + + + ]]> +           +           +           @@ -1696,8 +1884,31 @@

          Presents a document for rendering by the output engine.

          -

          The <document/> element MUST contain a document for output rendering enclosed within CDATA.

          -

          The <document/> element has no attributes.

          +

          The <document/> element MUST have either a url attribute set OR a content type and a body, containing a document for output rendering enclosed within CDATA.

          +

          The attributes of the <document/> element are as follows.

          + + + + + + + + + + + + + + + + + + + + + + +
          AttributeDefinitionPossible ValuesDefaultInclusion
          urlProvides a URI at which the document is available.Any valid URI scheme supported by the server (eg HTTP).noneREQUIRED unless content-type and content are set
          content-typeIndicates the content type of the document provided as CDATA.A document content type tokenapplication/ssml+xmlREQUIRED unless url is set
           @@ -1769,7 +1980,7 @@

          The <finish/> element has no attributes.

          - +

          Indicates that the output component came to an end due to the maximum time limit being reached.

          The <max-time/> element MUST be empty.

          The <max-time/> element has no attributes.

          @@ -2809,6 +3020,27 @@           + + + + + + Provides a URI at which the document is available. Must not be provided if the content-type attribute is set or the element contains a document as CDATA. + + + + + + + Indicates the content type of the document provided as CDATA. Must not be set if the url attribute is set. + + + + + + + + @@ -2854,10 +3086,10 @@ - + - An document for rendering (contained within CDATA). + Provides the document for rendering. From 049e200f71aebadf8944f483b16d6523b3d53bed Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 17:34:14 +0200 Subject: [PATCH 095/178] [BUG] Cannot include CDATA tags in example stanzas (nested CDATA not allowed) #19 --- extensions/inbox/rayo.xml | 41 ++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a9b2563a..289f4f2e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1089,25 +1089,23 @@ id='h7ed2'> - - - -

          - You have 4 new messages. - The first is from Stephanie Williams and arrived at 3:45pm. - - The subject is ski trip - -

          -           - ]]> + + + +

          + You have 4 new messages. + The first is from Stephanie Williams and arrived at 3:45pm. + + The subject is ski trip + +

          +           @@ -1268,7 +1266,10 @@ - + + + + From f2a2489e7927086c21b2259146f485fcf57f251b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 18:37:10 +0200 Subject: [PATCH 096/178] Document input component session flow --- extensions/inbox/rayo.xml | 104 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 289f4f2e..feb1a8bf 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1267,7 +1267,111 @@ +

          Media input is a core concept in Rayo, and is provided by the input component. The component allows input to be collected from a call by way of either DTMF (dual-tone multi-frequency) or ASR (automatic speech recognition), using the server's local media server. The component is created using an <input/> command, containing one or more grammar documents by which to control input, along with a set of options to determine the nature of the collection.

          + + + + + + + + + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + + + + + + + + # + + + * 9 + + + + + + + + ]]> + +

          The server MUST validate that it has appropriate resources/mechanisms to collect the requested input before acknowledging the component creation.

          + + +

          In the case that an input component is executed on a call joined to other calls or mixers, the input SHOULD be collected only from the call and not the joined parties. Input components cannot be executed on a mixer.

          +           + + +

          The input component does not implement any intermediate commands, other than those specified for all components.

          +           + + +

          The output component does not provide any intermediate events.

          +           + + +

          The output completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Input component completion provides match metadata for the <finish/> reason only.

          +
            +
          • + finish (indicating that one of the grammars matched the received input) +
            • +
          • + initial-timeout (indicating that the initial timeout was triggered) +
            • +
          • + inter-digit-timeout (indicating that the inter-digit timeout was triggered) +
            • +
          • + max-silence (indicating that the max-silence timeout was triggered) +
            • +
          • + min-confidence (indicating that the minimum confidence threshold was not reached) +
            • +
          • + no-match (indicating that input was received which did not match any of the specified grammars) +
            • +
          + +

          If the media server reports a match to one of the provided grammars, the server MUST present the results of the match to the client by way of match meta-data on a finish complete reason. It MUST provide mode, confidence, interpretation and utterance data as specified on the match element.

          + + + + + + 1 2 3 4 # + + + dtmf-1 dtmf-2 dtmf-3 dtmf-4 dtmf-pound + + + + + + ]]> +           From 4c95af06a4c00994d322ba06d257e6c168e616fa Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 19:28:00 +0200 Subject: [PATCH 097/178] Document record component session flow --- extensions/inbox/rayo.xml | 92 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 91 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index feb1a8bf..94b8f0d9 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1374,7 +1374,97 @@ - + +

          Call recording is a core concept in Rayo, and is provided by the record component. The component allows media to be captured from a call or a mixer, using the server's local media server, stored, and made available to clients. The component is created using a <record/> command, with a set of options to determine the nature of the recording.

          + + + + + ]]> + +

          The server MUST validate that it has apropriate resources/mechanisms to make the recording before acknowledging the component creation.

          + + +

          In the case that a record component is executed on a call joined to other calls or mixers, the recording SHOULD be made of both sides of the join. In the case that a record component is executed on a mixer, the recording should be made of the mixer audio, such that all participants' audio is present in the recording.

          +           + + +

          The record component implements several commands for manipulating the recording during its execution.

          + + +

          A client may instruct a record component to pause by sending a pause command. The server MUST cause the media server to pause recording, allowing for later appending.

          + + + + + + + ]]> +           + + +

          A client may instruct a record component to resume recording if it has previously been paused. The server MUST cause the media server to resume recording, appending to the original file.

          + + + + + + + ]]> +           + +           + + +

          The record component does not provide any intermediate events.

          +           + + +

          The record completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Record component completion provides recording metadata in all cases.

          +
            +
          • + max-duration (indicating that the max duration was reached) +
            • +
          • + initial-timeout (indicating that the initial timeout was triggered) +
            • +
          • + final-timeout (indicating that the final timeout was triggered) +
            • +
          + +

          The server MUST present the recording for consumption by the client by way of recording meta-data on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration & size data as specified on the recording element.

          + + + + + + + + ]]> +           +           From db18a46f07b0d340862c9cddc4f7262db6e64bf5 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 19 Apr 2012 19:30:38 +0200 Subject: [PATCH 098/178] Stray tag --- extensions/inbox/rayo.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 94b8f0d9..0ca1b77c 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1430,7 +1430,6 @@ id='h7ed2'/> ]]> - From 1fe19ad11be9dbde9974058cbffd8429697b526e Mon Sep 17 00:00:00 2001 From: Ben Klang Date: Fri, 20 Apr 2012 16:11:39 -0400 Subject: [PATCH 099/178] Clarification; fix a spelling error --- extensions/inbox/rayo.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0ca1b77c..a9f3df43 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -48,12 +48,12 @@
        -

        Rayo is a protocol for controlling media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself.

        +

        Rayo is a protocol to allow third-party remote control over media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself.

          -
        • A Rayo server takes on the role of negotiating a session between itself and some other endpoint, or between two distinct endpoints, by way of an implementation-specific means, be that Jingle, SIP, connection to the public telephone network, or anything else. The server may even bridge multiple networks.
          • -
        • The server then presents the Rayo protocol as an interface to a client, allowing it to monitor and/or exercise third-party control over a particular session.
          • -
        • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end a session.
          • +
        • A Rayo server takes on the role of negotiating a media session between itself and some other endpoint, or between two external endpoints, by way of an implementation-specific means, be that Jingle, SIP, the public-switched telephone network, or anything else. The server may even bridge multiple networks.
          • +
        • The server then presents the Rayo protocol as an interface to a Rayo client, allowing it to monitor and/or exercise third-party control over particular the established media sessions.
          • +
        • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end sessions.

        The relationship between the calling parties, the Rayo server and the Rayo client looks something like this:

        @@ -82,7 +82,7 @@

        The client then decides that it is able to handle the incoming call, and so accepts it from the server, thus gaining exclusive control and indicating to the calling party that the call will be processed and that it should ring.

        - Date: Sat, 21 Apr 2012 11:34:14 +0200 Subject: [PATCH 100/178] Typos --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a9f3df43..2467b720 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -215,7 +215,7 @@
      • Extensible - The protocol must provide for the possibility of extra functionality being added by future specifications or an individual implementation.
      -

      Additionally, the protocol is required to abstract away the complexity of the raw negotioation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Jingle and FreeSWITCH are made in the respective specifications.

      +

      Additionally, the protocol is required to abstract away the complexity of the raw negotioation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Asterisk and FreeSWITCH are made in the respective specifications.

       @@ -272,7 +272,7 @@

      Calls have separate presence from the root domain of the service and thus appear to be separate entities.

      -

      A Rayo call is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

      +

      A Rayo mixer is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

      A Rayo mixer is responsible for sending its events to and receiving commands from a client, and may have some components executed on it directly.

      Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

       From 21a9681d82d0ea17263cf6bf860d119735c2d322 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 22 Apr 2012 20:22:08 +0200 Subject: [PATCH 101/178] Specify mixer API --- extensions/inbox/rayo.xml | 78 ++++++++++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 10 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2467b720..e9c5d438 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -833,16 +833,74 @@       - +

      While in general, calls may be joined peer-to-peer in any desireable combination, such an implimentation it not necessarily scaleable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and it MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

      + + + + + + + + + + + + + + ]]> + +

      If a client sends directed presence to a mixer, the mixer MUST subscribe the client to its events. On receiving unavailable presence, the mixer MUST stop sending events to the client.

      + +

      The error conditions on joining a mixer are the same as for calls, as are the unjoin and join modification semantics. Additionally, mixers may host components just like calls, following the rules defined for each component.

      + + + + + + + + + ]]> + +

      If the media server providing the mixer supports active speaker detection, it SHOULD emit active speaker events to all clients with an event subscription. Such events MUST indicate the start and end of speaking for a particular call ID joined to the mixer.

      + + + + + + + + + + + + + + + + + ]]>       From d8a2ee9ad5a168c18b048f1cd8baa3574df7a954 Mon Sep 17 00:00:00 2001 From: mpermar Date: Wed, 25 Apr 2012 10:29:51 +0300 Subject: [PATCH 102/178] typo --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index e9c5d438..1f3c0926 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -58,7 +58,7 @@

      The relationship between the calling parties, the Rayo server and the Rayo client looks something like this:

      - [caller] ----SIP---- [rayo server] ( -----Jingle---- [calee] ) optional + [caller] ----SIP---- [rayo server] ( -----Jingle---- [callee] ) optional                              | |                          rayo client From 5f247c9914c552151effc841d2d123784089316e Mon Sep 17 00:00:00 2001 From: mpermar Date: Wed, 25 Apr 2012 12:27:14 +0200 Subject: [PATCH 103/178] Fixed some typos --- extensions/inbox/rayo.xml | 49 ++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1f3c0926..45f58202 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -59,9 +59,9 @@

      The relationship between the calling parties, the Rayo server and the Rayo client looks something like this:

      [caller] ----SIP---- [rayo server] ( -----Jingle---- [callee] ) optional -                              | | -                          rayo client + | + rayo client

      This document defines the core Rayo protocol, and contains provisions for its extension by further specifications. Additionally, further documents specify implementation best practices, such as clustering.

      @@ -91,7 +91,7 @@ ]]> -

      The protocol defined herein is designed to provide the following features:

        -
      1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Evey attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
        2. +
      2. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Every attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
      3. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
      4. Speech Synthesis / TTS: In cases where dynamic data must be spoken, a Speech Synthesis engine many be used to play computer generated speech to the caller.
      5. Touch-tone Events / DTMF: Rayo surfaces real-time event when the caller presses keys on their touch-tone keypad.
        6. @@ -199,7 +199,7 @@
      6. Platform/vendor/hardware specific
      7. Synchronous interface
      8. Inconsistent - evolved, rather than designed
        9. -
      9. Lacking in scaleability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
        10. +
      10. Lacking in scalability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
      11. Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
      12. Inextensible
    @@ -208,14 +208,14 @@
    • Simple client library implementation - XMPP client libraries exist in all modern languages, and many are of a high standard.
    • Cross-platform standard - The protocol must not expose any platform specifics and all elements should be candidates for implementation on any suitable platform. Addiditionally, the protocol must be ratified as a standard following a community discussion.
      • -
    • Asynchronous interface - The protocol should present an asynchronous interface for the purposes of performance and flexibility in performing paralell operations.
      • +
    • Asynchronous interface - The protocol should present an asynchronous interface for the purposes of performance and flexibility in performing parallel operations.
    • Consistent - The protocol must provide a considered, unobtrusive, logically and philisophically consistent interface.
    • Federated - The protocol must support communication between client and server entities on separately owned, operated and addressed networks.
    • Flexible routing - The protocol must lend itself to routing across wide networks such as the internet, and to potential complex routing such as proxying or redirection. Additionally, the client and server should each be aware of the presence of the other and be able to use such information to make routing decisions.
    • Extensible - The protocol must provide for the possibility of extra functionality being added by future specifications or an individual implementation.
    -

    Additionally, the protocol is required to abstract away the complexity of the raw negotioation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Asterisk and FreeSWITCH are made in the respective specifications.

    +

    Additionally, the protocol is required to abstract away the complexity of the raw negotiation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Asterisk and FreeSWITCH are made in the respective specifications.

     @@ -237,7 +237,7 @@
    An XMPP entity to which an offer to control an incoming call may be sent.
    -
    Difinitive controlling party (DCP)
    +
    Definitive controlling party (DCP)
    The XMPP entity which gains a lock on control of a session, either by requesting the session's creation, or being the first respondent to an offer.
     @@ -277,7 +277,7 @@

    Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

    -

    A Rayo command is a simple combination of request and response and may be issued directly to the service, or to a call or mixer. Commands are executed serially and are generally very short-lived.

    +

    A Rayo command is a simple combination of request and response and may be issued directly to the service domain, or to a call or mixer. Commands are executed serially and are generally very short-lived.

    Components extend the Rayo protocol by providing additional media and call control functionality.

    @@ -382,7 +382,7 @@ ]]>     -

    On successfully receiving and parsing the dial command, the server SHOULD perform its own proprietary authorization measures to ensure that only desireable outbound sessions are created. If it is established that the command should not be allowed, the server MUST return an error giving an authorization reason.

    +

    On successfully receiving and parsing the dial command, the server SHOULD perform its own proprietary authorization measures to ensure that only desirable outbound sessions are created. If it is established that the command should not be allowed, the server MUST return an error giving an authorization reason.

    There are several reasons why the server might immediately return an error instead of acknowledging the creation of a new call:

    @@ -485,7 +485,7 @@ ]]>     -

    If the command is successfull and the call is queued, however, confirmation of such should be sent to the client, including a reference to the unique ID of the call. This call ID may be used to execute commands and filter events for the duration of the session.

    +

    If the command is successful and the call is queued, however, confirmation of such should be sent to the client, including a reference to the unique ID of the call. This call ID may be used to execute commands and filter events for the duration of the session.

    -

    When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it MUST then remove any parties whom it can identify as being temporarily inappropropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available. If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

    +

    When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it MUST then remove any parties whom it can identify as being temporarily inappropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available). If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

    If the server can identify active Potential Controlling Parties, it MUST offer them control of the call simultaneously. The server must broadcast an offer on behalf of the call to all Potential Controlling Parties, using applicable to/from/header data from the incoming session.

    If the specified media/direction options or their combination are not possible/supported, the server MUST return a <not-acceptable/> error with a type of 'modify'.

    - -

    While in general, calls may be joined peer-to-peer in any desireable combination, such an implimentation it not necessarily scaleable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and it MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

    +

    While in general, calls may be joined peer-to-peer in any desirable combination, such an implementation it not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and it MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

    -

    Components are long-lived elements of a call or mixer which may execute in paralell, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

    +

    Components are long-lived elements of a call or mixer which may execute in parallel, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

    In the event that a call or mixer receives a command which triggers the execution of a component, it MUST use the normal command handling routine, and schedule the component for immediate execution and return a reference to the requesting client as confirmation of the component's completion. Additionally, the component JID MUST send available presence to the executing party:

    @@ -935,9 +935,9 @@

    There are several reasons why the server might immediately return an error instead of acknowledging the creation of a new component:

      -
    • The server does not implement the component/command.
      • -
    • The server does not implement a particular option value for the command/component.
      • -
    • Some aspect of the component/command does not comply with this specification.
      • +
    • The server does not implement the component.
      • +
    • The server does not implement a particular option value for the component.
      • +
    • Some aspect of the component does not comply with this specification.
    • The server does not have sufficient resources to create a new component on this call/mixer.
    • The component would cause a resource conflict with another component on this call/mixer.
    @@ -1011,7 +1011,7 @@     -

    Once acknowleged, the component MUST begin execution according to its particular specification. During its execution, it MAY emit events relevant to its progress, and an implementation MUST be cabable of emitting events specified for each component. Any events should be sent inside a directed presence element to the executing party.

    +

    Once acknowleged, the component MUST begin execution according to its particular specification. During its execution, it MAY emit events relevant to its progress, and an implementation MUST be capable of emitting events specified for each component. Any events should be sent inside a directed presence element to the executing party.

    During execution, the component MUST respond to commands addressed to it. Each component has its own set of commands, but all components have the 'stop' command in common. On receipt of the stop command, the component MUST acknowledge that it has been instructed to stop and gracefully cease its execution in whatever way is appropriate to the particular component.

    @@ -1079,7 +1079,7 @@ ]]>

    If the command is not appropriate for the component's current stage of execution, it should return a unexpected-request (wait) error:

    - ]]> -

    Once a component is completed, or if it did not exist, the server should return an item-not-found (cancel) error:

    +

    Once a component is completed, or if it did not exist, the server should return an item-not-found (cancel) error as response to any commands:

    -

    The output component does not provide any intermediate events.

    +

    The input component does not provide any intermediate events.

     -

    The output completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Input component completion provides match metadata for the <finish/> reason only.

    +

    The input completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Input component completion provides match metadata for the <finish/> reason only.

    • finish (indicating that one of the grammars matched the received input) @@ -1525,7 +1525,7 @@ -

      Session termination may occurr by one of several methods:

      +

      Session termination may occur by one of several methods:

      • An inbound call may be redirected by a PCP to some other target.
      • An inbound call may be rejected by a PCP.
        • @@ -3939,3 +3939,4 @@
      + From 638c9a2b8e6de3c8b0534f446ec518ade3bcc0b6 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Apr 2012 14:13:47 +0100 Subject: [PATCH 104/178] Clarify some minor points --- extensions/inbox/rayo.xml | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 45f58202..2534af30 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -184,7 +184,7 @@

      The protocol defined herein is designed to provide the following features:

        -
      1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Every attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
        2. +
      2. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Outbound calls may also be made and monitored. Every attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
      3. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
      4. Speech Synthesis / TTS: In cases where dynamic data must be spoken, a Speech Synthesis engine many be used to play computer generated speech to the caller.
      5. Touch-tone Events / DTMF: Rayo surfaces real-time event when the caller presses keys on their touch-tone keypad.
        6. @@ -196,12 +196,12 @@

        Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have at least one or more of the following drawbacks:

        • Totally ground-up wire protocol requiring implementation all the way down to the socket
          • -
        • Platform/vendor/hardware specific
          • -
        • Synchronous interface
          • +
        • Platform/vendor/hardware specific - each system implements its own proprietary protocol which does not allow easily porting an application from one back-end to another.
          • +
        • Synchronous interface - Operations on calls or other entities are often blocking, and one must serialise all control messaged.
        • Inconsistent - evolved, rather than designed
        • Lacking in scalability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
        • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
          • -
        • Inextensible
          • +
        • Inextensible - The specification of extensions to the core protocol is either impossible or very difficult.

        Rayo has been designed with these failings in mind, and intends to address many concerns not addressed by these earlier attempts. The following considerations were made:

        @@ -213,8 +213,11 @@
      6. Federated - The protocol must support communication between client and server entities on separately owned, operated and addressed networks.
      7. Flexible routing - The protocol must lend itself to routing across wide networks such as the internet, and to potential complex routing such as proxying or redirection. Additionally, the client and server should each be aware of the presence of the other and be able to use such information to make routing decisions.
      8. Extensible - The protocol must provide for the possibility of extra functionality being added by future specifications or an individual implementation.
        9. +
      9. Secure - The protocol should include appropriate measures for authentication and authorization of participants, as well as preventing third-parties from intercepting control messages.
    +

    Many of the features in the above list are available to Rayo at no specification or implementation cost, since they are core to XMPP itself and thus Rayo inherits these 'for free'.

    +

    Additionally, the protocol is required to abstract away the complexity of the raw negotiation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Asterisk and FreeSWITCH are made in the respective specifications.

     @@ -226,11 +229,11 @@
    Command
    -
    Commands instruct the receiving entity to perform some atomic action. Commands may be executed against a given call, component or mixer and can be considered completed as soon as they receive a response.
    +
    Commands instruct the receiving entity to perform some atomic action. Commands may be executed against a given call, component or mixer and can be considered completed as soon as they receive a response. Some commands create components, and return a reference to the component in their response.
    Component
    -
    Components extend the Rayo protocol by providing additional media and call control functionality. Components are similar to commands, but have a lifecycle attached to them. A component, once created and attached to a call or mixer, will respond giving an ID that it is known by. The component will then begin execution, and may trigger events or have commands issued to it. Finally, once the component is stopped or comes to an end naturally, it will issue a special <complete/> event
    +
    Components extend the Rayo protocol by providing additional media and call control functionality. Components are created by an appropriate command, which returns a reference to the component. Components are executed asynchronously, and have a lifecycle attached to them, with the ability to trigger events or have commands issued to it. Once a component is stopped or comes to an end naturally, it will issue a special <complete/> event, indicating that it has ceased execting and deliver any required data.
    Potential controlling party (PCP)
    @@ -268,12 +271,12 @@

    A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a single session. It is usually a simple alias for the main server process.

    -

    A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client.

    +

    A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client. Calls may host components.

    Calls have separate presence from the root domain of the service and thus appear to be separate entities.

    A Rayo mixer is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

    -

    A Rayo mixer is responsible for sending its events to and receiving commands from a client, and may have some components executed on it directly.

    +

    A Rayo mixer is responsible for sending its events to and receiving commands from one or more clients, and can host components.

    Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

     @@ -282,7 +285,7 @@

    Components extend the Rayo protocol by providing additional media and call control functionality.

    -

    Components are started by sending a specialized command to a call or mixer. Unlike basic commands, components have a lifecycle. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

    +

    Components are started by sending a specialized command to a call or mixer, and have a lifecycle. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

     @@ -531,7 +534,7 @@     -

    When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it MUST then remove any parties whom it can identify as being temporarily inappropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available). If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

    +

    When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it SHOULD then remove any parties whom it can identify as being temporarily inappropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available). If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

    If the server can identify active Potential Controlling Parties, it MUST offer them control of the call simultaneously. The server must broadcast an offer on behalf of the call to all Potential Controlling Parties, using applicable to/from/header data from the incoming session.

    Date: Wed, 25 Apr 2012 14:15:55 +0100 Subject: [PATCH 105/178] Don't require available presence from components and clarify some language --- extensions/inbox/rayo.xml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2534af30..8be00f2d 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -909,7 +909,7 @@

    Components are long-lived elements of a call or mixer which may execute in parallel, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

    -

    In the event that a call or mixer receives a command which triggers the execution of a component, it MUST use the normal command handling routine, and schedule the component for immediate execution and return a reference to the requesting client as confirmation of the component's completion. Additionally, the component JID MUST send available presence to the executing party:

    +

    In the event that a call or mixer receives a command which triggers the execution of a component, it MUST use the normal command handling routine, schedule the component for immediate execution and return a reference to the requesting client as confirmation of the component's creation:

    ]]> - - - ]]>

    If a component execution command is received prior to the call being answered, the server MUST implicitly answer the underlying session and negotiate media as if an answer command had been received before it begins processing the component.

    From c9004f989af6f3e41f87bc96cfd019e50039f856 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 25 Apr 2012 14:21:41 +0100 Subject: [PATCH 106/178] Relax a requirement From @mpermar: This is interesting because the client is always open to ignore it. The problem happens when the call is sent to multiple clients. If one of them rejects it (as you are encouraging in the spec) currently the call is rejected and other clients won't be able to take it. So, shouldn't the spec state "CAN" instead of "SHOULD"? or perhaps as done below for hangups state something like "If a client wishes to reject a call it should send...". Otherwise, rayo servers will have to implement complex logic to handle this case. --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 8be00f2d..b90ec602 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1585,7 +1585,7 @@     -

    If a client cannot handle an incoming call, it SHOULD reject it. The client MUST do this before accepting the call. The target URI must be specified in the 'to' attribute of the redirect element.

    +

    If a client cannot handle an incoming call, it MAY reject it. The client MUST do this before accepting the call. The target URI must be specified in the 'to' attribute of the redirect element.

    Date: Wed, 25 Apr 2012 16:30:28 +0200 Subject: [PATCH 107/178] Added stop-beep to record --- extensions/inbox/rayo.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b90ec602..b2498e19 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2447,6 +2447,13 @@ false OPTIONAL + + stop-beep + Indicates whether subsequent record stop will be preceded with a beep. + true|false + false + OPTIONAL + start-paused Whether subsequent record will start in PAUSE mode. From 5d7eda8e3234c49863b8b48aaf90d787ac7edc04 Mon Sep 17 00:00:00 2001 From: mpermar Date: Wed, 25 Apr 2012 16:35:49 +0200 Subject: [PATCH 108/178] adding stop-beep to schema --- extensions/inbox/rayo.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b2498e19..4b00e7fa 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -3761,6 +3761,13 @@ + + + + Indicates whether subsequent record stop will be preceded with a beep. + + + From b7f88417c44dcb9db6483d56fc37379f91162f90 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 27 Apr 2012 14:00:34 +0100 Subject: [PATCH 109/178] Record component should ignore hints it does not understand --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 4b00e7fa..0fc8b60f 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1445,7 +1445,7 @@ ]]> -

    The server MUST validate that it has apropriate resources/mechanisms to make the recording before acknowledging the component creation.

    +

    The server MUST validate that it has apropriate resources/mechanisms to make the recording before acknowledging the component creation. The component MUST ignore any hints that it does not understand.

    In the case that a record component is executed on a call joined to other calls or mixers, the recording SHOULD be made of both sides of the join. In the case that a record component is executed on a mixer, the recording should be made of the mixer audio, such that all participants' audio is present in the recording.

    From 6b79da4a9d6bfca88f13f58d47be87321247d5b3 Mon Sep 17 00:00:00 2001 From: Ben Klang Date: Sat, 16 Jun 2012 15:40:18 -0400 Subject: [PATCH 110/178] Typos/small ambiguities --- extensions/inbox/rayo.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 0fc8b60f..cb0468d7 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -186,7 +186,7 @@
    1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Outbound calls may also be made and monitored. Every attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
    2. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
      3. -
    3. Speech Synthesis / TTS: In cases where dynamic data must be spoken, a Speech Synthesis engine many be used to play computer generated speech to the caller.
      4. +
    4. Speech Synthesis / TTS: In cases where dynamic data must be spoken, a Speech Synthesis engine may be used to play computer generated speech to the caller.
    5. Touch-tone Events / DTMF: Rayo surfaces real-time event when the caller presses keys on their touch-tone keypad.
    6. Speech Recognition: Enables the phone application to take spoken queues allowing for sophisticated voice-driven menus and directory services.
    7. Call Recording: Can be used to capture the caller's voice (e.g. Voicemail) or both sides of the call for auditing and compliance purposes.
      8. @@ -197,7 +197,7 @@
      • Totally ground-up wire protocol requiring implementation all the way down to the socket
      • Platform/vendor/hardware specific - each system implements its own proprietary protocol which does not allow easily porting an application from one back-end to another.
        • -
      • Synchronous interface - Operations on calls or other entities are often blocking, and one must serialise all control messaged.
        • +
      • Synchronous interface - Operations on calls or other entities are often blocking, and one must serialise all control messages.
      • Inconsistent - evolved, rather than designed
      • Lacking in scalability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
      • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
        • @@ -233,7 +233,7 @@
        Component
        -
        Components extend the Rayo protocol by providing additional media and call control functionality. Components are created by an appropriate command, which returns a reference to the component. Components are executed asynchronously, and have a lifecycle attached to them, with the ability to trigger events or have commands issued to it. Once a component is stopped or comes to an end naturally, it will issue a special <complete/> event, indicating that it has ceased execting and deliver any required data.
        +
        Components extend the Rayo protocol by providing additional media and call control functionality. Components are created by an appropriate command, which returns a reference to the component. Components are executed asynchronously, and have a lifecycle attached to them, with the ability to trigger events or have commands issued to it. Once a component is stopped or comes to an end naturally, it will issue a special <complete/> event, indicating that it has ceased executing and deliver any required data.
        Potential controlling party (PCP)
        @@ -270,7 +270,7 @@

        A Rayo client is responsible for indicating its availability to a Rayo server and responding to offer messages appropriately.

        -

        A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a single session. It is usually a simple alias for the main server process.

        +

        A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain, usually at a sub-domain, with the purpose of representing a single session. It is usually a simple alias for the main server process.

        A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client. Calls may host components.

        Calls have separate presence from the root domain of the service and thus appear to be separate entities.

         @@ -280,12 +280,12 @@

        Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

        -

        A Rayo command is a simple combination of request and response and may be issued directly to the service domain, or to a call or mixer. Commands are executed serially and are generally very short-lived.

        +

        A Rayo command is a simple combination of request and response and may be issued directly to the service domain, or to a call or a mixer. Commands are executed serially and are generally very short-lived.

        Components extend the Rayo protocol by providing additional media and call control functionality.

        -

        Components are started by sending a specialized command to a call or mixer, and have a lifecycle. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

        +

        Components have a lifecycle and are started by sending a specialized command to a call or mixer. Thus, a request for creation of a component will return a reference to the component's ID, and the component will continue to execute until it completes, potentially sending events and processing commands along the way (such as an instruction to pause or terminate), before finally issuing an event indicating its completion and thus unavailability. Multiple components may be active on a call or mixer at any one time, and commands may be executed on any entity during the execution of a component.

         @@ -836,7 +836,7 @@ -

        While in general, calls may be joined peer-to-peer in any desirable combination, such an implementation it not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and it MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

        +

        While calls may generally be joined peer-to-peer in any desirable combination, such an implementation is not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and it MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

        Date: Sat, 16 Jun 2012 15:41:17 -0400 Subject: [PATCH 111/178] Additional justification against proprietary specs --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index cb0468d7..eef68299 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -196,7 +196,7 @@

        Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have at least one or more of the following drawbacks:

        • Totally ground-up wire protocol requiring implementation all the way down to the socket
          • -
        • Platform/vendor/hardware specific - each system implements its own proprietary protocol which does not allow easily porting an application from one back-end to another.
          • +
        • Platform/vendor/hardware specific - each system implements its own proprietary protocol (in many cases, without a formal published specification) which does not allow easily porting an application from one back-end to another.
        • Synchronous interface - Operations on calls or other entities are often blocking, and one must serialise all control messages.
        • Inconsistent - evolved, rather than designed
        • Lacking in scalability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
          • From 2ebf26f589b8bd681bc35eee4e091ed3692ee9b1 Mon Sep 17 00:00:00 2001 From: Ben Klang Date: Sat, 16 Jun 2012 15:41:47 -0400 Subject: [PATCH 112/178] clarify "high standard" --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index eef68299..a7f70d41 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -206,7 +206,7 @@

          Rayo has been designed with these failings in mind, and intends to address many concerns not addressed by these earlier attempts. The following considerations were made:

            -
          • Simple client library implementation - XMPP client libraries exist in all modern languages, and many are of a high standard.
            • +
          • Simple client library implementation - XMPP client libraries exist in all modern languages, and many are of a high standard of quality and maturity.
          • Cross-platform standard - The protocol must not expose any platform specifics and all elements should be candidates for implementation on any suitable platform. Addiditionally, the protocol must be ratified as a standard following a community discussion.
          • Asynchronous interface - The protocol should present an asynchronous interface for the purposes of performance and flexibility in performing parallel operations.
          • Consistent - The protocol must provide a considered, unobtrusive, logically and philisophically consistent interface.
            • From cecc4a43dca9b4ad82dd48c220ef708c4da39b42 Mon Sep 17 00:00:00 2001 From: Ben Klang Date: Sat, 16 Jun 2012 15:46:26 -0400 Subject: [PATCH 113/178] Clarify Rayo's abstraction and interaction with platforms --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a7f70d41..efbf2f71 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -218,7 +218,7 @@

            Many of the features in the above list are available to Rayo at no specification or implementation cost, since they are core to XMPP itself and thus Rayo inherits these 'for free'.

            -

            Additionally, the protocol is required to abstract away the complexity of the raw negotiation/transport protocols such as SIP, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as the public APIs of Asterisk and FreeSWITCH are made in the respective specifications.

            +

            Additionally, the protocol is required to abstract away the complexity of the back-end negotiation, especially the details of the transport protocols such as SIP or Jingle, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as integrating with the public APIs of telephony engines such as Asterisk and FreeSWITCH are made in their respective specifications.

            From 09a7ec027a852f3854dc63c75e7b23f5426e20b6 Mon Sep 17 00:00:00 2001 From: Ben Klang Date: Sat, 16 Jun 2012 16:24:00 -0400 Subject: [PATCH 114/178] Clarify the type attribute on iq --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index efbf2f71..89b4f930 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -340,7 +340,7 @@

            Rayo defines several events and commands which may be executed on one of the above actors. These payloads must be sent within an XMPP primitive element, and the rules are as such:

            • Events: Sent as directed presence from the entity producing the event to a client.
              • -
            • Commands: Sent as an <iq/> 'set' from the client to the entity to be acted on. Responses returned as an <iq/> 'result' or 'error'.
              • +
            • Commands: Sent as an <iq/> with the 'type' attribute 'set' from the client to the entity to be acted on. Responses returned as an <iq/> with the 'type' attribute either 'result' or 'error'.
                         From 410d1dff0d14cbd0b8b25aee24fc7bb99efc6caf Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 18 Jun 2012 13:32:10 +0200 Subject: [PATCH 115/178] Rule out auto-answer, and outline attempts at early media Fixes #33 --- extensions/inbox/rayo.xml | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 89b4f930..07e9d05a 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -929,7 +929,7 @@ ]]> -

            If a component execution command is received prior to the call being answered, the server MUST implicitly answer the underlying session and negotiate media as if an answer command had been received before it begins processing the component.

            +

            If a component execution command is received prior to the call being answered, the server MUST NOT answer the call, and SHOULD attempt to use early-media techniques to perform the relevant operation without answering the call. If such early-media is not possible, it MUST return an error indicating that the call state is incorrect (unexpected-request).

            The whole command MUST be parsed up-front, and any applicable validation performed before acknowledgement of the command.

            @@ -941,6 +941,7 @@
          • Some aspect of the component does not comply with this specification.
          • The server does not have sufficient resources to create a new component on this call/mixer.
          • The component would cause a resource conflict with another component on this call/mixer.
            • +
          • The call/mixer is not in the correct state to begin executing the component.

          If the server does not implement the command/component, it should return a feature-not-implemented (cancel) error:

          @@ -1010,6 +1011,19 @@ ]]> +

          If the server is not able to create the component due to the call being in an incorrect state, it should return an unexpected-request (wait) error:

          + + + + + + + ]]> +

          Once acknowleged, the component MUST begin execution according to its particular specification. During its execution, it MAY emit events relevant to its progress, and an implementation MUST be capable of emitting events specified for each component. Any events should be sent inside a directed presence element to the executing party.

          From a1567a53e35bcd494558513cb4b50a7585e9d149 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 14 Oct 2012 21:35:15 -0300 Subject: [PATCH 116/178] Switch input to return NLSML --- extensions/inbox/rayo.xml | 86 ++++++--------------------------------- 1 file changed, 12 insertions(+), 74 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 07e9d05a..1e10af38 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1425,22 +1425,19 @@
        -

        If the media server reports a match to one of the provided grammars, the server MUST present the results of the match to the client by way of match meta-data on a finish complete reason. It MUST provide mode, confidence, interpretation and utterance data as specified on the match element.

        +

        If the media server reports a match to one of the provided grammars, the server MUST present the results of the match to the client by way of match meta-data on a finish complete reason. It MUST provide an NLSML fragment as specified on the match element.

        - - - - 1 2 3 4 # - - - dtmf-1 dtmf-2 dtmf-3 dtmf-4 dtmf-pound - - - + + + + 1 2 3 4 + + + ]]> @@ -2359,40 +2356,8 @@

        Provides the result of a match between the input received and the specified grammar.

        -

        The <match/> element MUST contain valid <interpretation/> and <utterance/> elements.

        -

        The attributes of the <match/> element are as follows.

        - - - - - - - - - - - - - - - - - - - -
        AttributeDefinitionPossible ValuesInclusion
        modeIndicates the mode by which the match occurred.speech|dtmfREQUIRED
        confidenceIndicates the confidence with which the match has been made.A decimal value between 0 and 1.REQUIRED
        - - -

        Provides the result of the grammar match after any symantic processing which may have been performed.

        -

        The <interpretation/> element SHOULD contain an interpretation as CDATA.

        -

        The <interpretation/> element has no attributes.

        -         - - -

        Provides the raw string of the detected input.

        -

        The <utterance/> element SHOULD contain an utterance as textual content.

        -

        The <utterance/> element has no attributes.

        -         +

        The <match/> element MUST contain a valid NLSML fragment (<result/> element).

        +

        The <match/> element has no attributes.

         @@ -3642,37 +3607,10 @@ - - - - Indicates the mode by which the match occurred. - - - - - - - - - - - - - Indicates the confidence with which the match has been made. - - - - - - - Provides the result of the grammar match after any symantic processing which may have been performed. - - - - + - Provides the raw string of the detected input. + Provides the NLSML result of the grammar match after any symantic processing which may have been performed. See the NLSML spec for details. From 2afb8869099cd210148c52a9142350d033bf1f93 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 14 Oct 2012 21:35:23 -0300 Subject: [PATCH 117/178] Use correct GRXML content type --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1e10af38..9e347331 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2347,7 +2347,7 @@ content-type Indicates the content type of the grammar document provided as CDATA. A grammar content type token - application/grammar+grxml + application/srgs+xml REQUIRED unless url is set From efe63fb0e4a4282203e159afbfd814c872b9abad Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sun, 14 Oct 2012 21:39:30 -0300 Subject: [PATCH 118/178] Fix input match completion reason --- extensions/inbox/rayo.xml | 28 ++++------------------------ 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 9e347331..3a77e67b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1406,7 +1406,7 @@

        The input completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Input component completion provides match metadata for the <finish/> reason only.

        • - finish (indicating that one of the grammars matched the received input) + match (indicating that one of the grammars matched the received input)
        • initial-timeout (indicating that the initial timeout was triggered) @@ -2355,17 +2355,11 @@ -

          Provides the result of a match between the input received and the specified grammar.

          +

          Indicates that the component came to an end due to one of its grammars matching the received input.

          The <match/> element MUST contain a valid NLSML fragment (<result/> element).

          The <match/> element has no attributes.

           - -

          Indicates that the component came to an end due to one of its grammars matching the received input.

          -

          The <finish/> element MUST contain a valid match element.

          -

          The <finish/> element has no attributes.

          -           -

          Indicates that the component came to an end because the initial timeout was triggered.

          The <initial-timeout/> element MUST be empty.

          @@ -3605,27 +3599,13 @@ - - - - - - Provides the NLSML result of the grammar match after any symantic processing which may have been performed. See the NLSML spec for details. - - - - - - + - Indicates that the component came to an end due to one of its grammars matching the received input. + Indicates that the component came to an end due to one of its grammars matching the received input. Provides the NLSML result of the grammar match after any symantic processing which may have been performed. See the NLSML spec for details. - - - From 6db84c8a4b8b3a2c1f1f682fba8b008071ad8d7f Mon Sep 17 00:00:00 2001 From: Luca Pradovera Date: Mon, 3 Dec 2012 15:37:31 +0100 Subject: [PATCH 119/178] Added renderer attribute to output component. --- extensions/inbox/rayo.xml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 3a77e67b..76a9b80b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2144,6 +2144,13 @@ -1 OPTIONAL + + renderer + Indicates which media engine the server should use to render the Output. The server defines the possible values and falls back to the platform default if not specified. + An arbitrary string + + OPTIONAL + @@ -3317,6 +3324,13 @@ + + + + Indicates which media engine the server should use to render the Output. + + + From ee2df29f63e7015436442a75cb43173b393822c5 Mon Sep 17 00:00:00 2001 From: Luca Pradovera Date: Tue, 18 Dec 2012 18:42:12 +0100 Subject: [PATCH 120/178] First draft of recording direction. --- extensions/inbox/rayo.xml | 50 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 76a9b80b..f7b85c77 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1459,7 +1459,10 @@

          The server MUST validate that it has apropriate resources/mechanisms to make the recording before acknowledging the component creation. The component MUST ignore any hints that it does not understand.

          -

          In the case that a record component is executed on a call joined to other calls or mixers, the recording SHOULD be made of both sides of the join. In the case that a record component is executed on a mixer, the recording should be made of the mixer audio, such that all participants' audio is present in the recording.

          +

          In the case that a record component is executed on a call joined to other calls or mixers, the direction attibute will specify if the sent audio, received audio, or both will be present in the recording. +

          In send mode, only the audio sent by the caller is recorded.

          +

          In recv mode, when just joined to the media server, should record TTS, audio playback, etc; when joined to another call, should record that other call's sending audio (probably a human talking) also. When joined to a mixer, should record the audio send from the mixer (other people talking) also.

          +

          When executing a record against a mixer, send mode is not supported. Recv mode records audio from all mixer participants. Duplex is a clone of recv.

           @@ -2462,6 +2465,19 @@ -1 OPTIONAL + + direction + +

          Indicates the direction of the call to record, meaning which call legs(s) are included in the resulting file, in case the call is joined to another or a mixer.

          +
            +
          • "duplex" - Records both call legs in a stereo file, one leg for each channel. If not joined, it behaves like send.
            • +
          • "send" - Indicates that only the audio sent from the caller is to be recorded. Not supported when Record is executed against a mixer.
            • +
          • "recv" - Indicates that only and all audio received by the caller is recorded.
            • +
          + + OPTIONAL + duplex + @@ -3742,6 +3758,38 @@ + + + + Indicates the direction of the call to record, meaning which call legs(s) are included in the resulting file, in case the call is joined to another or a mixer. + + + + + + + + Records both call legs in a stereo file, one leg for each channel. If not joined, it behaves like send. + + + + + + + Indicates that only the audio sent from the caller is to be recorded. Not supported when Record is executed against a mixer. + + + + + + + Indicates that only and all audio received by the caller is recorded. + + + + + + From 8d80b76ba00a9c5dc5cbdf3541ad6da339e49c4a Mon Sep 17 00:00:00 2001 From: Luca Pradovera Date: Tue, 18 Dec 2012 23:09:58 +0100 Subject: [PATCH 121/178] [CS] Some clarifications in docs for the direction attribute on Record. --- extensions/inbox/rayo.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f7b85c77..1b75e94f 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1462,6 +1462,7 @@

          In the case that a record component is executed on a call joined to other calls or mixers, the direction attibute will specify if the sent audio, received audio, or both will be present in the recording.

          In send mode, only the audio sent by the caller is recorded.

          In recv mode, when just joined to the media server, should record TTS, audio playback, etc; when joined to another call, should record that other call's sending audio (probably a human talking) also. When joined to a mixer, should record the audio send from the mixer (other people talking) also.

          +

          Duplex mode is a combination of send and recv. The platform may mix these or record them as separate channels.

          When executing a record against a mixer, send mode is not supported. Recv mode records audio from all mixer participants. Duplex is a clone of recv.

           @@ -2470,7 +2471,7 @@

          Indicates the direction of the call to record, meaning which call legs(s) are included in the resulting file, in case the call is joined to another or a mixer.

            -
          • "duplex" - Records both call legs in a stereo file, one leg for each channel. If not joined, it behaves like send.
            • +
          • "duplex" - Records both sent and received audio.
          • "send" - Indicates that only the audio sent from the caller is to be recorded. Not supported when Record is executed against a mixer.
          • "recv" - Indicates that only and all audio received by the caller is recorded.
          @@ -3769,7 +3770,7 @@ - Records both call legs in a stereo file, one leg for each channel. If not joined, it behaves like send. + Records both sent and received audio. From 175b5500430bdefd7d8c80bd2de060d31d652fd0 Mon Sep 17 00:00:00 2001 From: Luca Pradovera Date: Wed, 19 Dec 2012 00:20:37 +0100 Subject: [PATCH 122/178] [CS] Some doc fixes and clarifications on Record. --- extensions/inbox/rayo.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1b75e94f..b37c3dd1 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1459,10 +1459,10 @@

          The server MUST validate that it has apropriate resources/mechanisms to make the recording before acknowledging the component creation. The component MUST ignore any hints that it does not understand.

          -

          In the case that a record component is executed on a call joined to other calls or mixers, the direction attibute will specify if the sent audio, received audio, or both will be present in the recording. +

          In the case that a record component is executed on a call joined to other calls or mixers, the direction attibute will specify if the sent audio, received audio, or both will be present in the recording.

          In send mode, only the audio sent by the caller is recorded.

          In recv mode, when just joined to the media server, should record TTS, audio playback, etc; when joined to another call, should record that other call's sending audio (probably a human talking) also. When joined to a mixer, should record the audio send from the mixer (other people talking) also.

          -

          Duplex mode is a combination of send and recv. The platform may mix these or record them as separate channels. +

          Duplex mode is a combination of send and recv. The platform may mix these or record them as separate channels.

          When executing a record against a mixer, send mode is not supported. Recv mode records audio from all mixer participants. Duplex is a clone of recv.

           @@ -3762,7 +3762,7 @@ - Indicates the direction of the call to record, meaning which call legs(s) are included in the resulting file, in case the call is joined to another or a mixer. + Indicates the direction of the call to record, as in media produced or received by the calling party. From ed1b166d00cb5fd9b5cb1856ee0f642f1137aafe Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 7 Jan 2013 18:36:59 -0500 Subject: [PATCH 123/178] [FEATURE] Add recording mix support to Rayo --- extensions/inbox/rayo.xml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b37c3dd1..9638f6df 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2479,6 +2479,13 @@ OPTIONAL duplex + + mix + Whether all channels (call legs) should be mixed into a single recording channel. + true|false + false + OPTIONAL + @@ -3791,6 +3798,13 @@ + + + + Whether all channels (call legs) should be mixed into a single recording channel. + + + From e794617ac3fb1bdd616f88de571203e639552280 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 7 Jan 2013 18:38:50 -0500 Subject: [PATCH 124/178] Fix table formatting --- extensions/inbox/rayo.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 9638f6df..fcb01030 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2470,14 +2470,16 @@ direction

          Indicates the direction of the call to record, meaning which call legs(s) are included in the resulting file, in case the call is joined to another or a mixer.

          + +
          • "duplex" - Records both sent and received audio.
          • "send" - Indicates that only the audio sent from the caller is to be recorded. Not supported when Record is executed against a mixer.
          • "recv" - Indicates that only and all audio received by the caller is recorded.
          - OPTIONAL duplex + OPTIONAL mix From 25b62a5732ac7685e0931ea996c22b115e814a8f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 7 Jan 2013 19:18:43 -0500 Subject: [PATCH 125/178] Typo fix --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index fcb01030..3a008ebe 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1383,8 +1383,8 @@ - - + + ]]> From 6ddc52e2f842f11a11386e9c25e758608092af18 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 8 Jan 2013 07:58:10 -0500 Subject: [PATCH 126/178] [FEATURE] Add initial prompt component definition --- extensions/inbox/rayo.xml | 171 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 3a008ebe..bb070b77 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1444,6 +1444,94 @@           + +

          Prompt is a convenience component to wrap input and output components, combine their lifecycles, and allow input to barge-in on an output component in the standard sense.

          + + + + + + + + +

          + Please enter your pin number now. +

          +           +           +           + + + + + + + + + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + + + + + + + + # + + + * 9 + + + + + + +           + + ]]>           + +

          The server MUST validate that it has appropriate resources/mechanisms to render the requested output and collect the requested input before acknowledging the component creation.

          + + +

          The prompt component follows the same combined join considerations as output and input components.

          +           + + +

          The prompt component implements implements all intermediate commands from output and input and behaves the same.

          +           + + +

          The prompt component emits intermediate events from the nested output and input components.

          +           + + +

          The input completion reason MUST be one of the core Rayo reasons, or one of the Input component reasons. Events signalling completion of the output components are suppressed.

          +           +           +

          Call recording is a core concept in Rayo, and is provided by the record component. The component allows media to be captured from a call or a mixer, using the server's local media server, stored, and made available to clients. The component is created using a <record/> command, with a set of options to determine the nature of the recording.

          @@ -2402,6 +2490,32 @@           + +

          An prompt component is a mixture of audio output and input, and is used to link the lifecycle of both such input may interrupt output via an arbitrary grammar.

          + + +

          Instructs the server to begin an input detector of the specified mode, with certain attributes, governed by the rules provided in one or more grammar documents, while simultaneously rendering output.

          +

          The <prompt/> element MUST contain an <input/> element and an <output/> element.

          +

          The attributes of the <prompt/> element are as follows.

          + + + + + + + + + + + + + + + +
          AttributeDefinitionPossible ValuesDefaultInclusion
          barge-inWhether or not the input detector is permitted to interrupt the output.true|falsetrueOPTIONAL
          +           +           +

          A record component is used to instruct the server to record audible or visual media for temporary or permanent storage.

          @@ -3693,6 +3807,63 @@ + + ]]>           + + + + + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + Instructs the server to begin an input detector of the specified mode, with certain attributes, governed by the rules provided in one or more grammar documents, while simultaneously rendering output. + + + + + + + + Whether or not the input detector is permitted to interrupt the output. + + + + + + + + + Provides the output component to be executed + + + + + + + Provides the input component to be executed + + + + + + + + ]]> From b4cf7db7b6d865c6c54203576a5c98f79059ddf0 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 7 Feb 2013 16:09:35 +0000 Subject: [PATCH 127/178] Bump rayo version to reflect semi-stable --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index bb070b77..62e6c1dc 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -41,8 +41,8 @@ http://langfeld.me - 0.0.1 - 2011-12-05 + 0.1.0 + 2013-02-07 jdc

          First draft.

                     From 85d475e5cd19da822cd6404261c55bc7ebfc4519 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 15 Feb 2013 17:20:16 +0000 Subject: [PATCH 128/178] [RAYO] Add back voice attribute on output --- extensions/inbox/rayo.xml | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 62e6c1dc..6a4dd6ec 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2243,6 +2243,13 @@ OPTIONAL + + voice + The voice with which to speak the requested document + Any voice supported by the TTS engine. + + OPTIONAL + @@ -3471,7 +3478,14 @@ - + + + + The voice with which to speak the requested document. + + + + From 5501da197c3c68afb7e5da8598f982cafad45f2d Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 18 Feb 2013 14:57:48 +0000 Subject: [PATCH 129/178] Make the requirement for SSML support explicit. --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 6a4dd6ec..ce126ab9 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2191,7 +2191,7 @@

          Instructs the server to begin an output component executing on the target call or mixer with the specified document and parameters.

          -

          The <output/> element MUST contain one or more <document/> elements.

          +

          The <output/> element MUST contain one or more <document/> elements. A server MUST support the application/ssml+xml content type, but MAY additionally support others.

          The attributes of the <output/> element are as follows.

          From 6491f7ec7264e0f66a6bb2c54ec01afa4d24c61e Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 1 Mar 2013 17:32:43 +0000 Subject: [PATCH 130/178] Add prompt namespace to namespace list --- extensions/inbox/rayo.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ce126ab9..2309e077 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2776,6 +2776,7 @@
        • urn:xmpp:rayo:output:complete:1
        • urn:xmpp:rayo:input:1
        • urn:xmpp:rayo:input:complete:1
          • +
        • urn:xmpp:rayo:prompt:1
        • urn:xmpp:rayo:record:1
        • urn:xmpp:rayo:record:complete:1
          • From ce92c7e659bbe55b05ca716c9ebdbe0b811523c4 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Sat, 2 Mar 2013 15:54:16 +0000 Subject: [PATCH 131/178] Formatting typo --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2309e077..391de0a2 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2245,7 +2245,7 @@           - @@ -3486,7 +3486,7 @@ - + From 5e8ac11f4c61883bf1373978816cc3bad15e65dc Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Mon, 25 Mar 2013 12:59:20 -0300 Subject: [PATCH 132/178] Make recording and other completion metadata elements siblings of the completion reason #55 --- extensions/inbox/rayo.xml | 51 +++++++++++++++------------------------ 1 file changed, 20 insertions(+), 31 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 391de0a2..f878e1e5 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1618,9 +1618,8 @@ to='juliet@capulet.lit/courtyard' type='unavailable'> - - - + + ]]> @@ -2681,19 +2680,19 @@

          Indicates that the component came to an end due to the max duration being reached.

          -

          The <max-duration/> element MUST contain a valid recording element.

          +

          The <max-duration/> element MUST be empty.

          The <max-duration/> element has no attributes.

          Indicates that the component came to an end due to no input being detected before the initial-timeout.

          -

          The <initial-timeout/> element MUST contain a valid recording element.

          +

          The <initial-timeout/> element MUST be empty.

          The <initial-timeout/> element has no attributes.

          Indicates that the component came to an end because no input had been detected for the final timeout duration.

          -

          The <final-timeout/> element MUST contain a valid recording element.

          +

          The <final-timeout/> element MUST be empty.

          The <final-timeout/> element has no attributes.

           @@ -3332,6 +3331,15 @@           + + + + + May be any component specific meta-data elements, such as . + + + +           @@ -3354,7 +3362,7 @@ - + Indicates that the component came to an end because it was issued a stop command by the controlling party. @@ -3363,7 +3371,7 @@ - + Indicates that the component came to an end because the call ended. @@ -3380,16 +3388,6 @@ - - - - - May be any component specific meta-data elements. - - - - - ]]> @@ -4059,7 +4057,7 @@ - + @@ -4084,39 +4082,30 @@ - + Indicates that the component came to an end due to the max duration being reached. - - - - + Indicates that the component came to an end due to no input being detected before the initial-timeout. - - - - + Indicates that the component came to an end because no input had been detected for the final timeout duration. - - - From 727de4cd71f6a1e1c2022e5dcc0744521be90563 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 26 Mar 2013 11:35:04 -0300 Subject: [PATCH 133/178] Credit corrections & better implementation references --- extensions/inbox/rayo.xml | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f878e1e5..ad97fe78 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -26,13 +26,6 @@ NOT_YET_ASSIGNED - - Jose - de Castro - jdecastro@voxeo.com - jdecastro@voxeo.com - http://voxeolabs.com - Ben Langfeld @@ -40,10 +33,17 @@ ben@langfeld.me http://langfeld.me + + Jose + de Castro + jdecastro@voxeo.com + jdecastro@voxeo.com + http://voxeolabs.com + 0.1.0 2013-02-07 - jdc + bl

          First draft.

                     @@ -4122,15 +4122,16 @@
        • To enable authenticated, federated, web-scale 3PCC on platforms with APIs only suitable for trusted internal use (Asterisk, FreeSWITCH, etc).
          • - Initial development of the Rayo specification and its reference implementation was sponsored by Voxeo Labs and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols, as well as client library implementations in Node/CoffeeScript and Python. + Initial development of the Rayo specification and its reference implementation was sponsored by Voxeo Labs and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols and FreeSWITCH EventSocket, native to FreeSWITCH (mod_rayo), as well as client library implementations in Node/CoffeeScript and Python. -

          The authors would like to acknowledge the input of teams at Voxeo Labs, Mojo Lingo and Telefónica in the development of the initial specification.

          +

          The authors would like to acknowledge the input of teams at Voxeo Labs, Mojo Lingo and Telefónica in the development of the initial specification, and Grasshopper in expanding the implementation landscape.

          Specific individuals who have contributed to the specification or to software significant to its completion include:

          • Ben Langfeld
          • Ben Klang
            • +
          • Chris Rienzo
          • Jason Goecke
          • John Dyer
          • Jose de Castro
            • From fe83b262134169493cd5aa0566588d51fcacb740 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 26 Mar 2013 11:35:09 -0300 Subject: [PATCH 134/178] Whitespace --- extensions/inbox/rayo.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ad97fe78..1748f301 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -4141,4 +4141,3 @@
          - From 07c7dce0a8d8a1fbd3b859364b80933fbcd2abc1 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 26 Mar 2013 11:36:37 -0300 Subject: [PATCH 135/178] Remove mention of non-existent extension specs --- extensions/inbox/rayo.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 1748f301..13373866 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -64,7 +64,7 @@ rayo client -

          This document defines the core Rayo protocol, and contains provisions for its extension by further specifications. Additionally, further documents specify implementation best practices, such as clustering.

          +

          This document defines the core Rayo protocol, and contains provisions for its extension by further specifications.

          In order to understand the nature of a Rayo interaction, here we show a simple example of a control session.

          @@ -218,7 +218,7 @@

          Many of the features in the above list are available to Rayo at no specification or implementation cost, since they are core to XMPP itself and thus Rayo inherits these 'for free'.

          -

          Additionally, the protocol is required to abstract away the complexity of the back-end negotiation, especially the details of the transport protocols such as SIP or Jingle, but to map conceptually to such protocols. Best practices for the implementation of Rayo on top of SIP and Jingle environments, as well as integrating with the public APIs of telephony engines such as Asterisk and FreeSWITCH are made in their respective specifications.

          +

          Additionally, the protocol is required to abstract away the complexity of the back-end negotiation, especially the details of the transport protocols such as SIP or Jingle, but to map conceptually to such protocols.

           @@ -263,7 +263,7 @@

          A Rayo server is an entity which is capable of receiving and intiating calls and being party to their media stream, while exposing a Rayo interface to a client in order to permit control over its calls. The Rayo server may handle calls in any way supported by the implementation, such as SIP, Jingle, etc, and should expose a full XMPP domain at the root level of the service deployment (eg shakespeare.lit).

          The Rayo server is responsible for keeping track of valid clients, routing calls to the correct potential controlling parties, performing authorization measures on received stanzas, etc.

          -

          For the purposes of this specification, complex server-side deployments such as clusters, proxies, gateways, protocol translators, etc are not considered. Further details of such concepts may be found in their relevant specifications.

          +

          For the purposes of this specification, complex server-side deployments such as clusters, proxies, gateways, protocol translators, etc are not considered. Further details of such concepts may be found in their (present or future) relevant specifications.

          A Rayo client is an entity which implements the Rayo protocol for the purpose of asserting control over calls made available by a Rayo server. The method by which such control measures are determined is outside the scope of this document, but may be the result of human interaction or some automated decision-making process.

          From d69abd2fc005e29938aece2be65fe586cd04baaf Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Tue, 26 Mar 2013 12:20:55 -0300 Subject: [PATCH 136/178] Separate end reasons for first/third party hangup Fixes #45 --- extensions/inbox/rayo.xml | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 13373866..344a6816 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1863,7 +1863,11 @@
          <hungup/>
          -
          Indication that the call ended due to a normal hangup by either party.
          +
          Indication that the call ended due to a normal hangup by the remote party.
          +           + +
          <hangup-command/>
          +
          Indication that the call ended due to a normal hangup triggered by a hangup command.
          <timeout/>
          @@ -2900,7 +2904,14 @@ - Indication that the call ended due to a normal hangup by either party. + Indication that the call ended due to a normal hangup by the remote party. + + + + + + + Indication that the call ended due to a normal hangup triggered by a hangup command. From 5206055f26e53dc3eefd7d20815b4156228629f0 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 10:59:03 -0300 Subject: [PATCH 137/178] Fix #56 --- extensions/inbox/rayo.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 344a6816..11db4827 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -125,9 +125,11 @@ id='j9d3j'> - ![CDATA[ - You have no new messages. Goodbye! - ]] + + ![CDATA[ + You have no new messages. Goodbye! + ]] + ]]> From 523de643ab4a9f561eb54042805a5219f047ab7b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 11:52:51 -0300 Subject: [PATCH 138/178] Fix example end reason for 1st-party hangup --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 11db4827..2e62e4cd 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -178,7 +178,7 @@ to='juliet@capulet.lit/balcony' type='unavailable'> - + ]]> From eaef369dae0d61b3d5f9c60f592ebf07b14b5188 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 12:03:22 -0300 Subject: [PATCH 139/178] Try out nesting CDATA in examples --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 2e62e4cd..ecb5601e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -126,9 +126,9 @@ - ![CDATA[ + From e300276437cc1fca447a6fb2e8c0b9c69a127558 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 12:10:24 -0300 Subject: [PATCH 140/178] Include CDATA in all examples where it's required Fix #19 --- extensions/inbox/rayo.xml | 204 ++++++++++++++++++++------------------ 1 file changed, 106 insertions(+), 98 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ecb5601e..924c964e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1164,23 +1164,25 @@ id='h7ed2'> - - - -

          - You have 4 new messages. - The first is from Stephanie Williams and arrived at 3:45pm. - - The subject is ski trip - -

          -           + + + +

          + You have 4 new messages. + The first is from Stephanie Williams and arrived at 3:45pm. + + The subject is ski trip + +

          +           + ]]]]>           @@ -1351,40 +1353,42 @@ id='h7ed2'> - - - - - - 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - - - - - - - - # - - - * 9 - - - - + + + + + + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + + + + + + + + # + + + * 9 + + + + + ]]]]> @@ -1457,58 +1461,62 @@ - - - -

          - Please enter your pin number now. -

          -           + + + +

          + Please enter your pin number now. +

          +           + ]]]]>           - - - - - - 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - - - - - - - - # - - - * 9 - - - - + + + + + + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + + + + + + + + # + + + * 9 + + + + + ]]]]>           From c4ea3bda9bd76b0247172f3b6b5b4938956a0d9c Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 12:13:58 -0300 Subject: [PATCH 141/178] Give example of plain text output document Fixes #24 --- extensions/inbox/rayo.xml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 924c964e..58d2ede5 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1188,6 +1188,21 @@ ]]> + + + + + + + + ]]> +

          The server MUST validate that it has apropriate resources/mechanisms to render the requested document before acknowledging the component creation.

          From 71fcf94d03b867a46cf3a4d8f4f6a9d28de01eb5 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 12:21:58 -0300 Subject: [PATCH 142/178] Consistency in terminating bulleted lists with a period Fixes #31 --- extensions/inbox/rayo.xml | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 58d2ede5..9f2d7ea9 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -186,7 +186,7 @@

          The protocol defined herein is designed to provide the following features:

            -
          1. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Outbound calls may also be made and monitored. Every attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc.)
            2. +
          2. Call Control: Incoming calls are "offered" to clients at which point they can be answered, rejected, redirected to another destination, etc. Outbound calls may also be made and monitored. Every attempt is made to be shield the Rayo client from the low level telephony protocol (e.g. SIP, Jingle, PSTN, etc).
          3. Audio File Playback: A compatible Rayo server will fetch a file from a a specified URL and play the containing audio to the caller.
          4. Speech Synthesis / TTS: In cases where dynamic data must be spoken, a Speech Synthesis engine may be used to play computer generated speech to the caller.
          5. Touch-tone Events / DTMF: Rayo surfaces real-time event when the caller presses keys on their touch-tone keypad.
            6. @@ -197,12 +197,12 @@

            Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have at least one or more of the following drawbacks:

              -
            • Totally ground-up wire protocol requiring implementation all the way down to the socket
              • +
            • Totally ground-up wire protocol requiring implementation all the way down to the socket.
            • Platform/vendor/hardware specific - each system implements its own proprietary protocol (in many cases, without a formal published specification) which does not allow easily porting an application from one back-end to another.
            • Synchronous interface - Operations on calls or other entities are often blocking, and one must serialise all control messages.
              • -
            • Inconsistent - evolved, rather than designed
              • -
            • Lacking in scalability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible
              • -
            • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system
              • +
            • Inconsistent - evolved, rather than designed.
              • +
            • Lacking in scalability - client/server sometimes tied one-to-one, servers rarely clustered, advanced message routing not possible.
              • +
            • Poor security - lack of wire-level encryption, lack of or sub-standard authentication mechanisms, lack of or limited authorization mechanisms, lack of or poor sandboxing between multiple tenants on one system.
            • Inextensible - The specification of extensions to the core protocol is either impossible or very difficult.
            @@ -1427,22 +1427,22 @@

            The input completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Input component completion provides match metadata for the <finish/> reason only.

            • - match (indicating that one of the grammars matched the received input) + match (indicating that one of the grammars matched the received input).
            • - initial-timeout (indicating that the initial timeout was triggered) + initial-timeout (indicating that the initial timeout was triggered).
            • - inter-digit-timeout (indicating that the inter-digit timeout was triggered) + inter-digit-timeout (indicating that the inter-digit timeout was triggered).
            • - max-silence (indicating that the max-silence timeout was triggered) + max-silence (indicating that the max-silence timeout was triggered).
            • - min-confidence (indicating that the minimum confidence threshold was not reached) + min-confidence (indicating that the minimum confidence threshold was not reached).
            • - no-match (indicating that input was received which did not match any of the specified grammars) + no-match (indicating that input was received which did not match any of the specified grammars).
            @@ -1627,13 +1627,13 @@

            The record completion reason MUST be one of the core Rayo reasons, or one of the following reasons. Record component completion provides recording metadata in all cases.

            • - max-duration (indicating that the max duration was reached) + max-duration (indicating that the max duration was reached).
            • - initial-timeout (indicating that the initial timeout was triggered) + initial-timeout (indicating that the initial timeout was triggered).
            • - final-timeout (indicating that the final timeout was triggered) + final-timeout (indicating that the final timeout was triggered).
            @@ -2046,7 +2046,7 @@
          - + @@ -2071,7 +2071,7 @@ - + @@ -2094,7 +2094,7 @@ - + @@ -2117,7 +2117,7 @@ - + From 261795a753ff0639c6b6fcac48c815087f5bd915 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 15:05:10 -0300 Subject: [PATCH 143/178] Clarify support for multiple headers of the same name Fixes #35 --- extensions/inbox/rayo.xml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 9f2d7ea9..93c9dc68 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1817,6 +1817,24 @@ ]]> + + +

          In elements which may carry child <header/> elements, a server or client MAY specify several header elements with the same name. In such cases, these MUST be considered to form a collection of ordered values for the key provided.

          + + + +
          +
          + + + ]]> + From 0005ed0a14a8a7f1b4ddf8919b6c062440cc9a3b Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 15:40:41 -0300 Subject: [PATCH 144/178] Clarify mixer presence subscription rules Fixes #21 --- extensions/inbox/rayo.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 93c9dc68..b0bfce5b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -863,9 +863,9 @@ ]]> -

          If a client sends directed presence to a mixer, the mixer MUST subscribe the client to its events. On receiving unavailable presence, the mixer MUST stop sending events to the client.

          +

          Mixers MUST respect the normal rules of XMPP presence subscriptions. If a client sends directed presence to a mixer, the mixer MUST implicitly create a presence subscription for the client. On receiving unavailable presence, the mixer MUST stop sending events to the client.

          -

          The error conditions on joining a mixer are the same as for calls, as are the unjoin and join modification semantics. Additionally, mixers may host components just like calls, following the rules defined for each component.

          +

          The error conditions on joining a mixer are the same as for calls, as are the unjoin and join modification semantics. Additionally, mixers SHOULD be able to host components just like calls, following the rules defined for each component.

          ]]> -

          If the media server providing the mixer supports active speaker detection, it SHOULD emit active speaker events to all clients with an event subscription. Such events MUST indicate the start and end of speaking for a particular call ID joined to the mixer.

          +

          If the media server providing the mixer supports active speaker detection, it MUST emit active speaker events to all clients with a presence subscription. Such events MUST indicate the start and end of speaking for a particular call ID joined to the mixer.

          +

          Once the last participant unjoins from the mixer, the mixer SHOULD be destroyed. When a mixer is destroyed, it MUST send unavailable presence to all entities which have a presence subscription.

          +

          Components are long-lived elements of a call or mixer which may execute in parallel, have a lifecycle (may send events and/or process commands during their execution, indicate their completion asynchronously) and typically implement media operations. A server SHOULD implement components in such a way that it is acceptable to execute multiple components of the same type or of differing types simultaneously. A server SHOULD implement all core components.

          From 8ec724173c5f8014f2292c719a7dd9e8a45cd460 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 27 Mar 2013 19:14:49 -0300 Subject: [PATCH 145/178] Better explain optional elements of addresses Fixes #44 --- extensions/inbox/rayo.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index b0bfce5b..bbfcaa5b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -292,7 +292,7 @@           -

          All of the actors described in the previous section (with the exception of commands) are represented by XMPP entities with a JID of their own. Thus, a scheme for determining the JIDs of each of these entities is required. The following is the required naming scheme for Rayo deployments.

          +

          All of the actors described in the previous section (with the exception of commands) are represented by XMPP entities with a JID of their own. Thus, a scheme for determining the JIDs of each of these entities is required. The following is the required naming scheme for Rayo deployments, where elements in square brackets are optional.

          voiceThe voice with which to speak the requested document + The voice with which to speak the requested document Any voice supported by the TTS engine. OPTIONAL
          call-id Indicates the 3rd party call ID to which the target call should be joined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is setREQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set.
          call-id Indicates the 3rd party call ID from which the target call should be unjoined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is setREQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set.
          mixer-name
          call-id Indicates the 3rd party call ID to which the target call was joined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is setREQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set.
          mixer-name
          call-id Indicates the 3rd party call ID from which the target call was unjoined.REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is setREQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set.
          mixer-name
          @@ -311,27 +311,27 @@ - + - + - + - + - +
          Actor
          Call[call ID]@[call sub-domain].[service domain]<call ID>@[<call sub-domain>.]<service domain> f88eh2@call.shakespeare.lit
          Mixer[mixer name]@[mixer sub-domain].[service domain]<mixer name>@[<mixer sub-domain>.]<service domain> conf1@mixer.shakespeare.lit
          Call Component[call ID]@[call sub-domain].[service domain]/[component ID]<call ID>@[<call sub-domain>.]<service domain>/<component ID> f88eh2@call.shakespeare.lit/8f83jf
          Mixer Component[mixer name]@[mixer sub-domain].[service domain]/[component ID]<mixer name>@[<mixer sub-domain>.]<service domain>/<component ID> conf1@mixer.shakespeare.lit/932eu
          Server Component[service domain]/[component ID]<service domain>/<component ID> shakespeare.lit/f3fg4
          From a9f8a448b7fe7cfd7088204e9f2256202ac94b58 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 29 Mar 2013 14:10:36 -0300 Subject: [PATCH 146/178] Calls and mixers should use caps to advertise that they are a call or mixer Fixes #48 --- extensions/inbox/rayo.xml | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index bbfcaa5b..22289e6d 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -72,6 +72,10 @@ + @@ -354,6 +358,10 @@ + chat ]]> @@ -362,6 +370,10 @@ + dnd ]]> @@ -538,10 +550,14 @@

          When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it SHOULD then remove any parties whom it can identify as being temporarily inappropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available). If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

          -

          If the server can identify active Potential Controlling Parties, it MUST offer them control of the call simultaneously. The server must broadcast an offer on behalf of the call to all Potential Controlling Parties, using applicable to/from/header data from the incoming session.

          +

          If the server can identify active Potential Controlling Parties, it MUST offer them control of the call simultaneously. The server must broadcast an offer on behalf of the call to all Potential Controlling Parties, using applicable to/from/header data from the incoming session. The server MUST also include entity capabilities information in the presence stanza containing the offer, in order to advertise the fact that the entity is a call, qualified by the node name "urn:xmpp:rayo:call:1".

          + @@ -838,7 +854,7 @@ -

          While calls may generally be joined peer-to-peer in any desirable combination, such an implementation is not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and it MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

          +

          While calls may generally be joined peer-to-peer in any desirable combination, such an implementation is not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and MUST broadcast presence to all controlling parties who have calls joined to it before any other events are sent. The server MUST include entity capabilities information in the first presence stanza it sends, in order to advertise the fact that the entity is a mixer, qualified by the node name "urn:xmpp:rayo:mixer:1". A mixer MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

          + + + +
        • urn:xmpp:rayo:1
        • urn:xmpp:rayo:client:1
          • +
        • urn:xmpp:rayo:call:1
          • +
        • urn:xmpp:rayo:mixer:1
        • urn:xmpp:rayo:ext:1
        • urn:xmpp:rayo:ext:complete:1
        • urn:xmpp:rayo:output:1
          • From 90e068d73ba0663dac946de13dc144bc94d42170 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 29 Mar 2013 15:26:16 -0300 Subject: [PATCH 147/178] Add the concept of security zones to address join security issues #38 --- extensions/inbox/rayo.xml | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 22289e6d..5a258d13 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -249,6 +249,10 @@
          Definitive controlling party (DCP)
          The XMPP entity which gains a lock on control of a session, either by requesting the session's creation, or being the first respondent to an offer.
          + +
          Security Zone
          +
          A security zone is the conceptual border around a call which defines which parties may interact with the call's media or signaling. A security zone MUST contain the rayo server's internal implementation, the media server to which the call is joined, the DCP, and any JID whose bare form is the same as the DCP. A server MAY relax this definition further, for example to consider all JIDs at the same domain to be in the same security zone.
          +           @@ -595,22 +599,24 @@

          Calls in a Rayo system are capable of having their media streams moved/manipulated. Once such manipulation is to join the media streams of two calls. In a scenario where callA and callB should be joined, the client MUST send a join command to either call (not both) specifying the call ID of the other call, like so:

          - - ]]> -

          The server MUST join the media streams of the two calls and return an empty IQ result to confirm that the operation has been successful. Additionally, both calls MUST dispatch joined events specifying who they have been joined to:

          - + ]]> +

          If the calls to be joined to each other are in the same security zone, the server MUST join the media streams of the two calls and return an empty IQ result to confirm that the operation has been successful. If the parties to be joined are not within the same security zone, an error should be returned as detailed below.

          + +

          When calls are joined to each other by any mechanism, each call MUST dispatch a joined event specifying who they have been joined to:

          + @@ -628,6 +634,7 @@

          There are several reasons why the call might return an error instead of acknowledging a join:

          • The specified join party does not exist or cannot be found.
            • +
          • The specified join party is inaccessible for the purposes of being joined due to security restrictions.
          • The server does not have sufficient resources to complete the join.
          • The join command was malformed.
          • The specified media/direction options or their combination are not possible/supported.
            • @@ -646,6 +653,19 @@ ]]> +

            If the specified join party is inaccessible for the purposes of being joined due to security restrictions, the server MUST return a <not-allowed/> error with a type of 'cancel'.

            + + + + + + + ]]> +

            If the server does not have sufficient resources to complete the join, the server MUST return a <resource-constraint/> error with a type of 'wait'.

            Date: Thu, 4 Apr 2013 17:52:17 -0300 Subject: [PATCH 148/178] Specify input behaviour on a mixer Fixes #25 --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 5a258d13..56ca01b2 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1458,7 +1458,7 @@

            The server MUST validate that it has appropriate resources/mechanisms to collect the requested input before acknowledging the component creation.

            -

            In the case that an input component is executed on a call joined to other calls or mixers, the input SHOULD be collected only from the call and not the joined parties. Input components cannot be executed on a mixer.

            +

            In the case that an input component is executed on a call joined to other calls or mixers, the input SHOULD be collected only from the call and not the joined parties. Input components executed on a mixer SHOULD collect and combine input from all participants joined to the mixer.

             From c7497e943ffe211c75d50b158e91ffaf5b8da9f2 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 4 Apr 2013 18:21:24 -0300 Subject: [PATCH 149/178] Specify required support for input/output document types and modes Fixes #36 --- extensions/inbox/rayo.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 56ca01b2..37f77e8a 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1201,7 +1201,7 @@ ]]>             -

            Media output is a core concept in Rayo, and is provided by the output component. The component allows media to be rendered to a call or a mixer, using the server's local media server. The component is created using an <output/> command, containing one or more documents to render, along with a set of options to determine the nature of the rendering.

            +

            Media output is a core concept in Rayo, and is provided by the output component. The component allows media to be rendered to a call or a mixer, using the server's local media server. A server MUST support audio file playback and MUST support the text/uri-list document format. A server MAY support speech synthesis and MAY support SSML. The component is created using an <output/> command, containing one or more documents to render, along with a set of options to determine the nature of the rendering.

            -

            Media input is a core concept in Rayo, and is provided by the input component. The component allows input to be collected from a call by way of either DTMF (dual-tone multi-frequency) or ASR (automatic speech recognition), using the server's local media server. The component is created using an <input/> command, containing one or more grammar documents by which to control input, along with a set of options to determine the nature of the collection.

            +

            Media input is a core concept in Rayo, and is provided by the input component. The component allows input to be collected from a call by way of either DTMF (dual-tone multi-frequency) or ASR (automatic speech recognition), using the server's local media server. A Rayo server MUST support DTMF input and MUST support SRGS XML grammars (application/srgs+xml). A server MAY suport speech input, and MAY support other grammar formats. The component is created using an <input/> command, containing one or more grammar documents by which to control input, along with a set of options to determine the nature of the collection.

            - + - + content-type Indicates the content type of the document provided as CDATA. A document content type token - application/ssml+xml + REQUIRED unless url is set @@ -2545,7 +2545,7 @@ content-type Indicates the content type of the grammar document provided as CDATA. A grammar content type token - application/srgs+xml + none REQUIRED unless url is set @@ -3773,7 +3773,7 @@ - + The method by which to collect input. From 7ca6d85d356a7f78528acb0a0296de443714aab9 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 4 Apr 2013 21:17:33 -0300 Subject: [PATCH 150/178] Clarify error behaviour in Prompt Specify the error to be returned in the case that output commands are executed once output has ceased executing. Fixes #57 --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 37f77e8a..f3273949 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1591,7 +1591,7 @@ -

            The prompt component implements implements all intermediate commands from output and input and behaves the same.

            +

            The prompt component implements implements all intermediate commands from output and input and behaves the same. If output component commands are executed after the output component has ceased executing, a <unexpected-request> error MUST be returned.

             From e3e9197be7948a9f1f89bf7861c6436c788fd74f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 4 Apr 2013 21:25:16 -0300 Subject: [PATCH 151/178] Make errors on bad commands consistent Eliminate use of not-acceptable Fixes #23 --- extensions/inbox/rayo.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index f3273949..ff28c622 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -487,7 +487,7 @@ ]]>             -

            If the dial command was malformed, the server MUST return a <not-acceptable/> error with a type of 'modify'.

            +

            If the dial command was malformed, the server MUST return a <bad-request/> error with a type of 'modify'.

            - + ]]> @@ -692,7 +692,7 @@ ]]>             -

            If the specified media/direction options or their combination are not possible/supported, the server MUST return a <not-acceptable/> error with a type of 'modify'.

            +

            If the specified media/direction options or their combination are not possible/supported, the server MUST return a <feature-not-implemented/> error with a type of 'modify'.

            - + ]]> From 82e4dbdd83ce07fe7d9c6440e222c52787784972 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 4 Apr 2013 21:29:54 -0300 Subject: [PATCH 152/178] Update copyright date --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ff28c622..a658ef09 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -9,7 +9,7 @@ Rayo This specification defines an XMPP protocol extension for the third-party control of telephone calls and other similar media sessions. The protocol includes support for session management/signaling, as well as advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. The protocol serves a different purpose from that of first-party protocols such as Jingle or SIP, and is compatible with those protocols. - This XMPP Extension Protocol is copyright (c) 2011 by the XMPP Standards Foundation (XSF). + This XMPP Extension Protocol is copyright (c) 2013 by the XMPP Standards Foundation (XSF). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. From 51a420c29ead9897c87ba95a2316396b1ce00a94 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 4 Apr 2013 22:17:58 -0300 Subject: [PATCH 153/178] Require that refs be a full URI for a call In `` elements, id is replaced by a uri attribute. When requesting joins, call URIs must be used. Fixes #41 --- extensions/inbox/rayo.xml | 128 +++++++++++++++++++------------------- 1 file changed, 63 insertions(+), 65 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index a658ef09..eba46535 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -261,8 +261,6 @@
            • juliet@capulet.lit/balcony, romeo@montague.lit/orchard - Potential controlling parties
            • shakespeare.lit - The root domain of the Rayo service
              • -
            • call.shakespeare.lit - The Rayo service's call domain
              • -
            • mixer.shakespeare.lit - The Rayo service's mixer domain
            @@ -280,12 +278,12 @@

            A Rayo client is responsible for indicating its availability to a Rayo server and responding to offer messages appropriately.

             -

            A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain, usually at a sub-domain, with the purpose of representing a single session. It is usually a simple alias for the main server process.

            +

            A Rayo call is a short-lived XMPP entity within the scope of the deployment's root domain, perhaps at a sub-domain, with the purpose of representing a single session. It is usually a simple alias for the main server process.

            A Rayo call is the entity with which most client interactions are made, and is responsible for sending its events to and receiving commands from a client. Calls may host components.

            Calls have separate presence from the root domain of the service and thus appear to be separate entities.

             -

            A Rayo mixer is an XMPP entity within the scope of the deployment's root domain (usually at a sub-domain) with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

            +

            A Rayo mixer is an XMPP entity within the scope of the deployment's root domain, perhaps at a sub-domain, with the purpose of representing a service for the linking of media streams from several calls. It is usually a simple alias for the main server process.

            A Rayo mixer is responsible for sending its events to and receiving commands from one or more clients, and can host components.

            Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

             @@ -512,7 +510,7 @@ to='juliet@capulet.lit/balcony' type='result' id='h7ed2'> - + ]]> @@ -542,7 +540,7 @@ - + ]]> @@ -604,7 +602,7 @@ to='callA@call.shakespeare.lit' type='set' id='h7ed2'> - + - + - + ]]> @@ -646,7 +644,7 @@ to='juliet@capulet.lit/balcony' type='error' id='h7ed2'> - + @@ -659,7 +657,7 @@ to='juliet@capulet.lit/balcony' type='error' id='h7ed2'> - + @@ -672,20 +670,20 @@ to='juliet@capulet.lit/balcony' type='error' id='h7ed2'> - + ]]> -

            If the join command was malformed (eg no call ID specified), the server MUST return a <bad-request/> error with a type of 'modify'.

            +

            If the join command was malformed (eg no call URI specified), the server MUST return a <bad-request/> error with a type of 'modify'.

            - + @@ -698,7 +696,7 @@ to='juliet@capulet.lit/balcony' type='error' id='h7ed2'> - + @@ -713,7 +711,7 @@ to='callA@call.shakespeare.lit' type='set' id='h7ed2'> - + ]]> @@ -753,20 +751,20 @@ to='juliet@capulet.lit/balcony' type='error' id='h7ed2'> - + ]]> -

            If the unjoin command was malformed (eg an empty call ID specified), the server MUST return a <bad-request/> error with a type of 'modify'.

            +

            If the unjoin command was malformed (eg an empty call URI specified), the server MUST return a <bad-request/> error with a type of 'modify'.

            - + @@ -780,12 +778,12 @@ - + - + ]]> @@ -797,7 +795,7 @@ to='callA@call.shakespeare.lit' type='set' id='h7ed2'> - + - + - + - + - + - + - + - + - + @@ -903,7 +901,7 @@ - + ]]> @@ -923,7 +921,7 @@ to='juliet@capulet.lit/balcony' type='result' id='h7ed2'> - + ]]> @@ -932,22 +930,22 @@ - + - + - + - + ]]> @@ -973,7 +971,7 @@ to='juliet@capulet.lit/balcony' type='result' id='h7ed2'> - + ]]> @@ -1690,7 +1688,7 @@ type='unavailable'> - + ]]> @@ -2108,15 +2106,15 @@ bridge - call-id - Indicates the 3rd party call ID to which the target call should be joined. + call-uri + Indicates the 3rd party call URI to which the target call should be joined. REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set. mixer-name Indicates the mixer name to which the target call should be joined. - REQUIRED unless call-id is set. MUST NOT be set if call-id is set. + REQUIRED unless call-uri is set. MUST NOT be set if call-uri is set. @@ -2133,14 +2131,14 @@ Inclusion - call-id - Indicates the 3rd party call ID from which the target call should be unjoined. + call-uri + Indicates the 3rd party call URI from which the target call should be unjoined. REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set. mixer-name Indicates the mixer name from which the target call should be unjoined. - REQUIRED unless call-id is set. MUST NOT be set if call-id is set. + REQUIRED unless call-uri is set. MUST NOT be set if call-uri is set. @@ -2156,14 +2154,14 @@ Inclusion - call-id - Indicates the 3rd party call ID to which the target call was joined. + call-uri + Indicates the 3rd party call URI to which the target call was joined. REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set. mixer-name Indicates the mixer name to which the target call was joined. - REQUIRED unless call-id is set. MUST NOT be set if call-id is set. + REQUIRED unless call-uri is set. MUST NOT be set if call-uri is set. @@ -2179,20 +2177,20 @@ Inclusion - call-id - Indicates the 3rd party call ID from which the target call was unjoined. + call-uri + Indicates the 3rd party call URI from which the target call was unjoined. REQUIRED unless mixer-name is set. MUST NOT be set if mixer-name is set. mixer-name Indicates the mixer name from which the target call was unjoined. - REQUIRED unless call-id is set. MUST NOT be set if call-id is set. + REQUIRED unless call-uri is set. MUST NOT be set if call-uri is set. -

            Indicates that a call joined to a mixer with which the controlling party has an events subscription has activated a speech detector, providing its ID.

            +

            Indicates that a call joined to a mixer with which the controlling party has an events subscription has activated a speech detector, providing its URI.

            The <started-speaking/> element MUST be empty.

            The attributes of the <started-speaking/> element are as follows.

            @@ -2202,15 +2200,15 @@ - - + +
            Inclusion
            call-idIndicates the ID of the call which has triggered the speech detector.call-uriIndicates the URI of the call which has triggered the speech detector. REQUIRED
            -

            Indicates that a call joined to a mixer with which the controlling party has an events subscription has ceased activation of a speech detector, providing its ID.

            +

            Indicates that a call joined to a mixer with which the controlling party has an events subscription has ceased activation of a speech detector, providing its URI.

            The <stopped-speaking/> element MUST be empty.

            The attributes of the <stopped-speaking/> element are as follows.

            @@ -2220,15 +2218,15 @@ - - + +
            Inclusion
            call-idIndicates the ID of the call which has triggered the speech detector.call-uriIndicates the URI of the call which has triggered the speech detector. REQUIRED
            -

            Used to give an indication of the identity of a newly created resource, either a call or a component.

            +

            Used to give the address of a newly created resource, either a call or a component.

            The <ref/> element MUST be empty.

            The attributes of the <ref/> element are as follows.

            @@ -2238,8 +2236,8 @@ - - + +
            Inclusion
            idGives the ID of the new resource.uriGives the URI of the new resource. REQUIRED
            @@ -3288,10 +3286,10 @@ - + - Indicates the 3rd party call ID to which the target call should be joined. May not be set if the mixer-name attribute is set. + Indicates the 3rd party call URI to which the target call should be joined. May not be set if the mixer-name attribute is set. @@ -3323,10 +3321,10 @@ - + - Indicates the ID of the call which has triggered the speech detector. + Indicates the URI of the call which has triggered the speech detector. @@ -3340,10 +3338,10 @@ - + - Gives the ID of the new resource. + Gives the URI of the new resource. From a916ad842860b98208b96b90391079f3fa456a75 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 4 Apr 2013 23:31:49 -0300 Subject: [PATCH 154/178] Minor grammar bug --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index eba46535..29027c7d 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -199,7 +199,7 @@
          • Mixing: Typically referred to as an audio "conference"; calls can be joined together so that the participants can hear each other in real-time.
    -

    Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have at least one or more of the following drawbacks:

    +

    Many third-party call control protocols have preceeded Rayo (see Asterisk's AGI/AMI, FreeSWITCH's eventsocket, Microsoft's TAPI, Java's JTAPI, Novell/AT&T's TSAPI, CSTA, etc). None of these protocols is ideal, and all have one or more of the following drawbacks:

    • Totally ground-up wire protocol requiring implementation all the way down to the socket.
    • Platform/vendor/hardware specific - each system implements its own proprietary protocol (in many cases, without a formal published specification) which does not allow easily porting an application from one back-end to another.
      • From ff5662087a10e1cee294890a18afbd0f12833fcc Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 5 Apr 2013 11:21:47 -0300 Subject: [PATCH 155/178] Specify security measures for mixers * Mixers should be internally namespaced within a security zone to allow for naming overlap while preventing security issues * Joining a mixer should return a full URI for the mixer Fixes #49 --- extensions/inbox/rayo.xml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 29027c7d..ec5ca073 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -872,7 +872,10 @@ -

      While calls may generally be joined peer-to-peer in any desirable combination, such an implementation is not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, and MUST broadcast presence to all controlling parties who have calls joined to it before any other events are sent. The server MUST include entity capabilities information in the first presence stanza it sends, in order to advertise the fact that the entity is a mixer, qualified by the node name "urn:xmpp:rayo:mixer:1". A mixer MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

      +

      While calls may generally be joined peer-to-peer in any desirable combination, such an implementation is not necessarily scalable or practical to manage. Rayo, therefore, includes the concept of mixers, which are entities like calls, to which calls or other mixers may be joined in the same way as joining multiple calls directly. A mixer MUST be implicitly created the first time a call attempts to join it, MUST immediately broadcast presence to all controlling parties who have calls joined to it, and must respond to the join command with a reference to the mixer. The server MUST include entity capabilities information in the first presence stanza it sends, in order to advertise the fact that the entity is a mixer, qualified by the node name "urn:xmpp:rayo:mixer:1". A mixer MUST emit events (joined, unjoined) to all controlling parties who have calls joined to it, using the same semantics as joining calls.

      + +

      In order to support friendly-named mixers without causing naming collisions between security zones, a server SHOULD represent a mixer internally using some alternative name scoped to the client's security zone and mapped to the friendly name/URI presented to the client for the emission of events and processing of commands. A server MUST NOT allow clients to interact with mixers allocated within other security zones either by observing their status or media.

      + + id='h7ed2'> + + From e91b4dd60fe6845a9fb174635206c03120cdaa6f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 5 Apr 2013 12:28:28 -0300 Subject: [PATCH 156/178] Initial submission to the XSF should be v0.0.1 --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ec5ca073..d051b543 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -41,8 +41,8 @@ http://voxeolabs.com - 0.1.0 - 2013-02-07 + 0.0.1 + 2013-04-05 bl

      First draft.

             From ba703aff3c269876fab9966b755cce303aa8237f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 5 Apr 2013 18:55:09 -0300 Subject: [PATCH 157/178] Allow for different input result formats Default to NLSML --- extensions/inbox/rayo.xml | 62 +++++++++++++++++++++++++++++++++------ 1 file changed, 53 insertions(+), 9 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index d051b543..accc9d1b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1495,18 +1495,20 @@
    -

    If the media server reports a match to one of the provided grammars, the server MUST present the results of the match to the client by way of match meta-data on a finish complete reason. It MUST provide an NLSML fragment as specified on the match element.

    +

    If the media server reports a match to one of the provided grammars, the server MUST present the results of the match to the client by way of a match document in the format requested by the client. A server MUST be capable of supporting NLSML, and may support other formats.

    - - - - 1 2 3 4 - - + + + + 1 2 3 4 + + + ]]]]> @@ -2523,6 +2525,13 @@ -1 OPTIONAL + + match-content-type + Indicates the required response document format. + Must support at least application/nlsml+xml, but may support others such as application/emma+xml. + application/nlsml+xml + OPTIONAL + @@ -2557,8 +2566,24 @@

    Indicates that the component came to an end due to one of its grammars matching the received input.

    -

    The <match/> element MUST contain a valid NLSML fragment (<result/> element).

    -

    The <match/> element has no attributes.

    +

    The <match/> element MUST contain a valid response document within CDATA.

    +

    The attributes of the <matchr/> element are as follows.

    + + + + + + + + + + + + + + + +
    AttributeDefinitionPossible ValuesDefaultInclusion
    content-typeIndicates the content type of the result document provided as CDATA.A result document content type tokenapplication/nlsml+xmlREQUIRED
     @@ -3839,6 +3864,13 @@ + + + + Indicates the required response document format. + + + @@ -3878,6 +3910,18 @@ Indicates that the component came to an end due to one of its grammars matching the received input. Provides the NLSML result of the grammar match after any symantic processing which may have been performed. See the NLSML spec for details. + + + + + + + Indicates the content type of the result document provided as CDATA. + + + + + From ad91d8ad15b52e126d4fd7521b89d59991abf42d Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 10 Apr 2013 11:25:20 -0300 Subject: [PATCH 158/178] Input component needs recognizer for routing and language to pass to recognizer --- extensions/inbox/rayo.xml | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index accc9d1b..fb9812c1 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2485,7 +2485,14 @@ recognizer - Indicates the name of the particular input processor to be engaged. Usually only applies to speech input, in order to specify the recognition language. + Indicates the name of the particular input processor to be engaged, used only for routing purposes (eg to choose which MRCP profile to invoke). + A token string + none + OPTIONAL + + + language + Specifies the recognition language to the recognizer. Any valid ISO 639‑3 language code en-US OPTIONAL @@ -3822,10 +3829,17 @@ - + + + + Indicates the name of the particular input processor to be engaged, used only for routing purposes (eg to choose which MRCP profile to invoke). + + + + - Indicates the name of the particular input processor to be engaged. Usually only applies to speech input, in order to specify the recognition language. + Specifies the recognition language to the recognizer. From 7c78451dceeb283184f06b4e9b9e3067027876d9 Mon Sep 17 00:00:00 2001 From: James Le Cuirot Date: Wed, 5 Jun 2013 17:07:08 +0100 Subject: [PATCH 159/178] [FEATURE] Allow repeat-times to be 0 for the output to repeat forever --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index fb9812c1..5738c772 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2322,7 +2322,7 @@ repeat-times Indicates the number of times the output should be played. - An integer greater than 0. + A positive integer or 0 to repeat forever. 1 OPTIONAL @@ -3593,7 +3593,7 @@ - + Indicates the number of times the output should be played. From 730f5f85e755cfa2d040c7455fa6b01e0c747c3e Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 12:37:44 -0300 Subject: [PATCH 160/178] Update to version published by XSF --- extensions/inbox/rayo.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index fb9812c1..ddbcf51d 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -8,15 +8,9 @@
    Rayo This specification defines an XMPP protocol extension for the third-party control of telephone calls and other similar media sessions. The protocol includes support for session management/signaling, as well as advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. The protocol serves a different purpose from that of first-party protocols such as Jingle or SIP, and is compatible with those protocols. - - This XMPP Extension Protocol is copyright (c) 2013 by the XMPP Standards Foundation (XSF). - Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. - ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## - In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. - This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). - - xxxx - ProtoXEP + &LEGALNOTICE; + 0327 + Experimental Standards Track Standards Council @@ -40,6 +34,12 @@ jdecastro@voxeo.com http://voxeolabs.com + + 0.1 + 2013-05-06 + psa +

    Initial published version approved by the XMPP Council.

     +     0.0.1 2013-04-05 From f066e006afe8acaf86703dd7a4ee438d2f296357 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 13:33:49 -0300 Subject: [PATCH 161/178] Typo Fixes #58 --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ddbcf51d..03ae53e3 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -52,7 +52,7 @@
    • A Rayo server takes on the role of negotiating a media session between itself and some other endpoint, or between two external endpoints, by way of an implementation-specific means, be that Jingle, SIP, the public-switched telephone network, or anything else. The server may even bridge multiple networks.
      • -
    • The server then presents the Rayo protocol as an interface to a Rayo client, allowing it to monitor and/or exercise third-party control over particular the established media sessions.
      • +
    • The server then presents the Rayo protocol as an interface to a Rayo client, allowing it to monitor and/or exercise third-party control over the established media sessions.
    • The client has the option to accept/reject/answer inbound session requests, request the creation of outbound sessions and monitor their progress, execute media operations such as speech synthesis, speech recognition & recording, and to end sessions.
    From 2d66783da4940f1c5ca1bd41a7ee41c8c9ac57ca Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 13:35:06 -0300 Subject: [PATCH 162/178] Typo Fixes #60 --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 03ae53e3..d02aaa59 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -269,7 +269,7 @@ -

    A Rayo server is an entity which is capable of receiving and intiating calls and being party to their media stream, while exposing a Rayo interface to a client in order to permit control over its calls. The Rayo server may handle calls in any way supported by the implementation, such as SIP, Jingle, etc, and should expose a full XMPP domain at the root level of the service deployment (eg shakespeare.lit).

    +

    A Rayo server is an entity which is capable of receiving and initiating calls and being party to their media stream, while exposing a Rayo interface to a client in order to permit control over its calls. The Rayo server may handle calls in any way supported by the implementation, such as SIP, Jingle, etc, and should expose a full XMPP domain at the root level of the service deployment (eg shakespeare.lit).

    The Rayo server is responsible for keeping track of valid clients, routing calls to the correct potential controlling parties, performing authorization measures on received stanzas, etc.

    For the purposes of this specification, complex server-side deployments such as clusters, proxies, gateways, protocol translators, etc are not considered. Further details of such concepts may be found in their (present or future) relevant specifications.

     From ff49e694d7bf7ac368fd7d288ab68d6a37e557a2 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 13:37:15 -0300 Subject: [PATCH 163/178] Clearer wording Fixes #59 --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index d02aaa59..7eff2a1b 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -82,9 +82,9 @@ ]]> -

    In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate for delegating control of the call, and so has directed an offer event to her 'balcony' resource.

    +

    In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate to be the client to whom the server delegates control of the call, and so has directed an offer event to her 'balcony' resource.

    -

    The client then decides that it is able to handle the incoming call, and so accepts it from the server, thus gaining exclusive control and indicating to the calling party that the call will be processed and that it should ring.

    +

    The client, 'juliet@capulet.lit', then decides that it is able to handle the incoming call, and so accepts it from the server, thus gaining exclusive control and indicating to the calling party that the call will be processed and that it should ring.

    Date: Thu, 6 Jun 2013 13:39:52 -0300 Subject: [PATCH 164/178] Clarify that commands can be sent to components Fixes #63 --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 7eff2a1b..ab7c74ae 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -288,7 +288,7 @@

    Mixers have separate presence from the root domain of the service and its calls and thus appear to be separate entities.

    -

    A Rayo command is a simple combination of request and response and may be issued directly to the service domain, or to a call or a mixer. Commands are executed serially and are generally very short-lived.

    +

    A Rayo command is a simple combination of request and response and may be issued directly to the service domain, a call, a mixer or a component attached to any of the former. Commands are executed serially and are generally very short-lived.

    Components extend the Rayo protocol by providing additional media and call control functionality.

    From ee85d7242f1d547cf90969e1bb93ec50ba0b9616 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 14:54:10 -0300 Subject: [PATCH 165/178] Simplify input complete reasons due to lack of use cases #68 --- extensions/inbox/rayo.xml | 70 +++++---------------------------------- 1 file changed, 8 insertions(+), 62 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ab7c74ae..57c7c3ae 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1479,19 +1479,10 @@ match (indicating that one of the grammars matched the received input).
  • - initial-timeout (indicating that the initial timeout was triggered). + noinput (indicating that no input was received before a timeout was encountered).
  • - inter-digit-timeout (indicating that the inter-digit timeout was triggered). -
    • -
  • - max-silence (indicating that the max-silence timeout was triggered). -
    • -
  • - min-confidence (indicating that the minimum confidence threshold was not reached). -
    • -
  • - no-match (indicating that input was received which did not match any of the specified grammars). + nomatch (indicating that input was received which did not match any of the specified grammars).
    • @@ -2593,28 +2584,10 @@ - -

    Indicates that the component came to an end because the initial timeout was triggered.

    -

    The <initial-timeout/> element MUST be empty.

    -

    The <initial-timeout/> element has no attributes.

    -     - - -

    Indicates that the component came to an end because the inter-digit timeout was triggered.

    -

    The <inter-digit-timeout/> element MUST be empty.

    -

    The <inter-digit-timeout/> element has no attributes.

    -     - - -

    Indicates that the component came to an end because the max-silence timeout was triggered.

    -

    The <max-silence/> element MUST be empty.

    -

    The <max-silence/> element has no attributes.

    -     - - -

    Indicates that the component came to an end because the minimum confidence threshold was not reached.

    -

    The <min-confidence/> element MUST be empty.

    -

    The <min-confidence/> element has no attributes.

    + +

    Indicates that the component came to an end because a timeout was triggered before input was received.

    +

    The <noinput/> element MUST be empty.

    +

    The <noinput/> element has no attributes.

     @@ -3939,37 +3912,10 @@ - - - - Indicates that the component came to an end because the initial timeout was triggered. - - - - - - - - - Indicates that the component came to an end because the inter-digit timeout was triggered. - - - - - - - - - Indicates that the component came to an end because the max-silence timeout was triggered. - - - - - - + - Indicates that the component came to an end because the minimum confidence threshold was not reached. + Indicates that the component came to an end because a timeout was triggered before input was received. From d7909183147aad40efada4345ba1d33e09643a38 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 14:56:58 -0300 Subject: [PATCH 166/178] Switch input mode "speech" to "voice" to match SRGS #69 --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 57c7c3ae..820b7998 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2463,7 +2463,7 @@ mode The method by which to collect input. - any|dtmf|speech + any|dtmf|voice any OPTIONAL @@ -3790,7 +3790,7 @@ - + From 5da12a0b6678fba4e4837f2fca22007539bdec8f Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 6 Jun 2013 15:02:45 -0300 Subject: [PATCH 167/178] A ref example had an old ID attribute Fixes #66 --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 820b7998..a2df27cf 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -143,7 +143,7 @@ to='juliet@capulet.lit/balcony' type='result' id='j9d3j'> - + ]]>     From 7351b4b478a613a875c4d2be33842f1666d68639 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 21 Jun 2013 13:08:18 -0300 Subject: [PATCH 168/178] Typos --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 79921287..d0f32d55 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2565,8 +2565,8 @@

    Indicates that the component came to an end due to one of its grammars matching the received input.

    The <match/> element MUST contain a valid response document within CDATA.

    -

    The attributes of the <matchr/> element are as follows.

    - +

    The attributes of the <match/> element are as follows.

    +
    From 59dfadd3407e862ab511233ee8da95f4deba2885 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 12 Jul 2013 09:52:32 -0300 Subject: [PATCH 169/178] Optionally include platform-specific end reason codes --- extensions/inbox/rayo.xml | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index d0f32d55..62e67330 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1943,7 +1943,21 @@

    The <end/> element has no attributes.

    -

    The following are valid end reason elements. Unless otherwise stated, they all MUST be empty, and they do not have any attributes.

    +

    The following are valid end reason elements. Unless otherwise stated, they all MUST be empty.

    + +

    The attributes of the end reason element are as follows.

    +
    Attribute Definition
    + + + + + + + + + + +
    AttributeDefinitionInclusion
    codeA platform-specific end code. This could be a SIP code, ITU-T Q.850 or some other system. The code may be an arbitrary string.OPTIONAL
    @@ -2990,6 +3004,16 @@ + + + + + A platform-specific end code. This could be a SIP code, ITU-T Q.850 or some other system. The code may be an arbitrary string. + + + + + @@ -3000,42 +3024,42 @@ - + Indication that the call ended due to a normal hangup by the remote party. - + Indication that the call ended due to a normal hangup triggered by a hangup command. - + Indication that the call ended due to a timeout in contacting the remote party. - + Indication that the call ended due to being rejected by the remote party subsequent to being accepted. - + Indication that the call ended due to being rejected by the remote party before being accepted. - + Indication that the call ended due to a system error. From 7405110d81de6775ca4f9ca9153a8ca000448f8e Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 12 Jul 2013 16:02:01 -0300 Subject: [PATCH 170/178] Rename end code to platform_code to indicate ad-hoc nature --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 62e67330..7d77a46e 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1953,7 +1953,7 @@ Inclusion - code + platform_code A platform-specific end code. This could be a SIP code, ITU-T Q.850 or some other system. The code may be an arbitrary string. OPTIONAL @@ -3005,7 +3005,7 @@ - + A platform-specific end code. This could be a SIP code, ITU-T Q.850 or some other system. The code may be an arbitrary string. From 161a89efb294d544fac89fa7b31f0bb58fb36b52 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Fri, 12 Jul 2013 16:21:10 -0300 Subject: [PATCH 171/178] Dashes in attribute names --- extensions/inbox/rayo.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 7d77a46e..ef546332 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1953,7 +1953,7 @@ Inclusion - platform_code + platform-code A platform-specific end code. This could be a SIP code, ITU-T Q.850 or some other system. The code may be an arbitrary string. OPTIONAL @@ -3005,7 +3005,7 @@ - + A platform-specific end code. This could be a SIP code, ITU-T Q.850 or some other system. The code may be an arbitrary string. From 4bd3cdd910496c3d182f28541b67ab8cdcad7208 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Thu, 8 Aug 2013 12:16:28 -0300 Subject: [PATCH 172/178] Be more clear about behaviour in cases of 0 PCPs --- extensions/inbox/rayo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index ef546332..06a86c60 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -550,7 +550,7 @@ -

    When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it SHOULD then remove any parties whom it can identify as being temporarily inappropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available). If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call with a 'decline' reason.

    +

    When the system receives a call from one of its connected networks, it MUST then expose that requested session to Rayo clients. It SHOULD use an implementation-specific routing mechanism to map incoming calls to some set of registered JIDs which are considered appropriate controlling parties. From this set, it SHOULD then remove any parties whom it can identify as being temporarily inappropriate for control (either unavailable based on presence, under too much load, or any other metric which the server has available). If, as a result, the set of Potentially Controlling Parties is empty, the server MUST reject the call indicating that the requested service was unavailable.

    If the server can identify active Potential Controlling Parties, it MUST offer them control of the call simultaneously. The server must broadcast an offer on behalf of the call to all Potential Controlling Parties, using applicable to/from/header data from the incoming session. The server MUST also include entity capabilities information in the presence stanza containing the offer, in order to advertise the fact that the entity is a call, qualified by the node name "urn:xmpp:rayo:call:1".

    Date: Wed, 2 Oct 2013 12:43:31 -0300 Subject: [PATCH 173/178] Add first draft of Rayo-CPA specification --- extensions/inbox/rayo-cpa.xml | 330 ++++++++++++++++++++++++++++++++++ extensions/inbox/rayo.xml | 3 +- 2 files changed, 332 insertions(+), 1 deletion(-) create mode 100644 extensions/inbox/rayo-cpa.xml diff --git a/extensions/inbox/rayo-cpa.xml b/extensions/inbox/rayo-cpa.xml new file mode 100644 index 00000000..2374fc8c --- /dev/null +++ b/extensions/inbox/rayo-cpa.xml @@ -0,0 +1,330 @@ + + +%ents; +]> + + +
    + Rayo CPA + This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for performing Call Progress Analysis on a call under the control of a Rayo client. + &LEGALNOTICE; + NOT_YET_ASSIGNED + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0327 Rayo + + + + NOT_YET_ASSIGNED + + Ben + Langfeld + ben@langfeld.me + ben@langfeld.me + http://langfeld.me + + + 0.0.1 + 2013-10-o2 + bl +

    First draft.

     +     +
    + +

    Rayo allows for the third-party control of media sessions such as telephone calls. A common requirement in telephony applications is to establish the progress characteristics of the session, such as dtmf, fax or modem tones, or to differentiate between a human and an answering machine. This specification extends the core Rayo specification, and specifically its Input component to describe a protocol for establishing such progress analysis and gathering its results.

    +     + + +
    + +
    CPA
    +
    Call progress analysis.
    +     +
    +     +     + +

    This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise.

    + +

    CPA is achieved as a special case of the core input component. All rules regarding component execution and the input component in particular apply from the core specification. When a call's controlling party wishes to begin detection of signals from the suported set, it SHOULD begin an input component with the mode attribute set as 'cpa'. The provided grammar MUST be a special-case of an SRGS grammar of the format described below. If a Rayo server supports this specification, it MUST parse the provided grammar and invoke its supported CPA function using the parameters provided from the grammar; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification.

    + + + + + + + + + + + + + + + + ]]]]> + + + + ]]> + +

    The server MUST validate that it has appropriate resources/mechanisms to collect the requested signals before acknowledging the component creation.

    + + +

    If the meta-attribute named 'terminate' is set to true in the grammar, the component MUST terminate on the first signal match it detects. If it is set to false, signals MUST be reported as events until the component is instructed to stop.

    + + + + + ]]> +     + + +

    The input completion reason MUST be one of the supported reasons from the core specification or a signal, indicating that the CPA engine detected one of the requested signals. Any signals other than those requested by the input grammar should be ignored.

    + + + + + + + ]]> +     +     + + +

    The grammar format to declare the signal types of interest and the parameters which apply to their detection is a special case of SRGS. The requested signal types are specified as SRGS rule references where the URI is one of those listed in the following list of allowed signal types. Parameters to modify their detection are supplied as SRGS metadata, and the names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described abov.

    +     + + +

    Describes a detected signal.

    +

    The attributes of the <grammar/> element are as follows.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDefinitionPossible ValuesDefaultInclusion
    typeIndicates the type of signal detected.Any URI value from the listed signal typesnoneREQUIRED
    durationIndicates the duration of the received signal in millisecondsAn integer value in milliseconds.noneOPTIONAL
    valueIndicates the value of the signal received if applicable.For dtmf tones it is the digit detected, for speech may be human|machine|notsure and for beeps may be a frequency in Hz.noneOPTIONAL
    +     + + +

    Signal types may be one of the following:

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    URIDescription
    urn:xmpp:rayo:cpa:beep:1Detect a beep.
    urn:xmpp:rayo:cpa:dtmf:1Detect DTMF tones.
    urn:xmpp:rayo:cpa:speech:1Detect speech and decide human or machine.
    urn:xmpp:rayo:cpa:fax:1Detect a fax tone.
    urn:xmpp:rayo:cpa:fax-cng:1Detect a fax CNG tone.
    urn:xmpp:rayo:cpa:ring:1Detect a ringing tone.
    urn:xmpp:rayo:cpa:sit:1Detect a Special Information Tone.
    urn:xmpp:rayo:cpa:modem:1Detect a modem tone.
    urn:xmpp:rayo:cpa:offhook:1Detect an off-hook tone.
    + +     + +

    STRONGLY RECOMMENDED.

    +     + +

    If a Rayo server supports Rayo CPA, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo|cpa:0" &VNOTE; in response to a &xep0030; information request.

    + + + + ]]> + + + + + + + ]]> +

    In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

    +     + +

    A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions.

    +     + +

    None

    +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:rayo:cpa:1
      • +
    • urn:xmpp:rayo:cpa:beep:1
      • +
    • urn:xmpp:rayo:cpa:dtmf:1
      • +
    • urn:xmpp:rayo:cpa:speech:1
      • +
    • urn:xmpp:rayo:cpa:fax:1
      • +
    • urn:xmpp:rayo:cpa:fax-cng:1
      • +
    • urn:xmpp:rayo:cpa:ring:1
      • +
    • urn:xmpp:rayo:cpa:sit:1
      • +
    • urn:xmpp:rayo:cpa:modem:1
      • +
    • urn:xmpp:rayo:cpa:offhook:1
      • +
    +

    The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

    +     + +

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    +     +     + + + + + + + + The protocol documented by this schema is defined at http://rayo.org/xep + + + + + + + + Describes a detected signal. + + + + + + + + Indicates the type of signal detected. + + + + + + + + + + + + + + + + + + + + Indicates the duration of the received signal in milliseconds + + + + + + + Indicates the value of the signal received if applicable. For dtmf tones it is the digit detected, for speech may be human|machine|notsure and for beeps may be a frequency in Hz. + + + + + + + + ]]> + + + +

    The authors would like to acknowledge the input of teams at Tropo Inc, Mojo Lingo and Grasshopper in the development of this specification.

    + +

    Specific individuals who have contributed to the specification or to software significant to its completion include:

    +
      +
    • Ben Langfeld
      • +
    • Chris Rienzo
      • +
    • Martín Pérez
      • +
    +     +     diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index 06a86c60..fe6820c2 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -2477,7 +2477,7 @@ mode The method by which to collect input. - any|dtmf|voice + any|dtmf|voice|cpa any OPTIONAL @@ -3816,6 +3816,7 @@ +     From 4070e900df3e05b6783d707c70eda497c25f7dad Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 2 Oct 2013 12:45:11 -0300 Subject: [PATCH 174/178] Fix typo --- extensions/inbox/rayo-cpa.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo-cpa.xml b/extensions/inbox/rayo-cpa.xml index 2374fc8c..0337cb02 100644 --- a/extensions/inbox/rayo-cpa.xml +++ b/extensions/inbox/rayo-cpa.xml @@ -193,7 +193,7 @@ Detect an off-hook tone. - +

    STRONGLY RECOMMENDED.

    From ed81fe9528158e6878992d2c27695a28c34c8bb9 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 2 Oct 2013 12:48:57 -0300 Subject: [PATCH 175/178] Formatting --- extensions/inbox/rayo-cpa.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/extensions/inbox/rayo-cpa.xml b/extensions/inbox/rayo-cpa.xml index 0337cb02..c8da0190 100644 --- a/extensions/inbox/rayo-cpa.xml +++ b/extensions/inbox/rayo-cpa.xml @@ -30,7 +30,7 @@ 0.0.1 - 2013-10-o2 + 2013-10-02 bl

    First draft.

         @@ -51,7 +51,9 @@

    This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise.

    -

    CPA is achieved as a special case of the core input component. All rules regarding component execution and the input component in particular apply from the core specification. When a call's controlling party wishes to begin detection of signals from the suported set, it SHOULD begin an input component with the mode attribute set as 'cpa'. The provided grammar MUST be a special-case of an SRGS grammar of the format described below. If a Rayo server supports this specification, it MUST parse the provided grammar and invoke its supported CPA function using the parameters provided from the grammar; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification.

    +

    CPA is achieved as a special case of the core input component. All rules regarding component execution and the input component in particular apply from the core specification. When a call's controlling party wishes to begin detection of signals from the suported set, it SHOULD begin an input component with the mode attribute set as 'cpa'.

    + +

    The provided grammar MUST be a special-case of an SRGS grammar of the format described below. If a Rayo server supports this specification, it MUST parse the provided grammar and invoke its supported CPA function using the parameters provided from the grammar; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification.

    Date: Wed, 2 Oct 2013 15:31:44 -0300 Subject: [PATCH 176/178] Use special URIs for CPA & fix examples --- extensions/inbox/rayo-cpa.xml | 36 +++++++++-------------------------- 1 file changed, 9 insertions(+), 27 deletions(-) diff --git a/extensions/inbox/rayo-cpa.xml b/extensions/inbox/rayo-cpa.xml index c8da0190..aa40ad6d 100644 --- a/extensions/inbox/rayo-cpa.xml +++ b/extensions/inbox/rayo-cpa.xml @@ -53,33 +53,16 @@

    CPA is achieved as a special case of the core input component. All rules regarding component execution and the input component in particular apply from the core specification. When a call's controlling party wishes to begin detection of signals from the suported set, it SHOULD begin an input component with the mode attribute set as 'cpa'.

    -

    The provided grammar MUST be a special-case of an SRGS grammar of the format described below. If a Rayo server supports this specification, it MUST parse the provided grammar and invoke its supported CPA function using the parameters provided from the grammar; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification.

    +

    The grammars supplied determine the types of signal detected and parameters applied to their detection. The grammars MUST be referenced by URI in the format described below. If a Rayo server supports this specification, it MUST invoke its supported CPA function using the parameters provided from the grammars; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification.

    - - - - - - - - - - - - - - ]]]]> - + + ]]> @@ -89,10 +72,9 @@

    If the meta-attribute named 'terminate' is set to true in the grammar, the component MUST terminate on the first signal match it detects. If it is set to false, signals MUST be reported as events until the component is instructed to stop.

    - - + + ]]>     @@ -105,7 +87,7 @@ to='juliet@capulet.lit/courtyard' type='unavailable'> - + ]]>     @@ -113,7 +95,7 @@     -

    The grammar format to declare the signal types of interest and the parameters which apply to their detection is a special case of SRGS. The requested signal types are specified as SRGS rule references where the URI is one of those listed in the following list of allowed signal types. Parameters to modify their detection are supplied as SRGS metadata, and the names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described abov.

    +

    The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from the following list of allowed signal types, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described abov.

     From 7b1e435dd3e412026b493f8a09d3a13acbb97d24 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 2 Oct 2013 15:40:20 -0300 Subject: [PATCH 177/178] Typo --- extensions/inbox/rayo-cpa.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/inbox/rayo-cpa.xml b/extensions/inbox/rayo-cpa.xml index aa40ad6d..83bd8d0f 100644 --- a/extensions/inbox/rayo-cpa.xml +++ b/extensions/inbox/rayo-cpa.xml @@ -95,7 +95,7 @@     -

    The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from the following list of allowed signal types, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described abov.

    +

    The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from the following list of allowed signal types, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described above.

     From 8d0b6507b416e56948daa5596c0399f818e6e469 Mon Sep 17 00:00:00 2001 From: Ben Langfeld Date: Wed, 2 Oct 2013 15:50:40 -0300 Subject: [PATCH 178/178] Allow persistent input components emitting matches as intermediate events --- extensions/inbox/rayo-cpa.xml | 6 +++--- extensions/inbox/rayo.xml | 29 ++++++++++++++++++++++++++++- 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/extensions/inbox/rayo-cpa.xml b/extensions/inbox/rayo-cpa.xml index 83bd8d0f..04e06bd9 100644 --- a/extensions/inbox/rayo-cpa.xml +++ b/extensions/inbox/rayo-cpa.xml @@ -61,7 +61,7 @@ type='set' id='h7ed2'> - + @@ -70,7 +70,7 @@

    The server MUST validate that it has appropriate resources/mechanisms to collect the requested signals before acknowledging the component creation.

    -

    If the meta-attribute named 'terminate' is set to true in the grammar, the component MUST terminate on the first signal match it detects. If it is set to false, signals MUST be reported as events until the component is instructed to stop.

    +

    As per the core input component specification, the input component may return signals as intermediate events if the 'persistent' option is true.

    @@ -95,7 +95,7 @@     -

    The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from the following list of allowed signal types, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described above.

    +

    The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from the following list of allowed signal types, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific.

     diff --git a/extensions/inbox/rayo.xml b/extensions/inbox/rayo.xml index fe6820c2..3f4faee1 100644 --- a/extensions/inbox/rayo.xml +++ b/extensions/inbox/rayo.xml @@ -1469,7 +1469,20 @@ -

    The input component does not provide any intermediate events.

    +

    If the media server reports a match to one of the provided grammars, and the 'persistent' option is true, the server MUST present the results of the match to the client by way of a match document, in the format requested by the client, as an intermediate event. A server MUST be capable of supporting NLSML, and may support other formats.

    + + + + + 1 2 3 4 + + + ]]]]> + + + ]]>     @@ -2488,6 +2501,13 @@ none OPTIONAL + + persistent + Indicates the input collection should not terminate on a grammar match but rather continue to match indefinitely. + Boolean + false + OPTIONAL + recognizer Indicates the name of the particular input processor to be engaged, used only for routing purposes (eg to choose which MRCP profile to invoke). @@ -3827,6 +3847,13 @@     + + + + Indicates the input collection should not terminate on a grammar match but rather continue to match indefinitely. + + +