[xiph-commits] r10529 - trunk/theora/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Sat Dec 3 03:25:16 PST 2005
Author: lu_zero
Date: 2005-12-03 03:25:13 -0800 (Sat, 03 Dec 2005)
New Revision: 10529
Modified:
trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
Log:
Updated Offer/Answer section, added Well Known Configuration section
Modified: trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
===================================================================
--- trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt 2005-12-03 05:01:49 UTC (rev 10528)
+++ trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt 2005-12-03 11:25:13 UTC (rev 10529)
@@ -78,8 +78,9 @@
3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10
+ 3.2.2. Well Known Configurations . . . . . . . . . . . . . . 12
3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
- 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Example Fragmented Theora Packet . . . . . . . . . . . . . 14
5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
@@ -88,11 +89,11 @@
6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . . . . 22
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ Intellectual Property and Copyright Statements . . . . . . . . . . 23
@@ -108,7 +109,6 @@
-
Barbato Expires April 18, 2006 [Page 2]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -479,7 +479,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 1 | 1|
+ | Configuration Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -513,9 +513,9 @@
3.2. Out of Band Transmission
- This section, as stated before, won't cover all the possible out-of-
- band delivery methods since they rely to different protocols and be
- linked to a specific application. The following packet definition
+ This section, as stated before, will not cover all the possible out-
+ of-band delivery methods since they rely to different protocols and
+ be linked to a specific application. The following packet definition
SHOULD be used in out-of-band delivery and MUST be used when
Configuration is inlined in the SDP.
@@ -565,7 +565,7 @@
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | ..
+ | Configuration Ident | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Length | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -638,12 +638,42 @@
Change controller: IETF AVT Working Group
+3.2.2. Well Known Configurations
+
+ Even if the Vorbis nature prevents the creation of everlasting
+ profiles, some combination of codebooks, bitrate, channels and
+ samplerate are quite common. A client may have a list of well known
+ configuration and MAY avoid fetching them already. In order to
+ retain compatibility the server, even if all the Configurations that
+ will be in use are Well Known, MUST provide at least another way to
+ provide codebooks. Every Configuration that is available as Well
+ Known has the Ident highest bit set. Every Well Known List MUST
+ contain at most 2^23 items.
+
+ {FIXME:add an hash reference and a way to get them?} This off band
+ delivery method MUST be signaled as "out_band/wkc/list_name" using
+ the mandated parameter delivery-method. As further explained in the
+ IANA Considerations (Section 6) section.
+
+ Only one list MUST be used at time. During SDP Offer/Answer [5]
+ client and server MAY agree on a specific list, that subject will be
+ discussed further on the specific SDP Offer/Answer (Section 6.2)
+ section. This method
+
3.3. Loss of Configuration Headers
Unlike the loss of raw Theora payload data, loss of a configuration
header can lead to a situation where it will not be possible to
successfully decode the stream.
+
+
+
+Barbato Expires April 18, 2006 [Page 12]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
Loss of Configuration Packet results in the halting of stream
decoding and SHOULD be reported to the client as well as a loss
report sent via RTCP.
@@ -658,22 +688,6 @@
completely. The details on the format of the comments can be found
in the Theora documentation [12].
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires April 18, 2006 [Page 12]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -687,7 +701,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 2 | 1|
+ | Configuration Ident | 0 | 2 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -709,6 +723,13 @@
packets (up to a max of 15 packets, since the number of packets is
defined by a 4 bit value).
+
+
+Barbato Expires April 18, 2006 [Page 13]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
Any Theora data packet that is less than path MTU SHOULD be bundled
in the RTP packet with as many Theora packets as will fit, up to a
maximum of 15. Path MTU is detailed in [7] and [8].
@@ -722,14 +743,6 @@
correct sequence for fragmented packet reception the timestamp field
of fragmented packets MUST be the same as the first packet sent, with
the sequence number incremented as normal for the subsequent RTP
-
-
-
-Barbato Expires April 18, 2006 [Page 13]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
packets.
5.1. Example Fragmented Theora Packet
@@ -765,27 +778,17 @@
In this packet the initial sequence number is 1000 and the timestamp
is xxxxx. The Fragment type field is set to one, indicating it is
the start packet of a serie of fragments. The number of packets
- field is set to 0, and as the payload is raw Theora data the Theora
- payload type field is set to 0.
-
-
-
-
-
-
-
-
-
-
-
Barbato Expires April 18, 2006 [Page 14]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+ field is set to 0, and as the payload is raw Theora data the Theora
+ payload type field is set to 0.
+
Packet 2:
0 1 2 3
@@ -801,7 +804,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Configuration Ident | 2 | 0 | 0|
+ | Configuration Ident | 2 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -834,9 +837,6 @@
-
-
-
Barbato Expires April 18, 2006 [Page 15]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -857,7 +857,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Configuration Ident | 3 | 0 | 0|
+ | Configuration Ident | 3 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -918,7 +918,7 @@
between 1 and 1048561 and MUST be in multiples of 16.
delivery-method: indicates the delivery methods in use, the possible
- values are:inline, in_band, out_band/specific-method
+ values are:inline, in_band, out_band/specific_method
configuration: the base16 [15] (hexadecimal) representation of the
Packed Headers (Section 3.2.1).
@@ -990,7 +990,8 @@
be included in the SDP "a=fmpt" attribute.
o The optional parameter "configuration-uri", when present, MUST be
- included in the SDP "a=fmpt" attribute.
+ included in the SDP "a=fmpt" attribute and MUST follow the
+ delivery-method that applies.
If the stream comprises chained Theora files and all of them are
known in advance, the Configuration Packet for each file SHOULD be
@@ -1001,7 +1002,6 @@
location where all of the Configuration Packets needed for the life
of the session reside.
- Example:
@@ -1010,14 +1010,25 @@
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+ Example:
+
c=IN IP4/6
m=video RTP/AVP 98
a=rtpmap:98 theora/90000
a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-
- method=inline; configuration=base16string1;
+ method=inline; configuration=base16string1; delivery-
+ method=out_band/rtsp; delivery-method=out_band/http;
+ configuration-uri=http://path/to/resource/
6.2. Usage with the SDP Offer/Answer Model
+ {FIXME:explain also the standard way to offer multiple streams and
+ pick only the ones interesting?} The offer, as described in An Offer/
+ Answer Model Session Description Protocol [5], may contain a large
+ number of delivery methods per single fmtp attribute, the answerer
+ MUST remove every delivery-method and configuration-uri not
+ supported.
+
The answer to any offer, [5], MUST NOT change the URI specified in
the configuration-uri attribute. The Configuration inlined in the
configuration parameter MAY change.
@@ -1046,6 +1057,15 @@
9. References
+
+
+
+
+Barbato Expires April 18, 2006 [Page 19]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
9.1. Normative References
[1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
@@ -1058,14 +1078,6 @@
"RTP: A Transport Protocol for real-time applications",
RFC 3550.
-
-
-
-Barbato Expires April 18, 2006 [Page 19]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
[4] Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
Conferences with Minimal Control.", RFC 3551.
@@ -1102,6 +1114,14 @@
Conversion. International Telecommunications Union. Available
from the ITU website, http://www.itu.int".
+
+
+
+Barbato Expires April 18, 2006 [Page 20]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
[14] "ISO 3309, October 1984, 3rd Edition. Information Processing
Systems--Data Communication High-Level Data Link Control
Procedure--Frame Structure. International Organization for
@@ -1117,7 +1137,43 @@
-Barbato Expires April 18, 2006 [Page 20]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 21]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1173,7 +1229,7 @@
-Barbato Expires April 18, 2006 [Page 21]
+Barbato Expires April 18, 2006 [Page 22]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1229,6 +1285,6 @@
-Barbato Expires April 18, 2006 [Page 22]
+Barbato Expires April 18, 2006 [Page 23]
Modified: trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
===================================================================
--- trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml 2005-12-03 05:01:49 UTC (rev 10528)
+++ trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml 2005-12-03 11:25:13 UTC (rev 10529)
@@ -356,7 +356,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 1 | 1|
+ | Configuration Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -386,7 +386,7 @@
<section anchor="Out of Band Transmission" title="Out of Band Transmission">
<t>
-This section, as stated before, won't cover all the possible out-of-band delivery methods since they rely to different protocols and be linked to a specific application. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+This section, as stated before, will not cover all the possible out-of-band delivery methods since they rely to different protocols and be linked to a specific application. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
</t>
<section anchor="Packed Headers" title="Packed Headers">
@@ -418,7 +418,7 @@
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | ..
+ | Configuration Ident | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Length | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -499,8 +499,31 @@
</section>
</section>
+
+<section anchor="Well Known Configurations" title="Well Known Configurations">
+
+<t>
+Even if the Vorbis nature prevents the creation of everlasting profiles, some combination of codebooks, bitrate, channels and samplerate are quite common.
+A client may have a list of well known configuration and MAY avoid fetching them already.
+In order to retain compatibility the server, even if all the Configurations that will be in use are Well Known, MUST provide at least another way to provide codebooks.
+Every Configuration that is available as Well Known has the Ident highest bit set. Every Well Known List MUST contain at most 2^23 items.
+</t>
+
+<t>
+{FIXME:add an hash reference and a way to get them?}
+This off band delivery method MUST be signaled as "out_band/wkc/list_name" using the mandated parameter delivery-method. As further explained in the <xref target="IANA Considerations">IANA Considerations</xref> section.
+</t>
+
+<t>
+Only one list MUST be used at time. During <xref target="rfc3264">SDP Offer/Answer</xref> client and server MAY agree on a specific list, that subject will be discussed further on the specific <xref target="Usage with the SDP Offer/Answer Mode">SDP Offer/Answer</xref> section.
+This method
+</t>
+
</section>
+
+</section>
+
<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers">
<t>
@@ -512,6 +535,9 @@
</t>
</section>
+
+
+
</section>
<section anchor="Comment Headers" title="Comment Headers">
@@ -533,7 +559,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 2 | 1|
+ | Configuration Ident | 0 | 2 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -614,7 +640,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Configuration Ident | 2 | 0 | 0|
+ | Configuration Ident | 2 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -644,7 +670,7 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Configuration Ident | 3 | 0 | 0|
+ | Configuration Ident | 3 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -654,7 +680,7 @@
</figure>
<t>
-This is the last Theora fragment packet. The Fragment type filed is set to 3 and the packet count remains set to 0. As in the previous packets the timestamp remains set to the first packet in the sequence and the sequence number has been incremented.
+This is the last Theora fragment packet. The Fragment type filed is set to 3 and the packet count remains set to 0. As in the previous packets the timestamp remains set to the first packet in the sequence and the sequence number has been incremented.
</t>
</section>
@@ -662,7 +688,7 @@
<section anchor="Packet Loss" title="Packet Loss">
<t>
-As there is no error correction within the Theora stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Theora packets as the client will have to cope with the handling of the Fragment type field. If we use the fragmented Theora packet example above and the first packet is lost the client MUST detect that the next packet has the packet count field set to 0 and the Fragment type is set to 2 and MUST drop it. The next packet, which is the final fragmented packet, MUST be dropped in the same manner. Feedback reports on lost and dropped packets MUST be sent back via RTCP.
+As there is no error correction within the Theora stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Theora packets as the client will have to cope with the handling of the Fragment type field. If we use the fragmented Theora packet example above and the first packet is lost the client MUST detect that the next packet has the packet count field set to 0 and the Fragment type is set to 2 and MUST drop it. The next packet, which is the final fragmented packet, MUST be dropped in the same manner. Feedback reports on lost and dropped packets MUST be sent back via RTCP.
</t>
<t>
@@ -695,7 +721,7 @@
height: Determines the number of lines per frame. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
</t>
<t>
-delivery-method: indicates the delivery methods in use, the possible values are:inline, in_band, out_band/specific-method
+delivery-method: indicates the delivery methods in use, the possible values are:inline, in_band, out_band/specific_method
</t>
<t>
configuration: the <xref target="rfc3548">base16</xref> (hexadecimal) representation of the <xref target="Packed Headers">Packed Headers</xref>.
@@ -767,7 +793,7 @@
<t>The mandated parameters "delivery-method" and "configuration" MUST be included in the SDP "a=fmpt" attribute.</t>
<vspace blankLines="1" />
-<t>The optional parameter "configuration-uri", when present, MUST be included in the SDP "a=fmpt" attribute.</t>
+<t>The optional parameter "configuration-uri", when present, MUST be included in the SDP "a=fmpt" attribute and MUST follow the delivery-method that applies.</t>
</list>
@@ -787,13 +813,19 @@
<t>c=IN IP4/6 </t>
<t>m=video RTP/AVP 98</t>
<t>a=rtpmap:98 theora/90000</t>
-<t>a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-method=inline; configuration=base16string1;</t>
+<t>a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-method=inline; configuration=base16string1; delivery-method=out_band/rtsp; delivery-method=out_band/http; configuration-uri=http://path/to/resource/</t>
</list>
+
</section>
<section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
+
<t>
+{FIXME:explain also the standard way to offer multiple streams and pick only the ones interesting?}
+The offer, as described in <xref target="rfc3264">An Offer/Answer Model Session Description Protocol</xref>, may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery-method and configuration-uri not supported.
+</t>
+<t>
The answer to any offer, <xref target="rfc3264"></xref>, MUST NOT change the URI specified in the configuration-uri attribute. The Configuration inlined in the configuration parameter MAY change.
</t>
More information about the commits
mailing list