mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
Port version 0.5 to :0 namespace and introduce <ringing/>
This commit is contained in:
Thilo Molitor
parent
afd9c08a3a
commit
8cd1320ddc
154
xep-0353.xml
154
xep-0353.xml
@ -27,6 +27,14 @@
|
||||
&fippo;
|
||||
&stpeter;
|
||||
&tmolitor;
|
||||
<revision>
|
||||
<version>0.6.0</version>
|
||||
<date>2022-01-29</date>
|
||||
<initials>tm</initials>
|
||||
<remark>
|
||||
Port version 0.5 to :0 namespace and improve tie-breaking section
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.5.0</version>
|
||||
<date>2022-01-05</date>
|
||||
@ -106,12 +114,12 @@
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<p>All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; <store/> hints.</p>
|
||||
<section2 topic='Indicating Intent to Start a Session' anchor='intent'>
|
||||
<p>In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.</p>
|
||||
<p>In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:0' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.</p>
|
||||
<example caption="Initiator Sends Intent Message"><![CDATA[
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
|
||||
</propose>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
@ -127,16 +135,29 @@
|
||||
node='http://psi-im.org'
|
||||
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
|
||||
</presence>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Indicating a Ringing Device' anchor='ring'>
|
||||
<p>Upon receiving the <propose/> message, the responder's various devices will start "ringing" and indicate so by sending a message to the bare JID of the initiator containing a <ringing/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.</p>
|
||||
<p>This makes it possible to reflect the real state of the call in the UI and therefore comprises for better UX. It also somewhat compensates for the (intentionally) missing discovery of this protocol.</p>
|
||||
<example caption="One of Responder's Resources Reports it is Ringing"><![CDATA[
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<ringing xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Disavowing Intent to Start a Session' anchor='retract'>
|
||||
<p>It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element specifying the same session ID.</p>
|
||||
<p>The <retract/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see <link url="#security">Security Considerations</link> below for details and rationale).</p>
|
||||
<example caption="Initiator Sends Stop Message"><![CDATA[
|
||||
<p>It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.</p>
|
||||
<p>The <retract/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see <link url="#security">Security Considerations</link> below for details and rationale).</p>
|
||||
<p>In conjunction with &xep0313; upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to <link url="#proceed">accept the intent to start a session</link>.</p>
|
||||
<example caption="Initiator Sends Retract Message"><![CDATA[
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<retract xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<retract xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<cancel/>
|
||||
<text>Retracted</text>
|
||||
@ -145,21 +166,20 @@
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>In conjunction with &xep0313; upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to <link url="#accept">accept the intent to start a session</link>.</p>
|
||||
</section2>
|
||||
<section2 topic='Accepting Intent to Start a Session' anchor='accept'>
|
||||
<p>Upon receiving the intent message, the responder's various devices will "ring" and the responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.</p>
|
||||
<p>Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <accept/> element specifying the session ID of the original <propose/> message.</p>
|
||||
<section2 topic='Accepting Intent to Start a Session' anchor='proceed'>
|
||||
<p>The responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.</p>
|
||||
<p>Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <proceed/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.</p>
|
||||
<example caption="One of Responder's Resources Accepts the Call"><![CDATA[
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/>
|
||||
<proceed xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Juliet's server broadcasts this accept message to all of her resources (as described in &xep0280;), which stop ringing, and to all of Romeo's resources (as described in &rfc6121;). Romeo's resources that did not send the <propose/> can use this &MESSAGE; stanza to update their UI or choose to ignore this &MESSAGE; stanza altogether.</p>
|
||||
<p>Next, the device from which Juliet accepted the call sends directed presence to Romeo for the reasons described above.</p>
|
||||
<p>Next, the device from which Juliet accepted the call SHOULD also send directed presence to Romeo if the two entities do not already share presence information, for the reasons described above.</p>
|
||||
<example caption="Responder Sends Directed Presence"><![CDATA[
|
||||
<presence from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example/orchard'>
|
||||
@ -171,14 +191,14 @@
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Rejecting Intent to Start a Session' anchor='reject'>
|
||||
<p>Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a &MESSAGE; stanza containing a <reject/> element specifying the session ID of the original <propose/> message to the bare JID of Romeo.</p>
|
||||
<p>The <reject/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. The <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see <link url="#security">Security Considerations</link> below for details and rationale).</p>
|
||||
<p>Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a &MESSAGE; stanza containing a <reject/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message to the bare JID of Romeo.</p>
|
||||
<p>The <reject/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. If given, the <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see <link url="#security">Security Considerations</link> below for details and rationale).</p>
|
||||
<p>In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in <link url="#tie-break-1">Tie Breaking</link>.</p>
|
||||
<example caption="One of Responder's Resources Rejects the Call"><![CDATA[
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<reject xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<reject xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<busy/>
|
||||
<text>Busy</text>
|
||||
@ -198,7 +218,7 @@
|
||||
<jingle xmlns='urn:xmpp:jingle:1'
|
||||
action='session-initiate'
|
||||
initiator='romeo@montague.example/orchard'
|
||||
sid='a73sjjvkla37jfea'>
|
||||
sid='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<content creator='initiator' name='voice'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
|
||||
<payload-type id='96' name='speex' clockrate='16000'/>
|
||||
@ -240,14 +260,14 @@
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Finishing a Started Session' anchor='finish'>
|
||||
<p>This protocol in conjunction with &xep0280; and &xep0313; allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties MUST send a message stanza containing a <finish/> element specifying the same session ID as in <link url='#accept'>Accept</link> to the bare jid of the other party.</p>
|
||||
<p>This protocol in conjunction with &xep0280; and &xep0313; allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties SHOULD send a message stanza containing a <finish/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the same session ID as in <link url='#proceed'>proceed</link> to the bare jid of the other party.</p>
|
||||
<p>Letting both involved parties send the <finish/> element makes sure we have the correct state in MAM archives etc. even if one client suddenly looses connectivity/power. It even makes possible for a client to determine if the call is still deemed "running" by the other party if it manages to recover from connectivity loss — before the other party runs into a timeout and sends a <finish/> — to recover the session or formally terminate the call (by ending the Jingle session and sending a <finish/> message itself). See <link url="#tie-break-2">Tie Breaking</link> for more infos on this and similar scenarios.</p>
|
||||
<p>The <finish/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <success/>, but implementations MAY use other conditions if deemed more appropriate (see <link url="#security">Security Considerations</link> below for details and rationale).</p>
|
||||
<p>The <finish/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <success/> or <expired/>, but implementations MAY use other conditions like <connectivity-error/> if deemed more appropriate (see <link url="#security">Security Considerations</link> below for details and rationale).</p>
|
||||
<example caption="Initiator Sends Finish Message"><![CDATA[
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<success/>
|
||||
<text>Success</text>
|
||||
@ -260,7 +280,7 @@
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<success/>
|
||||
<text>Success</text>
|
||||
@ -272,15 +292,17 @@
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic="Tie Breaking" anchor="tie-breaking">
|
||||
<p>It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification MUST implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of &xep0166;.)</p>
|
||||
<p>It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification SHOULD implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of &xep0166;.)</p>
|
||||
<section2 topic='No existing session' anchor='tie-break-1'>
|
||||
<p>In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of &rfc4790; (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action). The party that receives the <propose/> action with the lower of the two session IDs MUST respond with an <accept/> or <reject/> mesage like it would normally do for a <propose/> message, and the party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.</p>
|
||||
<p>In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of &rfc4790; (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action).</p>
|
||||
<p>The party that receives the <propose/> action with the lower of the two session IDs MUST send a <retract/> message for the higher session ID to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/> and then eventually respond with an <proceed/> or <reject/> mesage like it would normally do for a received <propose/> message.</p>
|
||||
<p>The party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.</p>
|
||||
<example caption="Tie break in propose state"><![CDATA[
|
||||
<!-- lower session ID -->
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
|
||||
</propose>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
@ -290,7 +312,7 @@
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:1' id='b73sjjvkla37jfea'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:0' id='fecbea35-08d3-404f-9ec7-2b57c566fa74'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
|
||||
</propose>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
@ -300,7 +322,21 @@
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<reject xmlns='urn:xmpp:jingle-message:1' id='b73sjjvkla37jfea'>
|
||||
<reject xmlns='urn:xmpp:jingle-message:0' id='fecbea35-08d3-404f-9ec7-2b57c566fa74'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<expired/>
|
||||
<text>Tie-Break</text>
|
||||
</reason>
|
||||
<tie-break/>
|
||||
</reject>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
<!-- Juliet sent the higher ID and retracts the call -->
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<retract xmlns='urn:xmpp:jingle-message:0' id='fecbea35-08d3-404f-9ec7-2b57c566fa74'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<expired/>
|
||||
<text>Tie-Break</text>
|
||||
@ -314,21 +350,21 @@
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/>
|
||||
<proceed xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Existing session' anchor='tie-break-2'>
|
||||
<p>If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder MUST transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.</p>
|
||||
<p>She does so by first accepting the new session (sending an <accept/> message like she would do normally) and then sending a <finish/> message including a child element whose to-attribute refers to the old Jingle session id and including a <reason/> condition of <expired/>.</p>
|
||||
<p>That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume an alreay running session after a sudden connectivity/power loss.</p>
|
||||
<p>If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder SHOULD transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.</p>
|
||||
<p>The responder does so by sending a <finish/> message including a <reason/> condition of <expired/> and having a <migrated> child element whose to-attribute refers to the new Jingle session id, and accepting the new session by sending an <proceed/> message like they would do normally.</p>
|
||||
<p>That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume a still running session after a sudden connectivity/power loss.</p>
|
||||
<example caption="Tie break in accept state"><![CDATA[
|
||||
<!-- old session gets proposed... -->
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
|
||||
</propose>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
@ -338,7 +374,7 @@
|
||||
<message from='juliet@capulet.example/phone'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/>
|
||||
<proceed xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
@ -348,42 +384,48 @@
|
||||
<message from='juliet@capulet.example/tablet'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'>
|
||||
<propose xmlns='urn:xmpp:jingle-message:0' id='989a46a6-f202-4910-a7c3-83c6ba3f3947'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
|
||||
</propose>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
<!-- Romeo accepts the call because it is assumed to be a continuation of the old session with id 'a73sjjvkla37jfea'... -->
|
||||
<!-- Romeo finishes the old session with id 'ca3cf894-5325-482f-a412-a6e9f832298d' using reason <expired/> -->
|
||||
<!-- because the new one is assumed to be the continuation of the old one. -->
|
||||
<!-- This is including a <migrated/> element pointing to the new session id '989a46a6-f202-4910-a7c3-83c6ba3f3947'... -->
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<accept xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
<!-- ...and finishes the old session with id 'a73sjjvkla37jfea' directly afterwards using reason <expired/> -->
|
||||
<!-- and including a <migrated/> element pointing to the new session id 'x64sjjvkla37baka' -->
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:0' id='ca3cf894-5325-482f-a412-a6e9f832298d'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<expired/>
|
||||
<text>Session migrated</text>
|
||||
</reason>
|
||||
<migrated to='x64sjjvkla37baka'/>
|
||||
<migrated to='989a46a6-f202-4910-a7c3-83c6ba3f3947'/>
|
||||
</finish>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
<!-- ...and directly afterwards accepts the new call with id '989a46a6-f202-4910-a7c3-83c6ba3f3947'. -->
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<proceed xmlns='urn:xmpp:jingle-message:0' id='989a46a6-f202-4910-a7c3-83c6ba3f3947'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
<!-- ...some more time passes... -->
|
||||
|
||||
<!-- the new session is termianted normally by Romeo... -->
|
||||
<message from='romeo@montague.example/orchard'
|
||||
to='juliet@capulet.example'
|
||||
type='chat'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'/>
|
||||
<finish xmlns='urn:xmpp:jingle-message:0' id='989a46a6-f202-4910-a7c3-83c6ba3f3947'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<success/>
|
||||
<text>Success</text>
|
||||
</reason>
|
||||
</finish>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
@ -391,7 +433,12 @@
|
||||
<message from='juliet@capulet.example/tablet'
|
||||
to='romeo@montague.example'
|
||||
type='chat'>
|
||||
<finish xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'/>
|
||||
<finish xmlns='urn:xmpp:jingle-message:0' id='989a46a6-f202-4910-a7c3-83c6ba3f3947'>
|
||||
<reason xmlns="urn:xmpp:jingle:1">
|
||||
<success/>
|
||||
<text>Success</text>
|
||||
</reason>
|
||||
</finish>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
|
||||
@ -401,13 +448,13 @@
|
||||
<section1 topic='Business Rules' anchor="business-rules">
|
||||
<p>Participants MUST use &xep0280; and &xep0313; to make sure all devices of initiator and responder receive all messages exchanged by this protocol.
|
||||
Without &xep0280; implementations would need to send copies of outgoing messages to their own bare jid, to inform their own devices about an event (like it was done with the <accept/> message in the old urn:xmpp:jingle:jingle-message:0 specification).</p>
|
||||
<p>In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving an <accept/> might comprise bad UX.</p>
|
||||
<p>In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving a <propose/> might comprise bad UX.</p>
|
||||
<p>In the rare case of missing <finish/> elements from both initiator and responder, sessions SHOULD be considered terminated after an appropriate timeframe (for example 24 hours) and indicated so in the UI.</p>
|
||||
<p>All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.</p>
|
||||
<p>Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.</p>
|
||||
<p>Because exchanging messages with other entities is effectively a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.</p>
|
||||
<p>Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> (or <connectivity-error/>) for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.</p>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='acks'>
|
||||
<p>Thanks to Lance Stout, Holger Weiß and Daniel Gultsch for their feedback.</p>
|
||||
@ -419,7 +466,7 @@
|
||||
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||
<p>This specification defines the following XML namespace:</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:jingle:jingle-message:1</li>
|
||||
<li>urn:xmpp:jingle:jingle-message:0</li>
|
||||
</ul>
|
||||
<p>The ®ISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
|
||||
</section2>
|
||||
@ -427,6 +474,9 @@
|
||||
&NSVER;
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Design Considerations' anchor='design'>
|
||||
<p>Versions 0.4 and 0.5 of this specification define more or less the same protocol in the namespace urn:xmpp:jingle:jingle-message:1 (but in many places using MUST rather than SHOULD and removing <proceed/> in favor of <accept/>). To provide for greater backwards compatibility, version 0.6 of this document switched back to the old urn:xmpp:jingle:jingle-message:0 namespace. Future updates requiring a namespace bump should therefore directly bump the namespace version to :2 ans skip :1.</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
@ -434,8 +484,8 @@
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
xmlns:xml='http://www.w3.org/XML/1998/namespace'
|
||||
targetNamespace='urn:xmpp:jingle-message:1'
|
||||
xmlns='urn:xmpp:jingle-message:1'
|
||||
targetNamespace='urn:xmpp:jingle-message:0'
|
||||
xmlns='urn:xmpp:jingle-message:0'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:element name='propose'>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user