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@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.
