[Standards] LAST CALL: XEP-0327 (Rayo)

Philipp Hancke fippo at goodadvice.pages.de
Mon Apr 6 18:10:56 UTC 2015


Am 06.04.2015 um 07:26 schrieb XMPP Extensions Editor:
> This message constitutes notice of a Last Call for comments on XEP-0327 (Rayo).
>
> 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 2015-04-17.
>
> 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 
(http://www.ecma-international.org/publications/files/ECMA-TR/TR-087.pdf) over 
XMPP.

> 3. Do you plan to implement this specification in your code? If not, why not?

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?

No.

> 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 :-(
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.


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.


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.

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.

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.
Lance says this should use MUC.

It might be too late to fix that, depending on how widely this is 
deployed. And I think this spec still solves a problem worth solving.



More information about the Standards mailing list