draft-ietf-mmusic-rfc4566bis-28.txt | draft-ietf-mmusic-rfc4566bis-29.txt | |||
---|---|---|---|---|
Network Working Group A. Begen | Network Working Group A. Begen | |||
Internet-Draft Networked Media | Internet-Draft Networked Media | |||
Obsoletes: 4566 (if approved) P. Kyzivat | Obsoletes: 4566 (if approved) P. Kyzivat | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: November 22, 2018 C. Perkins | Expires: December 7, 2018 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
M. Handley | M. Handley | |||
UCL | UCL | |||
May 21, 2018 | June 5, 2018 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
draft-ietf-mmusic-rfc4566bis-28 | draft-ietf-mmusic-rfc4566bis-29 | |||
Abstract | Abstract | |||
This memo defines the Session Description Protocol (SDP). SDP is | This memo defines the Session Description Protocol (SDP). SDP is | |||
intended for describing multimedia sessions for the purposes of | intended for describing multimedia sessions for the purposes of | |||
session announcement, session invitation, and other forms of | session announcement, session invitation, and other forms of | |||
multimedia session initiation. This document obsoletes RFC 4566. | multimedia session initiation. This document obsoletes RFC 4566. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on November 22, 2018. | This Internet-Draft will expire on December 7, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 24 ¶ | |||
e=j.doe@example.com (Jane Doe) | e=j.doe@example.com (Jane Doe) | |||
c=IN IP4 233.252.0.2 | c=IN IP4 233.252.0.2 | |||
t=2873397496 2873404696 | t=2873397496 2873404696 | |||
a=recvonly | a=recvonly | |||
m=audio 49170 RTP/AVP 0 | m=audio 49170 RTP/AVP 0 | |||
m=audio 49180 RTP/AVP 0 | m=audio 49180 RTP/AVP 0 | |||
m=video 51372 RTP/AVP 99 | m=video 51372 RTP/AVP 99 | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
a=rtpmap:99 h263-1998/90000 | a=rtpmap:99 h263-1998/90000 | |||
Text containing fields such as the session name and information are | Text containing fields such as the session-name-field and | |||
octet strings that may contain any octet with the exceptions of 0x00 | information-field are octet strings that may contain any octet with | |||
(Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The | the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII | |||
sequence CRLF (0x0d0a) is used to end a record, although parsers | carriage return). The sequence CRLF (0x0d0a) is used to end a | |||
SHOULD be tolerant and also accept records terminated with a single | record, although parsers SHOULD be tolerant and also accept records | |||
newline character. If the "a=charset" attribute is not present, | terminated with a single newline character. If the "a=charset" | |||
these octet strings MUST be interpreted as containing ISO-10646 | attribute is not present, these octet strings MUST be interpreted as | |||
characters in UTF-8 encoding (the presence of the "a=charset" | containing ISO-10646 characters in UTF-8 encoding (the presence of | |||
attribute may force some fields to be interpreted differently). | the "a=charset" attribute may force some fields to be interpreted | |||
differently). | ||||
A session description can contain domain names in the "o=", "u=", | A session description can contain domain names in the "o=", "u=", | |||
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply | "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply | |||
with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) | with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) | |||
MUST be represented using the ASCII Compatible Encoding (ACE) form | MUST be represented using the ASCII Compatible Encoding (ACE) form | |||
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or | defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or | |||
any other encoding (this requirement is for compatibility with | any other encoding (this requirement is for compatibility with | |||
[RFC2327] and other early SDP-related standards, which predate the | [RFC2327] and other early SDP-related standards, which predate the | |||
development of internationalized domain names). | development of internationalized domain names). | |||
skipping to change at page 14, line 33 ¶ | skipping to change at page 14, line 33 ¶ | |||
Inclusion of an email address or phone number is OPTIONAL. | Inclusion of an email address or phone number is OPTIONAL. | |||
If an email address or phone number is present, it MUST be specified | If an email address or phone number is present, it MUST be specified | |||
before the first media description. More than one email or phone | before the first media description. More than one email or phone | |||
line can be given for a session description. | line can be given for a session description. | |||
Phone numbers SHOULD be given in the form of an international public | Phone numbers SHOULD be given in the form of an international public | |||
telecommunication number (see ITU-T Recommendation E.164 [E164]) | telecommunication number (see ITU-T Recommendation E.164 [E164]) | |||
preceded by a "+". Spaces and hyphens may be used to split up a | preceded by a "+". Spaces and hyphens may be used to split up a | |||
phone field to aid readability if desired. For example: | phone-field to aid readability if desired. For example: | |||
p=+1 617 555-6011 | p=+1 617 555-6011 | |||
Both email addresses and phone numbers can have an OPTIONAL free text | Both email addresses and phone numbers can have an OPTIONAL free text | |||
string associated with them, normally giving the name of the person | string associated with them, normally giving the name of the person | |||
who may be contacted. This MUST be enclosed in parentheses if it is | who may be contacted. This MUST be enclosed in parentheses if it is | |||
present. For example: | present. For example: | |||
e=j.doe@example.com (Jane Doe) | e=j.doe@example.com (Jane Doe) | |||
skipping to change at page 15, line 38 ¶ | skipping to change at page 15, line 38 ¶ | |||
address. Additional sub-fields MAY be added after the connection | address. Additional sub-fields MAY be added after the connection | |||
address depending on the value of the <addrtype> sub-field. | address depending on the value of the <addrtype> sub-field. | |||
When the <addrtype> is IP4 and IP6, the connection address is defined | When the <addrtype> is IP4 and IP6, the connection address is defined | |||
as follows: | as follows: | |||
o If the session is multicast, the connection address will be an IP | o If the session is multicast, the connection address will be an IP | |||
multicast group address. If the session is not multicast, then | multicast group address. If the session is not multicast, then | |||
the connection address contains the unicast IP address of the | the connection address contains the unicast IP address of the | |||
expected data source, data relay or data sink as determined by | expected data source, data relay or data sink as determined by | |||
additional attribute fields. It is not expected that unicast | additional attribute-fields. It is not expected that unicast | |||
addresses will be given in a session description that is | addresses will be given in a session description that is | |||
communicated by a multicast announcement, though this is not | communicated by a multicast announcement, though this is not | |||
prohibited. | prohibited. | |||
o Sessions using an IP4 multicast connection address MUST also have | o Sessions using an IP4 multicast connection address MUST also have | |||
a time to live (TTL) value present in addition to the multicast | a time to live (TTL) value present in addition to the multicast | |||
address. The TTL and the address together define the scope with | address. The TTL and the address together define the scope with | |||
which multicast packets sent in this session will be sent. TTL | which multicast packets sent in this session will be sent. TTL | |||
values MUST be in the range 0-255. Although the TTL MUST be | values MUST be in the range 0-255. Although the TTL MUST be | |||
specified, its use to scope multicast traffic is deprecated; | specified, its use to scope multicast traffic is deprecated; | |||
skipping to change at page 17, line 52 ¶ | skipping to change at page 17, line 52 ¶ | |||
sending simultaneously. | sending simultaneously. | |||
A prefix "X-" is defined for <bwtype> names. This is intended for | A prefix "X-" is defined for <bwtype> names. This is intended for | |||
experimental purposes only. For example: | experimental purposes only. For example: | |||
b=X-YZ:128 | b=X-YZ:128 | |||
Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-" | Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-" | |||
prefix) <bwtype> names SHOULD be defined, and then MUST be registered | prefix) <bwtype> names SHOULD be defined, and then MUST be registered | |||
with IANA in the standard namespace. SDP parsers MUST ignore | with IANA in the standard namespace. SDP parsers MUST ignore | |||
bandwidth fields with unknown <bwtype> names. The <bwtype> names | bandwidth-fields with unknown <bwtype> names. The <bwtype> names | |||
MUST be alphanumeric and, although no length limit is given, it is | MUST be alphanumeric and, although no length limit is given, it is | |||
recommended that they be short. | recommended that they be short. | |||
The <bandwidth> is interpreted as kilobits per second by default | The <bandwidth> is interpreted as kilobits per second by default | |||
(including the transport and network-layer but not the link-layer | (including the transport and network-layer but not the link-layer | |||
overhead). The definition of a new <bwtype> modifier MAY specify | overhead). The definition of a new <bwtype> modifier MAY specify | |||
that the bandwidth is to be interpreted in some alternative unit (the | that the bandwidth is to be interpreted in some alternative unit (the | |||
"CT" and "AS" modifiers defined in this memo use the default units). | "CT" and "AS" modifiers defined in this memo use the default units). | |||
5.9. Time Active ("t=") | 5.9. Time Active ("t=") | |||
skipping to change at page 21, line 14 ¶ | skipping to change at page 21, line 14 ¶ | |||
5.13. Attributes ("a=") | 5.13. Attributes ("a=") | |||
a=<attribute> | a=<attribute> | |||
a=<attribute>:<value> | a=<attribute>:<value> | |||
Attributes are the primary means for extending SDP. Attributes may | Attributes are the primary means for extending SDP. Attributes may | |||
be defined to be used as "session-level" attributes, "media-level" | be defined to be used as "session-level" attributes, "media-level" | |||
attributes, or both. | attributes, or both. | |||
A media description may have any number of "a=" lines (attribute- | A media description may contain any number of "a=" lines (attribute- | |||
fields) that are media description specific. These are referred to | fields) that are media description specific. These are referred to | |||
as "media-level" attributes and add information about the media | as "media-level" attributes and add information about the media | |||
description. Attribute fields can also be added before the first | description. Attribute-fields can also be added before the first | |||
media description; these "session-level" attributes convey additional | media description; these "session-level" attributes convey additional | |||
information that applies to the session as a whole rather than to | information that applies to the session as a whole rather than to | |||
individual media descriptions. | individual media descriptions. | |||
Attribute fields may be of two forms: | Attribute-fields may be of two forms: | |||
o A property attribute is simply of the form "a=<attribute>". These | o A property attribute is simply of the form "a=<attribute>". These | |||
are binary attributes, and the presence of the attribute conveys | are binary attributes, and the presence of the attribute conveys | |||
that the attribute is a property of the session. An example might | that the attribute is a property of the session. An example might | |||
be "a=recvonly". | be "a=recvonly". | |||
o A value attribute is of the form "a=<attribute>:<value>". For | o A value attribute is of the form "a=<attribute>:<value>". For | |||
example, a whiteboard could have the value attribute | example, a whiteboard could have the value attribute | |||
"a=orient:landscape" | "a=orient:landscape" | |||
skipping to change at page 22, line 12 ¶ | skipping to change at page 22, line 12 ¶ | |||
attribute is received that is not understood, it MUST be ignored by | attribute is received that is not understood, it MUST be ignored by | |||
the receiver. | the receiver. | |||
5.14. Media Descriptions ("m=") | 5.14. Media Descriptions ("m=") | |||
m=<media> <port> <proto> <fmt> ... | m=<media> <port> <proto> <fmt> ... | |||
A session description may contain a number of media descriptions. | A session description may contain a number of media descriptions. | |||
Each media description starts with an "m=" line (media-field) and is | Each media description starts with an "m=" line (media-field) and is | |||
terminated by either the next "m=" line or by the end of the session | terminated by either the next "m=" line or by the end of the session | |||
description. A media field has several sub-fields: | description. A media-field has several sub-fields: | |||
<media> is the media type. This document defines the values | <media> is the media type. This document defines the values | |||
"audio", "video", "text", "application", and "message". This list | "audio", "video", "text", "application", and "message". This list | |||
is extended by other memos and may be further extended by | is extended by other memos and may be further extended by | |||
additional memos registering media types in the future (see | additional memos registering media types in the future (see | |||
Section 8). For example, [RFC6466] defined the "image" media | Section 8). For example, [RFC6466] defined the "image" media | |||
type. | type. | |||
<port> is the transport port to which the media stream is sent. The | <port> is the transport port to which the media stream is sent. The | |||
meaning of the transport port depends on the network being used as | meaning of the transport port depends on the network being used as | |||
specified in the relevant "c=" line, and on the transport protocol | specified in the relevant "c=" line, and on the transport protocol | |||
defined in the <proto> sub-field of the media field. Other ports | defined in the <proto> sub-field of the media-field. Other ports | |||
used by the media application (such as the RTP Control Protocol | used by the media application (such as the RTP Control Protocol | |||
(RTCP) port [RFC3550]) MAY be derived algorithmically from the | (RTCP) port [RFC3550]) MAY be derived algorithmically from the | |||
base media port or MAY be specified in a separate attribute (for | base media port or MAY be specified in a separate attribute (for | |||
example, "a=rtcp:" as defined in [RFC3605]). | example, "a=rtcp:" as defined in [RFC3605]). | |||
If non-contiguous ports are used or if they don't follow the | If non-contiguous ports are used or if they don't follow the | |||
parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" | parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" | |||
attribute MUST be used. Applications that are requested to send | attribute MUST be used. Applications that are requested to send | |||
media to a <port> that is odd and where the "a=rtcp:" is present | media to a <port> that is odd and where the "a=rtcp:" is present | |||
MUST NOT subtract 1 from the RTP port: that is, they MUST send the | MUST NOT subtract 1 from the RTP port: that is, they MUST send the | |||
skipping to change at page 23, line 32 ¶ | skipping to change at page 23, line 32 ¶ | |||
This document provides no semantics for using multiple "m=" lines | This document provides no semantics for using multiple "m=" lines | |||
using the same transport address. This implies that, unlike | using the same transport address. This implies that, unlike | |||
limited past practice, there is no implicit grouping defined by | limited past practice, there is no implicit grouping defined by | |||
such means and an explicit grouping framework (for example, | such means and an explicit grouping framework (for example, | |||
[RFC5888]) should instead be used to express the intended | [RFC5888]) should instead be used to express the intended | |||
semantics. Such semantics may alo be added as extensions. For | semantics. Such semantics may alo be added as extensions. For | |||
instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. | instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. | |||
<proto> is the transport protocol. The meaning of the transport | <proto> is the transport protocol. The meaning of the transport | |||
protocol is dependent on the address type sub-field in the | protocol is dependent on the address type sub-field in the | |||
relevant "c=" line. Thus a "c=" field of IP4 indicates that the | relevant "c=" line. Thus a "c=" line with an address type of IP4 | |||
transport protocol runs over IP4. The following transport | indicates that the transport protocol runs over IP4. The | |||
protocols are defined, but may be extended through registration of | following transport protocols are defined, but may be extended | |||
new protocols with IANA (see Section 8): | through registration of new protocols with IANA (see Section 8): | |||
* udp: denotes that the data is transported directly in UDP with | * udp: denotes that the data is transported directly in UDP with | |||
no additional framing. | no additional framing. | |||
* RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for | * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for | |||
Audio and Video Conferences with Minimal Control [RFC3551] | Audio and Video Conferences with Minimal Control [RFC3551] | |||
running over UDP. | running over UDP. | |||
* RTP/SAVP: denotes the Secure Real-time Transport Protocol | * RTP/SAVP: denotes the Secure Real-time Transport Protocol | |||
[RFC3711] running over UDP. | [RFC3711] running over UDP. | |||
skipping to change at page 34, line 31 ¶ | skipping to change at page 34, line 31 ¶ | |||
a=sdplang:fr | a=sdplang:fr | |||
Multiple sdplang attributes can be provided either at session or | Multiple sdplang attributes can be provided either at session or | |||
media level if the session description or media use multiple | media level if the session description or media use multiple | |||
languages. | languages. | |||
As a session-level attribute, it specifies the language for the | As a session-level attribute, it specifies the language for the | |||
session description (not the language of the media). As a media- | session description (not the language of the media). As a media- | |||
level attribute, it specifies the language for any media-level SDP | level attribute, it specifies the language for any media-level SDP | |||
information field associated with that media (again not the language | information-field associated with that media (again not the language | |||
of the media), overriding any sdplang attributes specified at session | of the media), overriding any sdplang attributes specified at session | |||
level. | level. | |||
In general, sending session descriptions consisting of multiple | In general, sending session descriptions consisting of multiple | |||
languages is discouraged. Instead, multiple sesssion descriptions | languages is discouraged. Instead, multiple sesssion descriptions | |||
SHOULD be sent describing the session, one in each language. | SHOULD be sent describing the session, one in each language. | |||
However, this is not possible with all transport mechanisms, and so | However, this is not possible with all transport mechanisms, and so | |||
multiple sdplang attributes are allowed although NOT RECOMMENDED. | multiple sdplang attributes are allowed although NOT RECOMMENDED. | |||
The "sdplang" attribute value must be a single [RFC5646] language tag | The "sdplang" attribute value must be a single [RFC5646] language tag | |||
skipping to change at page 42, line 40 ¶ | skipping to change at page 42, line 40 ¶ | |||
For other protocols, formats MAY be registered according to the rules | For other protocols, formats MAY be registered according to the rules | |||
of the associated "proto" specification. | of the associated "proto" specification. | |||
Registrations of new formats MUST specify which transport protocols | Registrations of new formats MUST specify which transport protocols | |||
they apply to. | they apply to. | |||
8.2.4. Attribute Names ("att-field") | 8.2.4. Attribute Names ("att-field") | |||
8.2.4.1. New Attributes | 8.2.4.1. New Attributes | |||
Attribute field names ("att-field") MUST be registered with IANA and | Attribute-field names ("att-field") MUST be registered with IANA and | |||
documented, to avoid any issues due to conflicting attribute | documented, to avoid any issues due to conflicting attribute | |||
definitions under the same name. Unknown attributes in SDP are | definitions under the same name. Unknown attributes in SDP are | |||
simply ignored, but conflicting ones that fragment the protocol are a | simply ignored, but conflicting ones that fragment the protocol are a | |||
serious problem. | serious problem. | |||
New attribute registrations are accepted according to the | New attribute registrations are accepted according to the | |||
"Specification Required" policy of [RFC8126], provided that the | "Specification Required" policy of [RFC8126], provided that the | |||
specification includes the following information: | specification includes the following information: | |||
o Contact Name. | o Contact Name. | |||
skipping to change at page 45, line 22 ¶ | skipping to change at page 45, line 22 ¶ | |||
o Reference: A new reference MUST be provided. | o Reference: A new reference MUST be provided. | |||
Items SHOULD be omitted if there is no impact to them as a result of | Items SHOULD be omitted if there is no impact to them as a result of | |||
the attribute update. | the attribute update. | |||
8.2.5. Bandwidth Specifiers ("bwtype") | 8.2.5. Bandwidth Specifiers ("bwtype") | |||
A proliferation of bandwidth specifiers is strongly discouraged. | A proliferation of bandwidth specifiers is strongly discouraged. | |||
New bandwidth specifiers ("bwtype" fields) MUST be registered with | New bandwidth specifiers (<bwtype> sub-field values) MUST be | |||
IANA. The submission MUST reference a standards-track RFC specifying | registered with IANA. The submission MUST reference a standards- | |||
the semantics of the bandwidth specifier precisely, and indicating | track RFC specifying the semantics of the bandwidth specifier | |||
when it should be used, and why the existing registered bandwidth | precisely, and indicating when it should be used, and why the | |||
specifiers do not suffice. | existing registered bandwidth specifiers do not suffice. | |||
IANA has registered the bandwidth specifiers "CT" and "AS" with | IANA has registered the bandwidth specifiers "CT" and "AS" with | |||
definitions as in Section 5.8 of this memo (these definitions update | definitions as in Section 5.8 of this memo (these definitions update | |||
those in [RFC4566]). | those in [RFC4566]). | |||
8.2.6. Network Types ("nettype") | 8.2.6. Network Types ("nettype") | |||
New network types (the "nettype" sub-field) MUST be registered with | New network types (<nettype> sub-field values) MUST be registered | |||
IANA if SDP needs to be used in the context of non-Internet | with IANA if SDP needs to be used in the context of non-Internet | |||
environments. The registration is subject to the "RFC Required" | environments. The registration is subject to the "RFC Required" | |||
policy of [RFC8126]. Although these are not normally the preserve of | policy of [RFC8126]. Although these are not normally the preserve of | |||
IANA, there may be circumstances when an Internet application needs | IANA, there may be circumstances when an Internet application needs | |||
to interoperate with a non-Internet application, such as when | to interoperate with a non-Internet application, such as when | |||
gatewaying an Internet telephone call into the Public Switched | gatewaying an Internet telephone call into the Public Switched | |||
Telephone Network (PSTN). The number of network types should be | Telephone Network (PSTN). The number of network types should be | |||
small and should be rarely extended. A new network type cannot be | small and should be rarely extended. A new network type cannot be | |||
registered without registering at least one address type to be used | registered without registering at least one address type to be used | |||
with that network type. A new network type registration MUST | with that network type. A new network type registration MUST | |||
reference an RFC that gives details of the network type and address | reference an RFC that gives details of the network type and address | |||
skipping to change at page 54, line 28 ¶ | skipping to change at page 54, line 28 ¶ | |||
12.1. Normative References | 12.1. Normative References | |||
[E164] International Telecommunication Union, "E.164 : The | [E164] International Telecommunication Union, "E.164 : The | |||
international public telecommunication numbering plan", | international public telecommunication numbering plan", | |||
ITU Recommendation E.164, November 2010. | ITU Recommendation E.164, November 2010. | |||
[I-D.ietf-mmusic-data-channel-sdpneg] | [I-D.ietf-mmusic-data-channel-sdpneg] | |||
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., | Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., | |||
Marcon, J., and R. Even, "SDP-based Data Channel | Marcon, J., and R. Even, "SDP-based Data Channel | |||
Negotiation", draft-ietf-mmusic-data-channel-sdpneg-18 | Negotiation", draft-ietf-mmusic-data-channel-sdpneg-19 | |||
(work in progress), May 2018. | (work in progress), May 2018. | |||
[I-D.ietf-mmusic-sdp-mux-attributes] | [I-D.ietf-mmusic-sdp-mux-attributes] | |||
Nandakumar, S., "A Framework for SDP Attributes when | Nandakumar, S., "A Framework for SDP Attributes when | |||
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | |||
(work in progress), February 2018. | (work in progress), February 2018. | |||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
<https://www.rfc-editor.org/info/rfc1034>. | <https://www.rfc-editor.org/info/rfc1034>. | |||
skipping to change at page 55, line 52 ¶ | skipping to change at page 55, line 52 ¶ | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
12.2. Informative References | 12.2. Informative References | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | [I-D.ietf-mmusic-sdp-bundle-negotiation] | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | Holmberg, C., Alvestrand, H., and C. Jennings, | |||
"Negotiating Media Multiplexing Using the Session | "Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | |||
negotiation-51 (work in progress), May 2018. | negotiation-52 (work in progress), May 2018. | |||
[ITU.H332.1998] | [ITU.H332.1998] | |||
International Telecommunication Union, "H.323 extended for | International Telecommunication Union, "H.323 extended for | |||
loosely coupled conferences", ITU Recommendation H.332, | loosely coupled conferences", ITU Recommendation H.332, | |||
September 1998. | September 1998. | |||
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description | [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description | |||
Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, | Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, | |||
<https://www.rfc-editor.org/info/rfc2327>. | <https://www.rfc-editor.org/info/rfc2327>. | |||
End of changes. 20 change blocks. | ||||
36 lines changed or deleted | 37 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |