[Standards] LAST CALL: XEP-0327 (Rayo)
ben at langfeld.me
Tue Apr 7 00:17:55 UTC 2015
On 6 April 2015 at 15:10, Philipp Hancke <fippo at goodadvice.pages.de> wrote:
> Am 06.04.2015 um 07:26 schrieb XMPP Extensions Editor:
>> This message constitutes notice of a Last Call for comments on XEP-0327
>> Abstract: 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.
>> URL: http://xmpp.org/extensions/xep-0327.html
>> This Last Call begins today and shall end at the close of business on
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards at xmpp.org discussion list:
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack
>> or to clarify an existing protocol?
> Yes, it adds a way to do third-party call control. Which is certainly
> useful for enterprise/unified communications applications.
> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
> Yes. It is certainly better than doing something like uaCSTA (
> over XMPP.
I'll note as a preface to my below comments that CSTA is somewhat of a
motivation for Rayo being the way it is: stupidly simple. CSTA had the ECMA
treatment and turned into the monster that it is, which no-one with a
turnover of < $100MM can realistically implement properly.
CSTA is arguably a much more capable protocol set than Rayo, and that's
just fine by me. Rayo tries to go to the other extreme, resisting such
treatment as is stereotypical of a standards body in order to remain
realistic to implement. My responses to these and possible future comments
will reflect this goal. Please keep this in mind :)
> 3. Do you plan to implement this specification in your code? If not, why
> No. Mostly because I'm not involved with 3pcc anymore.
> So reviewing it with my council hat on.
> 4. Do you have any security concerns related to this specification?
> 5. Is the specification accurate and clearly written?
> couple of style issues... i've been sitting on some of those items for
> almost two years :-(
Thanks for the feedback Philipp :)
> It mostly concerns two things:
> 1) the use of caps
> 2) the use of presence
> Example 1 uses node='urn:xmpp:rayo:call:1' -- this seems odd, this should
> typically contain the client's node and not the urn of the specification.
> Together with the text in 6.2.2 this looks like an invalid use of caps to
> me. I'd suggest removing this, this might require changes to the
> registration process in example 12.
This was introduced at
I would love to hear alternative suggestions for identifying the type of a
Rayo entity (call or mixer).
> The use of directed presence is somewhat odd, I think this should be a
> <message/>. The rationale for this seems to be having the presence track
> the session status and allowing the call control server to notice if the
> client closed its connected to the server unexpectedly.
I figure you mean for an <offer/>? This is the point at which a new call
entity comes online on the network, in much the same way as an IM user's
resource comes online, and such a change in entity presence naturally fits
with <presence/>. I'm not sure why this would be considered a message.
If you mean for client registration (6.1), see below.
> 6.1: the rationale for using presence and <show/> here is that subsequent
> presence broadcasts which change the <show/> will also be sent to the rayo
> server? If so then (surprise) it doesn't work due to the way
> https://tools.ietf.org/html/rfc6121#section-4.4.2 is written (surprise!)
> It's not clear to me if there is a presence subscription between the
> client and the rayo server.
This functionality generally exists to permit a client to quiesce on
shutdown. Adhearsion's behaviour is to send DND presence on SIGTERM, in
order that the Rayo server not send it any new calls. It then waits for
existing calls to clear, before finally shutting down. Additional SIGTERMs
progress through the shutdown process faster, rejecting any new calls sent
by a leaky server, and eventually hanging up existing calls before shutting
It is intended that a presence subscription be created for the purpose you
describe above, but I agree this section could do with clarification. I
would love to hear suggestions for how we might make that clearer.
> 6.2.1 Outbound Call: the link for dial command is broken.
> Example 22: I don't think using presence for this is appropriate. Here and
> e.g. example 44. Active speaker detection is NOT a presence.
All state changes for an entity are signalled using a change to presence
like this. Presence is used as a generic event package. Alternative
proposals welcome that cover all such cases, but example 22 is not
sufficiently different from the rest of the protocol to warrant specific
Again, these are events like any other, indicating a change in state of the
resource. Thinking about it, this case is *somewhat* similar to XEP-0085,
except that they are aggregated across entities at the mixer level and then
disambiguated via an attribute. Again though, I don't think this is
sufficiently different from other events to warrant specific treatment.
> I think the whole presence stuff should work in a different way. The
> client should have a directed presence exchange with the rayo server. And
> inside that <iq/> or <message><pubsub/></message> should be used.
Why do you think it should work differently? I'm happy for it to do so if
there's a strong motivation, but I've yet to hear a convincing argument
against the current scheme.
IQ is used for command execution. IQ doesn't seem to jive with the idea of
an event, though. I could perhaps learn to live with these being PubSub,
but that's a humongous dependency for what is currently a very simple
> Lance says this should use MUC.
A dependency on XEP-0045 would kill this specification. I have no desire to
go down that road.
> It might be too late to fix that, depending on how widely this is
We would have to bump the protocol version (which I guess a move to Draft
would to anyway, to :1) and be careful about allowing a smooth upgrade
path, but it's not absolutely out of the question. I don't, however, want
to go down a rabbit hole without a particularly good reason.
> And I think this spec still solves a problem worth solving.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards