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 that will be used for the session invitation of &xep0166; and MUST contain one <description/> element for each media type associated with the intended session.

The server of the responder (e.g., Juliet) distributes this message stanza to all of Juliet's available resources (and to push resources as appropriate) thanks to &xep0280; and &xep0313;. Those devices might start ringing as a result.

Consistent with the recommendation for one-to-one chat sessions in Section 5.1 of &rfc6121;, the initiator SHOULD also send directed presence to the responder if the two entities do not already share presence information; including Entity Capabilities (XEP-0115) information in this directed presence stanza enables the responder to know the availability of the initiator (e.g., in case the message is actually delivered quite a bit later because it is saved to &xep0313; storage) and also to know the XMPP features supported by the initiator.

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.

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 Security Considerations below for details and rationale).

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 accept the intent to start a session.

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.

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.

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.

Next, the device from which Juliet accepted the call sends directed presence to Romeo for the reasons described above.

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.

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 Security Considerations below for details and rationale).

In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in Tie Breaking.

Now Romeo actually initiates the session (segue to Jingle itself).

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 Accept to the bare jid of the other party.

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 Tie Breaking for more infos on this and similar scenarios.

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 Security Considerations below for details and rationale).

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

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.

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

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.

This specification defines the following XML namespace:

• urn:xmpp:jingle:jingle-message:1

The ®ISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.