Specified how to include SDP parameters and codec-specific parameters; added Speex examples.
Specified how to include SDP parameters and codec-specific parameters; clarified negotiation process; added Speex examples.
]]>
- The parameter names are guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <http://www.iana.org/assignments/sdp-parameters>).
+Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <http://www.iana.org/assignments/sdp-parameters>).
+ +Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a receiver iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:
+If, after applying these rules, the receiver determines it does not support any of the offering encodings, the receiver MUST reject the session by sending a <unsupported-codecs/> error in response to the initiator's "initiate" action. Otherwise, it MUST provisionally accept the session by sending an empty IQ result. If the response content type differs from the one offered, the receiver MUST then propose the change in a "description-modify" action as defined in XEP-0166. If the description is identical, the receiver MUST send a "description-accept" action (either explicitly, or implicitly as part of a "session-accept" or "content-accept" action).
+Following is an example of this negotiation:
+The receiver now follows the rules provided in this section and determines it can only support PCMU. It provisionally accepts the session:
+It then offers the new content description in a 'description-modify' action:
+The initiator acknowledges the 'description-modify' with an empty IQ result, and sends a 'description-accept' to accept the new Jingle Audio content description.
+Finally, the target acknowledges the 'description-accept'.
+If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in RFC 4566: Session Description Protocol (SDP). The generic format for the media field is as follows:
@@ -315,6 +382,23 @@ a=fmtp:96 vbr=on;cng=on| Jingle Condition | +XMPP Condition | +Description | +
|---|---|---|
| <unsupported-codecs/> | +¬acceptable; | +The recipient does not support any of the offered audio encodings. | +
Support for the Speex codec is RECOMMENDED.
@@ -323,7 +407,7 @@ a=fmtp:96 vbr=on;cng=onIf it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is REQUIRED to use the XML format specified &xep0181;.
When the session is provisionally accepted, as indicated by the receiver sending an empty IQ result in response to an 'initiate' message, both receiving and sending entities SHOULD start listening for audio as defined by the negotiated transport method. For interoperability with telephony systems, each entity SHOULD play any audio received at this time, before the target sends an 'accept' message.
+When the Jingle Audio content is accepted, either by a 'content-accept' action or a combination of 'description-accept' and 'transport-accept' actions, both receiving and sending entities SHOULD start listening for audio as defined by the negotiated transport method and audio description. For interoperability with telephony systems, each entity SHOULD both play any audio received and send a ringing tone, at this time, before the receiver sends a 'session-accept' action.