diff --git a/xep-0327.xml b/xep-0327.xml index e720d983..15c0611f 100644 --- a/xep-0327.xml +++ b/xep-0327.xml @@ -31,10 +31,16 @@ Jose de Castro - jdecastro@voxeo.com - jdecastro@voxeo.com - http://voxeolabs.com + jdecastro@tropo.com + jdecastro@tropo.com + http://tropo.com + + 0.6 + 2015-04-29 + bl +

Changes to address Last Call feedback.

 + 0.5 2014-09-23 @@ -410,7 +416,7 @@

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.

+

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.

- -

STRONGLY RECOMMENDED.

- -

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.

+

If an entity supports Rayo, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo:1" &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.

- + ]]> @@ -2953,7 +2956,7 @@ Art thou not Romeo, and a Montague? to='call.rayo.org' type='result'> - + ]]> @@ -4382,10 +4385,10 @@ Art thou not Romeo, and a Montague?
  • 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 and FreeSWITCH EventSocket, native to FreeSWITCH (mod_rayo), as well as client library implementations in Node/CoffeeScript and Python. + Initial development of the Rayo specification and its reference implementation was sponsored by Tropo (formerly 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, and Grasshopper in expanding the implementation landscape.

    +

    The authors would like to acknowledge the input of teams at Tropo (formerly 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: