In diagrams, the following conventions are used:

• Dashed lines (---) represent Jingle stanzas that are sent via the XMPP signalling channel.
• Double-dashed lines (===) represent media packets that are sent via the media channel, which typically is not an XMPP channel but a direct or mediated channel between the endpoints.

The state machine for overall session management (i.e., the state per Session ID) is as follows:

As shown, there are three overall session states:

1. PENDING
2. ACTIVE
3. ENDED

The actions related to management of the overall Jingle session are as follows (detailed definitions are provided in under Action Attribute).

• content-accept -- Accept a content-add action received from another party.
• content-add -- Add one or more new content definitions to the session.
• content-modify -- Change the directionality of media sending.
• content-reject -- Reject a content-add action received from another party.
• content-remove -- Remove one or more content definitions from the session.
• session-accept -- Definitively accept a session negotiation.
• session-info -- Send session-level information, such as a ringing message.
• session-initiate -- Request negotiation of a new Jingle session.
• session-terminate -- End an existing session.
• transport-accept -- Accept a transport-replace action received from another party.
• transport-info -- Exchange transport candidates.
• transport-reject -- Reject a transport-replace action received from another party.
• transport-replace -- Redefine a transport method or replace it with a different method.

In order to initiate a Jingle session, the initiator needs to determine which of the responder's XMPP resources is best for the desired application format. Methods for doing so are out of scope for this specification. However, see the Determining Support section of this document (and associated specifications) for relevant information.

Once the initiator has discovered which of the responder's XMPP resources is ideal for the desired application format, it sends a session initiation request to the responder. This request is an IQ-set containing a &JINGLE; element qualified by the 'urn:xmpp:jingle:0' namespace &VNOTE;, where the value of the 'action' attribute is "session-initiate" and where the &JINGLE; element contains one or more &CONTENT; elements. Each &CONTENT; element defines a content type to be transferred during the session, and each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired application format and one &TRANSPORT; child element that specifies a potential transport method. If either party wishes to propose the use of multiple transport methods for the same application format, it MUST include multiple &CONTENT; elements.

Note: The syntax and semantics of the &DESCRIPTION; and &TRANSPORT; elements are out of scope for this document, since they are defined in related specifications. The syntax and semantics of the &JINGLE; and &CONTENT; elements are specified in this document under Formal Definition.

Note: In order to expedite session establishment, the initiator MAY send transport candidates (e.g., for negotiation of the ICE transport) immediately after sending the session-initiate action and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be PENDING even before receiving acknowledgement). Given in-order delivery in accordance with &xmppcore;, the responder will receive such transport-info actions after receiving the session-initiate action (if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist).

In general, negotiation will be necessary before the parties can agree on an acceptable set of application formats and transport methods. There are many potential parameter combinations, as defined in the relevant specifications for various application formats and transport methods.

The allowable negotiations (including content-level and transport-level negotiations) are as follows:

• Exchanging particular transport candidates via the transport-info action.
• Modifying the communication direction for a content type via the content-modify action.
• Changing the definition of a content type via the transport-replace action (typically to fall back to a more suitable transport).
• Adding a content type via the content-add action.
• Removing a content type via the content-remove action.

If (after negotiation of transport methods and application formats as well as checking of transport candidates) the responder determines that it will be able to establish a connection, it sends a definitive acceptance to the initiator.

The initiator then acknowledges the responder's definitive acceptance, after which the parties can exchange media over the negotiated connection.

If one of the parties cannot find a suitable transport method or candidate, it SHOULD terminate the session as described below.

Once a session is in the ACTIVE state, it might be modified via a content-add, content-modify, content-remove, or transport-info action. Examples of such modifications are shown in the specifications for various application formats and transport methods.

In order to gracefully end the session (which can be done at any point after acknowledging receipt of the initiation request, including immediately thereafter in order to decline the request), either the responder or the initiator MUST send a session-terminate action to the other party.

The party that terminates the session SHOULD include a <reason/> element that specifies why the session is being terminated. Examples follow.

One reason for terminating the session is that the terminating party is busy; in this case, the recommended condition is "busy".

Another reason for terminating the session is that the terminating party wishes to formally decline the session; in this case, the recommended condition is "decline".

Another reason for terminating the session is that the terminating party already has an existing session with the other party and wishes to use that session rather than initiate a new session; in this case, the recommended condition is "alternative-session" and the terminating party SHOULD include the session ID of the alternative session in the <sid/> element.

