First draft.
This documents specifies how to negotiate the use of the Extended + RTP Profile for Real-time Transport Control Protocol (RTCP)-Based + Feedback (RTP/AVPF) with Jingle RTP sessions.
+The Jingle extension defined herein is designed to meet the following requirements:
+This specification defines two new elements, <rtcp-fb/> and + <rtcp-fb-trr-int/>, that can be inserted in the + <description/> or the <payload-type/> elements of a + XEP-0167 RTP session. The presence of any of these elements in a + content's description means that the RTP/AVPF profile should be used + for the whole content. If any of these elements are inside the + <payload-type/> element, the parameters specified apply only to + that payload type, if they are directly inside the + <description/> tag, then the specified parameters apply to the + whole content.
+ +The attributes of the <rtcp-fb/> element are:
+| Attribute | +Description | +Inclusion | +Possible values | +
|---|---|---|---|
| type | +The type of feedback | +REQUIRED | +ack, nack, ccm, app, etc.. | +
| subtype | +The subtype (depends on the type) | +OPTIONAL (possibly REQUIRED depending on the type) | +
+ ack: rpsi, app + nack: sli, pli, rpsi, app, rai + ccm: fir, tmmbr, tstr, vbcm + app: depends on the application + |
+
Any type or subtype of feedback message that requires extra +parameters in the a=b form can use the <parameter/> element to +describe it. Any other form of parameter can be store in the CDATA +inside the <rtcp-fb/> element.
+ +The element <rtcp-fb-trr-int/> is used to specify the minimum +interval between two Regular (full compound) RTCP packets in +milliseconds for this media session. It corresponds to the +"a=rtcp-fb:* trr-int" line in SDP. The attributes of the +<rtcp-fb-trr-int/> element are:
+| Attribute | +Description | +Inclusion | +Possible values | +
|---|---|---|---|
| value | +Number of milliseconds between regular RTCP reports | +REQUIRED | +0 to MAXUINT (default to 0) | +
Feedback messages are negotiated along the codecs. They follow + the same Offer/Answer mechanism based on SDP Offer/Answer. The + initiator signals which feedback messages it wants to send or + receive in the the <session-initiate/> iq stanza. If the + responder does not understand the type or subtype of a feedback + message, it MUST remove the element from the reply. If the responder + does not wish to provide or receive some kind of feedback, it MUST + remove the relevant element. It MUST then send the remaining + elements it wants to keep as-is without modifying them in the + <session-accept/>
+ +The responder MUST send any <rtcp-fb/> element as-is if it + accepts it. It MUST NOT change any parameter to conform the the + negotiation defined in RFC 4585 Section 4. It MUST NOT add any + <rtcp-fb/> element that was not offered by the initiator. It + MUST NOT modify the 'value' of any >rtcp-fb-trr-int/< + element. It can only remove the >rtcp-fb-trr-int/< element or + reject the content. If all the feedback messages are removed but the + responder wants to stay in the RTP/AVPF profile, it MUST put a + <rtcp-fb-trr-int/> element with the same 'value' that it + received from the intiator, if the initiator did not provide a + <rtcp-fb-trr-int/> element, then this value is "0".
+ +Example negotiation where the initiator requests Packet Loss + Indications (pli) as defined in RFC 4585 on both H.263 and H.264, + but also requests Slice Loss Indications for H.264 with a minimum + interval between regular full compound RTCP packets of 100 milliseconds.
+ +Example reply where the responder rejects the "sli" but + accepts the "pli".
+ +Another reply to the same request where the responder wishes to + stay in the AVPF profile but rejects all specific feedback messages + by using the <rtcp-fb-trr-int/> with the default value.
+ +The <rtcp-fb/> element maps to the a:rtcp-fb= SDP line with + the exception of the 'trr-int' parameter which is mapped into it's + own element (<rtcp-fb-trr-int/>) in XMPP. The payload types + are also not explicitly written in the <rtcp-fb/> and + <rtcp-fb-trr-int/> elements. Instead, each payload type has its own + set of <rtcp-fb/> and <rtcp-fb-trr-int/> elements if + they do not apply to the whole content.
+ +Example conversion of a sample fragment of a SDP containing an + audio session using the RTP/AVP profile for audio and the RTP/AVPF + profile for video:
+To advertise its support for Extended RTCP Feedback in Jingle RTP + Sessions and a minimum interval between regular RTCP packets, when + replying to &xep0030; information requests an entity MUST return the + following features:
+ +An example follows:
+ +This document requires no interaction with the Internet Assigned + Numbers Authority (IANA).
+This specification defines the following XML namespaces:
+The ®ISTRAR; includes the foregoing namespaces in its + registry at &NAMESPACES;, as governed by &xep0053;.
+If the protocol defined in this specification undergoes a + revision that is not fully backwards-compatible with an older + version, 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.
+TODO: Write actual schema
+Thanks to Youness Alaoui for his feedback.
+First draft.
This documents specifies how to negotiate the use of the RTP + Header Extensions as defined by RFC 5285 with Jingle RTP + sessions.
+The Jingle extension defined herein is designed to meet the following requirements:
+This specification defines a new element, <rtp-hdrext/>, + that can be inserted in the <description/> element of a + XEP-0167 RTP session.
+ +The attributes of the <rtp-hdrext/> element are:
+| Attribute | +Description | +Inclusion | +Possible values | +
|---|---|---|---|
| id | +The ID of the extensions | +REQUIRED | +1-256, 4096-4351 | +
| uri | +The URI that defines the extension | +REQUIRED | +Any valid URI | +
| senders | +Which party is allowed to send the negotiated RTP Header Extensions | +OPTIONAL (defaults to "both") | +"initiator", "responder", and "both" | +
Any type of RTP Header Extension that requires extra +parameters in the a=b form can embed <parameter/> elements to +describe it. Any other form of parameter can be stored in the CDATA +inside the <rtp-hdrext/> element.
+ +RTP header extensions are negotiated along the codecs. They + follow the same Offer/Answer mechanism based on SDP + Offer/Answer. The initiator signals which RTP header extensions it + wants to send or receive in the the <session-initiate/> iq + stanza. If the responder does not understand the type of header + extensions, it MUST remove the element from the reply. If the + responder does not wish to provide or receive some kind of RTP + header extension, it MUST remove the relevant element from the + reply. It MUST then send the remaining elements it wants to keep + as-is without modifying them in the <session-accept/> iq + stanza.
+ +It MUST NOT add any <rtp-hdrext/> element that was not + offered by the initiator. The responder MAY downgrade the senders + field from "both" to "initator" or "responder", but MUST NOT modify it + if it is "initator" or "responder".
+ +Example negotiation where the initiator offers to use the + timestamp offset header extension as defined in RFC 5450 and also + the requests synchronisation metadata header extension (RFC 6051) + with either the 56-bit or the 64-bit format.
+ +Example reply where the responder accepts the timestamp offset + and the 56-bit synchronisation metadata header extensions.
+ +Another reply to the same request where the responder accepts only the synchronisation data header extension with the 64-bit format.
+ +The <rtp-hdrext/> element maps to the "a:extmap=" SDP line + defined in RFC 5285. The ID is mapped to the 'id' attribute, the + direction to the 'senders' attribute and the URI to the 'uri' + attribute.
+ +Example conversion of a incomplete sample fragment of a SDP taken from RFC 5285 section 6 into equivalent XMPP:
+To advertise its support for Generic Header extensions in Jingle + RTP Sessions, when replying to &xep0030; information requests an + entity MUST return the following features:
+ +An example follows:
+ +This document requires no interaction with the Internet Assigned + Numbers Authority (IANA).
+This specification defines the following XML namespaces:
+The ®ISTRAR; includes the foregoing namespaces in its + registry at &NAMESPACES;, as governed by &xep0053;.
+If the protocol defined in this specification undergoes a + revision that is not fully backwards-compatible with an older + version, 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.
+TODO: Write actual schema
+Thanks to Youness Alaoui for his feedback.
+