Promoting to Experimental.
+First draft.
++ A call can take place between two or more parties and can be initiated and conducted via various protocols. This + specification defines a way to invite someone to a call providing one or more ways in which to join. +
++ &xep0353; provides partially overlapping functionality. It allows to initiate any kind of Jingle session, for + example calls but also file transfers. However, it is not suitable for inviting someone to any kind of call, since + a call can also be established through other means than a simple Jingle session-initiate. +
++ This specification defines a way to invite someone to a call. The call can for example be initiated via &xep0167; + or via an external URI. It also allows to define multiple ways to join the same call. Furthermore, it defines how + to retract, accept and reject the call invite and how to indicate that a client left the call. +
++ To invite someone to a call, a message containing an <invite> element in the urn:xmpp:call-invites:0 + namespace is sent. The element has an optional 'video' attribute that indicates if the call is intended to be + joined with participants sending video ("true") or not ("false", default). An 'audio' attribute is defined + analogously, defaulting to "true". The <invite> element contains one sub-element for each way to join the + call. +
++ In order to invite someone to a &xep0167; call, a <jingle> element is placed in the <invite> + element. The <jingle> element has a 'sid' attribute specifying the ID of the Jingle session. It can + optionally also contain a 'jid' element, to indicate the JID the Jingle session will be initiated from. If no + 'jid' element is provided, the default is the sender of the message stanza. +
++ External ways to join the call can be specified via an <external> element placed in the <invite> + element with an 'uri' attribute that contains a URI. The URI can for example contain a URL to a browser + webclient or a dial-in telephone number. +
+ ++ Specifications that describe further ways to join a call define their own sub-elements to the <invite> + element containing all necessary information for joining. +
++ A call invite can be retracted by sending a message containing a <retract> element with an 'id' attribute + containing the id of the invite message qualified by the urn:xmpp:call-invites:0 namespace. +
++ A call invite can be accepted by sending a message containing an <accept> element with an 'id' attribute + containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. +
++ The element describing the connection method used by the accepting client (e.g. <jingle> or <external>) + including all of its attributes and children is placed in the <accept> element. +
++ After the <accept> was sent, the initiating or accepting client continues to establish the call depending + on the selected connection method: If an <external> method was selected, the accepting client handles the + URI. The exact behaviour of opening the URI is implementation specific. If a <jingle> method was selected, + the initiating client triggers a Jingle session-initiate from the JID and with the session ID specified in the + 'jid' and 'sid' attributes of the <jingle> element, respectively. +
++ A call invite can be rejected by sending a message containing a <reject> element with an 'id' attribute + containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. +
++ When a client leaves a call, it sends a message containing a <left> element with an 'id' attribute + containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. +
++ Clients must ensure that they will receive the accept or reject responses of other resources by the same user (if + any) when implementing this specification. This can be achieved by implementing &xep0280;. +
++ For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be used for call retracts, accepts, + rejects or lefts. Instead, in group chat situations, the ID assigned to the stanza by the group chat itself must + be used. This is discovered in a <stanza-id> element with a 'by' attribute that matches the bare JID of + the group chat, as defined in &xep0359;. +
++ This implies that invite messages should only be sent in group chats that attach a &xep0359; stanza-id. +
++ For other message types the sender should use the 'id' from a &xep0359; + <origin-id> if present, or the value of the 'id' attribute on the + <message> otherwise. +
++ None. +
+This document requires no interaction with &IANA;.
+This document requires no interaction with ®ISTRAR;.
+