Another reason for terminating the session is that the terminating party does not support any of the offered application formats; in this case, the recommended condition is "unsupported-applications".

Another reason for terminating the session is that the terminating party does not support any of the offered transport methods; in this case, the recommended condition is "unsupported-transports".

Upon receiving an action of "session-terminate", the other party MUST then acknowledge termination of the session:

Note: As soon as an entity sends a session-terminate action, it MUST consider the session to be in the ENDED state (even before receiving acknowledgement from the other party). If the terminating entity receives additional Jingle-related IQ-sets from the other party after sending the session-terminate action, it MUST reply with an <unknown-session/> error.

Unfortunately, not all sessions end gracefully. In applications of Jingle that also involve the exchange of presence information, receipt of &UNAVAILABLE; from the other party MAY be considered a session-ending event. However, in this case there is nothing for the party to acknowledge.

At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to inform the other party that a device is ringing.

An informational message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info" or "transport-info"; the &JINGLE; element SHOULD further contain a payload child element (specific to the application format or transport method) that specifies the information being communicated. If the party that receives an informational message does not understand the payload, it MUST return a &feature; error with a Jingle-specific error condition of <unsupported-info/>.

However, the &JINGLE; element associated with a session-info action MAY be empty. If either party receives an empty session-info action for an active session, it MUST send an empty IQ result; this usage functions as a "ping" to determine session vitality.

The &JINGLE; element MAY be empty or contain one or more &CONTENT; elements (for which see Content Element).

The attributes of the &JINGLE; element are as follows.

The value of the 'action' attribute SHOULD be one of the following. If an entity receives a value not defined here, it SHOULD ignore attribute and SHOULD return a &badrequest; error to the sender.

The attributes of the &CONTENT; element are as follows.

The structure of the <reason/> element is as follows.

• The <reason/> element MUST contain an element that provides machine-readable information about the condition that prompted the action.
• The <reason/> element MAY contain a <text/> element that provides human-readable information about the reason for the action.
• The <reason/> element MAY contain an element qualified by some other namespace that provides more detailed machine-readable information about the reason for the action.

The defined conditions are described in the following table.

The syntax and semantics of the <thread/> element exactly matches that of the <thread/> element as defined for the &MESSAGE; stanza (qualified by the 'jabber:client' namespace) as defined in &xmppim;. It is used to associate a Jingle session or sessions with an ongoing conversation, so that user interfaces with the ability to present multiple interactions in the same window can show an association between the conversation and the Jingle session(s).

A document that specifies a Jingle application format (e.g., RTP sessions) MUST define:

1. How successful application format negotiation occurs.
2. A &DESCRIPTION; element and associated semantics for representing the application format.
3. If and how the application format can be mapped to the Session Description Protocol, including the appropriate SDP media type (see Section 8.2.1 of RFC 4566).
4. Whether the media for the application format shall be sent over a streaming transport method or a datagram transport method (or, if both, which is preferred).
5. Exactly how the media is to be sent and received over a streaming or datagram transport.

A document that specifies a Jingle transport method (e.g., raw UDP) MUST define:

1. How successful transport negotiation occurs.
2. A &TRANSPORT; element and associated semantics for representing the transport method.
3. Whether the transport is streaming or datagram.
4. If and how the transport handles "components" (e.g., for the Real Time Control Protocol).

Jingle sessions can be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Jingle sessions. Care must be taken to accept sessions only from known entities and only if the entity's device is able to process such sessions.

Jingle communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. (For example, on some SIP networks authentication is optional and "from" addresses can be easily forged.) Care must be taken in communicating through such gateways.

Mere negotiation of a Jingle session can expose sensitive information about the parties (e.g., IP addresses). Care must be taken in communicating such information, and end-to-end encryption should be used if the parties do not trust the intermediate servers or gateways.

This specification defines the following XML namespaces:

• urn:xmpp:jingle:0
• urn:xmpp:jingle:errors:0

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

The XMPP Registrar shall maintain a registry of Jingle application formats. All application format registrations shall be defined in separate specifications (not in this document). Application types defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URNs of the form "urn:xmpp:jingle:app:name" (where "name" is the registered name of the application format).

The XMPP Registrar shall maintain a registry of Jingle transport methods. All transport method registrations shall be defined in separate specifications (not in this document). Transport methods defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URNs of the form "urn:xmpp:jingle:transport:name" (where "name" is the registered name of the transport method).