-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XEP-0353: Jingle Message Initiation -> Call Invite Message #1155
Conversation
- Restrict to calls only, removing non-call Jingle functionality - Support multiple and non-Jingle session establishment methods - Adjust title and namespace - Define Jingle-independent set of conditions for <reason>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a couple of questions inline.
Overall I do not think bringing groupchat into this is a good idea.
<example caption="Initiator Sends Intent Message"><![CDATA[ | ||
<p> | ||
All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" when | ||
sent in a direct message or of type="groupchat" when sent to a group chat |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: making this a list will be easier to read
<message from='[email protected]/orchard' | ||
to='[email protected]' | ||
type='chat'> | ||
<propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'> | ||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/> | ||
<propose xmlns='urn:xmpp:call-message:1' id='a73sjjvkla37jfea' audio='true' video='false' multi='false'> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we usually start counting namespaces at :0, no?
<example caption="One of Responder's Resources Accepts the Call"><![CDATA[ | ||
<message from='[email protected]/phone' | ||
to='[email protected]' | ||
type='chat'> | ||
<accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/> | ||
<accept xmlns='urn:xmpp:call-message:1' id='a73sjjvkla37jfea'> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: the first id is obsolete here, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The id
of <accept>
is referring to the id
of a <propose>
, the sid
of the <jingle>
element in <accept>
is indeed redundant, as it is the reflected element from the <propose>
message.
<p>Next, the device from which Juliet accepted the call sends directed presence to Romeo for the reasons described above.</p> | ||
<p> | ||
Juliet's server broadcasts this accept message to all of her resources (as | ||
described in &xep0280; or, e.g. &xep0045;, respectively), which stop ringing, and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how MUC plays a role in this part.
<busy/> | ||
<text>Busy</text> | ||
</reason> | ||
<reject xmlns='urn:xmpp:call-message:1' id='a73sjjvkla37jfea'> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you put the sid into a subelement above you'll need to do this here too.
<example caption="Initiator Sends Finish Message"><![CDATA[ | ||
<p> | ||
This protocol in conjunction with &xep0280; and &xep0313; or appropriate | ||
groupchat protocols (like &xep0045;) allows all devices of all involved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how this solves a problem in MUC where the full JIDs are known.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what you mean here. Synchronizing the call state via messages works independently of full JIDs being used in MUCs or not. MUCs do however help with synchronization by providing message history (although nowadays we typically use MAM there as well) and forwarding the messages to all other participating resources in the room (which include your own other devices).
@fippo I guess inviting a group of people to a call is a feature we want, no? Do you think this should always happen with a bunch of direct messages instead of a groupchat message? PS: Based on feedback outside GitHub I'll also rephrase a few bits that maybe were a bit unclear. |
Seems to have conflicts. |
Larger parts of the functionality I aimed to get added to 0353 through this PR (mostly related to group calls and invites to external calls) is now provided through 0482. To avoid further confusion, I'm closing this one. If anyone feels like they still want to get parts of this into 0353, you're always open to take it. |
<reason>
Rendered: https://larma.de/xeps/xep-0353.html
Diff: https://larma.de/xeps/xep-0353-diff.html