draft-ietf-mmusic-sdp-cs-16.txt   draft-ietf-mmusic-sdp-cs-17.txt 
MMUSIC WG M. Garcia-Martin MMUSIC WG M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track S. Veikkolainen Intended status: Standards Track S. Veikkolainen
Expires: July 13, 2013 Nokia Expires: July 18, 2013 Nokia
January 9, 2013 January 14, 2013
Session Description Protocol (SDP) Extension For Setting Up Audio and Session Description Protocol (SDP) Extension For Setting Up Audio and
Video Media Streams Over Circuit-Switched Bearers In The Public Switched Video Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-16 draft-ietf-mmusic-sdp-cs-17
Abstract Abstract
This memo describes use cases, requirements, and protocol extensions This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN). bearers in the Public Switched Telephone Network (PSTN).
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 13, 2013. This Internet-Draft will expire on July 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 27 skipping to change at page 3, line 27
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 14 Mechanism . . . . . . . . . . . . . . . . . . . . 14
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16
5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17 5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Bearer Setup . . . . . . . . . . . . . . . . . . . . . 18 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Populating the cs-correlation attribute . . . . . . . 18 5.3.2. Populating the cs-correlation attribute . . . . . . . 18
5.3.3. Considerations on successful correlation . . . . . . . 19 5.3.3. Considerations on correlations . . . . . . . . . . . . 19
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 20 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19
5.4.1. Originator of the Session . . . . . . . . . . . . . . 20 5.4.1. Originator of the Session . . . . . . . . . . . . . . 19
5.4.2. Contact information . . . . . . . . . . . . . . . . . 20 5.4.2. Contact information . . . . . . . . . . . . . . . . . 20
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21
5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 26 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 26
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 10, line 25 skipping to change at page 10, line 25
numbers, i.e., those including a country code and, as described above numbers, i.e., those including a country code and, as described above
prepended with a '+' sign. Implementations conforming to this prepended with a '+' sign. Implementations conforming to this
specification and using the "E164" address type together with the specification and using the "E164" address type together with the
"PSTN" network type MUST use the 'global-number-digits' construction "PSTN" network type MUST use the 'global-number-digits' construction
specified in RFC 3966 [RFC3966] for representing international E.164 specified in RFC 3966 [RFC3966] for representing international E.164
numbers. This representation requires the presence of the '+' sign, numbers. This representation requires the presence of the '+' sign,
and additionally allows for the presence of one or more 'visual- and additionally allows for the presence of one or more 'visual-
separator' constructions for easier human readability (see separator' constructions for easier human readability (see
Section 5.7). Section 5.7).
Note that <addrtype> and/or <connection-address> MUST NOT be Note that <addrtype> and/or <connection-address> MUST NOT be omitted
omitted when unknown since this would violate basic syntax of SDP when unknown since this would violate basic syntax of SDP [RFC4566].
[RFC4566]. In such cases, they MUST be set to a "-". In such cases, they MUST be set to a "-".
The following are examples of the extension to the connection data The following are examples of the extension to the connection data
line: line:
c=PSTN E164 +441134960123 c=PSTN E164 +441134960123
c=PSTN - - c=PSTN - -
When the <addrtype> is PSTN, the connection address is defined as When the <addrtype> is PSTN, the connection address is defined as
follows: follows:
skipping to change at page 13, line 21 skipping to change at page 13, line 21
a new media-level SDP attribute called "cs-correlation". This "cs- a new media-level SDP attribute called "cs-correlation". This "cs-
correlation" attribute can include any of the "callerid", "uuie", or correlation" attribute can include any of the "callerid", "uuie", or
"dtmf" subfields, which specify additional information required by "dtmf" subfields, which specify additional information required by
the Caller-ID, User to User Information, or DTMF correlation the Caller-ID, User to User Information, or DTMF correlation
mechanisms, respectively. The list of correlation mechanisms may be mechanisms, respectively. The list of correlation mechanisms may be
extended by other specifications, see Section 5.2.3.5 for more extended by other specifications, see Section 5.2.3.5 for more
details. There MUST be at most one "cs-correlation" attribute per details. There MUST be at most one "cs-correlation" attribute per
media description. media description.
The following sections provide more detailed information of these The following sections provide more detailed information of these
subfields. The "cs-correlation" attribute has the following format: subfields. Section 5.7> defined the formal syntax.
a=cs-correlation: <correlation-mechanisms>
correlation-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech /
dfmt-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value]
uuie-mech = "uuie" [":" uuie-value]
dtmf-mech = "dtmf" [":" dtmf-value]
ext-mech = <ext-mech-name>[":"<ext-mech-value>]
The values "callerid", "uuie" and "dtmf" refer to the correlation The values "callerid", "uuie" and "dtmf" refer to the correlation
mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and
Section 5.2.3.4, respectively. The formal Augmented Backus-Naur Section 5.2.3.4, respectively. The formal Augmented Backus-Naur
Format (ABNF) syntax of the "cs-correlation" attribute is presented Format (ABNF) syntax of the "cs-correlation" attribute is presented
in Section 5.7. in Section 5.7.
5.2.3.2. Caller-ID Correlation Mechanism 5.2.3.2. Caller-ID Correlation Mechanism
The Caller-ID correlation mechanisms consists of an exchange of the The Caller-ID correlation mechanisms consists of an exchange of the
skipping to change at page 14, line 27 skipping to change at page 14, line 16
case it cannot populate the SDP appropriately. case it cannot populate the SDP appropriately.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might not be available, e.g., due to policy switched signaling might not be available, e.g., due to policy
restrictions of the network operator or caller restriction due to restrictions of the network operator or caller restriction due to
privacy. privacy.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might be available, but the digit switched signaling might be available, but the digit
representation of the E.164 number might differ from the one representation of the E.164 number might differ from the one
expressed in the SDP. To mitigate this problem implementations expressed in the SDP, due to, e.g., lack of of country code. To
should consider only some of the rightmost digits from the E.164 mitigate this problem implementations should consider only some of
number for correlation. For example, the numbers +44-113-496-0123 the rightmost digits from the E.164 number for correlation. For
and 0113-496-0123 could be considered as the same number. This is example, the numbers +44-113-496-0123 and 0113-496-0123 could be
also the behavior of some cellular phones, which correlate the considered as the same number. This is also the behavior of some
incoming calling party with a number stored in the phone book, for cellular phones, which correlate the incoming calling party with a
the purpose of displaying the caller's name. number stored in the phone book, for the purpose of displaying the
caller's name. Please refer to ITU-T E.164 reccommendation
[ITU.E164.1991] for consideration of the relevant number of digits
to consider.
5.2.3.3. User-User Information Element Correlation Mechanism 5.2.3.3. User-User Information Element Correlation Mechanism
A second correlation mechanism is based on including in SDP a string A second correlation mechanism is based on including in SDP a string
that represents the User-User Information Element that is part of the that represents the User-User Information Element that is part of the
call setup signaling of the circuit-switched bearer. The User-User call setup signaling of the circuit-switched bearer. The User-User
Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and
3GPP TS 24.008 [TS.24.008], among others. The User-User Information 3GPP TS 24.008 [TS.24.008], among others. The User-User Information
Element has a maximum size of 35 or 131 octets, depending on the Element has a maximum size of 35 or 131 octets, depending on the
actual message of the PSTN protocol where it is included and the actual message of the PSTN protocol where it is included and the
skipping to change at page 15, line 31 skipping to change at page 15, line 22
are input to the creation of the value of the "uuie" subfield in the are input to the creation of the value of the "uuie" subfield in the
"cs-correlation" attribute. Therefore, the value of the "uuie" "cs-correlation" attribute. Therefore, the value of the "uuie"
subfield in the "cs-correlation" attribute MUST start with the subfield in the "cs-correlation" attribute MUST start with the
Protocol Discriminator octet, followed by the User Information Protocol Discriminator octet, followed by the User Information
octets. The value of the Protocol Discriminator octet is not octets. The value of the Protocol Discriminator octet is not
specified in this document; it is expected that organizations using specified in this document; it is expected that organizations using
this technology will allocate a suitable value for the Protocol this technology will allocate a suitable value for the Protocol
Discriminator. Discriminator.
Once the binary value of the "uuie" subfield in the "cs-correlation" Once the binary value of the "uuie" subfield in the "cs-correlation"
attribute is created, it MUST be encoded in hexadecimal before it is attribute is created, it MUST be base 16 (also known as "hex")
inserted in SDP. Each octet of binary data to be represented in the encoded before it is inserted in SDP. Please refer to RFC 4648
hexadecimal encoding MUST be mapped to two hexadecimal digits [RFC4648] for a detailed description of base 16 encoding. The
(represented by ASCII characters 0-9 and A-F), each representing four resulting encoded value needs to have an even number of hexadecimal
bits within the octet. The four bits appearing first in the binary digits, and MUST be considered invalid if it has an odd number.
data MUST be mapped to the first hexadecimal digit and the four
subsequent bits in the binary data MUST be mapped to the second
hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the
bit appearing first in the binary data SHALL be most significant.
Thus, the resulting hexadecimal encoded value needs to have an even
number of hexadecimal digits, and MUST be considered invalid if it
has an odd number.
Note that the encoding of the "uuie" subfield of the "cs- Note that the encoding of the "uuie" subfield of the "cs-
correlation" attribute is largely inspired by the encoding of the correlation" attribute is largely inspired by the encoding of the
same value in the User-to-User header field in SIP, according to same value in the User-to-User header field in SIP, according to
the document "A Mechanism for Transporting User to User Call the document "A Mechanism for Transporting User to User Call
Control Information in SIP" [I-D.ietf-cuss-sip-uui]. Control Information in SIP" [I-D.ietf-cuss-sip-uui].
As an example, an endpoint willing to send a UUIE containing a As an example, an endpoint willing to send a UUIE containing a
protocol discriminator with the hexadecimal value of %x56 and an protocol discriminator with the hexadecimal value of %x56 and an
hexadecimal User Information value of %xA390F3D2B7310023 would hexadecimal User Information value of %xA390F3D2B7310023 would
skipping to change at page 17, line 7 skipping to change at page 16, line 40
switched bearer is set up. The endpoint that initiates the call switched bearer is set up. The endpoint that initiates the call
setup attempt sends the DTMF digits according to the procedures setup attempt sends the DTMF digits according to the procedures
defined for the circuit-switched bearer technology used. The defined for the circuit-switched bearer technology used. The
recipient (passive side of the bearer setup) of the call setup recipient (passive side of the bearer setup) of the call setup
attempt collects the digits and compares them with the value attempt collects the digits and compares them with the value
previously received in the SDP. If the digits match, then the call previously received in the SDP. If the digits match, then the call
setup attempt corresponds to that indicated in the SDP. setup attempt corresponds to that indicated in the SDP.
Implementations are advised to select a number of DTMF digits that Implementations are advised to select a number of DTMF digits that
provide enough assurance that the call is related, but on the provide enough assurance that the call is related, but on the
other hand do not prolong the bearer setup time unnecessarily. other hand do not prolong the bearer setup time unnecessarily. A
number of 5 to 10 digits is a good compromise.
As an example, an endpoint willing to send DTMF tone sequence "14D*3" As an example, an endpoint willing to send DTMF tone sequence "14D*3"
would include a "cs-correlation" attribute line as follows: would include a "cs-correlation" attribute line as follows:
a=cs-correlation:dtmf:14D*3 a=cs-correlation:dtmf:14D*3
If the endpoints successfully agree on the usage of the DTMF digit If the endpoints successfully agree on the usage of the DTMF digit
correlation mechanism, but the passive side does not receive any DTMF correlation mechanism, but the passive side does not receive any DTMF
digits after successful circuit-switched bearer setup, or receives a digits after successful circuit-switched bearer setup, or receives a
set of DTMF digits that do not match the value of the "dtmf" set of DTMF digits that do not match the value of the "dtmf"
attribute (including receiving too many digits), the passive side attribute (including receiving too many digits), the passive side
SHOULD treat the circuit-switched bearer as not correlated to the SHOULD consider that this DTMF mechanism has failed to correlate the
ongoing session. incoming call.
DTMF digits can only be sent once the circuit-switched bearer is
set up. In order to suppress alerting for an incoming circuit-
switched call, implementations may choose various mechanisms. For
example, alerting may be suppressed for a certain time period for
incoming call attempts that originate from the number that was
observed during the offer/answer negotiation.
5.2.3.5. Extensions to correlation mechanisms 5.2.3.5. Extensions to correlation mechanisms
New values for the "cs-correlation" attribute may be specified. The New values for the "cs-correlation" attribute may be specified. The
registration policy for new values is "Specification Required", see registration policy for new values is "Specification Required", see
Section 8. Any such specification MUST include a description of how Section 8. Any such specification MUST include a description of how
SDP Offer/Answer mechanism is used to negotiate the use of the new SDP Offer/Answer mechanism is used to negotiate the use of the new
values, taking into account how endpoints determine which side will values, taking into account how endpoints determine which side will
become active or passive (see Section 5.3 for more details). become active or passive (see Section 5.3 for more details).
skipping to change at page 19, line 21 skipping to change at page 19, line 5
switched bearer setup MUST include all correlation mechanisms it switched bearer setup MUST include all correlation mechanisms it
supports in the "a=cs-correlation" attribute, but MUST NOT specify supports in the "a=cs-correlation" attribute, but MUST NOT specify
values for the subfields. values for the subfields.
An endpoint that is willing to become either the active or passive An endpoint that is willing to become either the active or passive
party (by including the "a=setup:actpass" attribute in the Offer), party (by including the "a=setup:actpass" attribute in the Offer),
MUST include all correlation mechanisms it supports in the "a=cs- MUST include all correlation mechanisms it supports in the "a=cs-
correlation" attribute, and MUST also specify values for the correlation" attribute, and MUST also specify values for the
subfields. subfields.
5.3.3. Considerations on successful correlation 5.3.3. Considerations on correlations
Note that, as stated above, it cannot be guaranteed that any given Passive endpoints should expect an incoming CS call for setting up
correlation mechanism will succeed even if the usage of those was the audio bearer. Passive endpoints MAY suppress the incoming CS
agreed beforehand. This is due to the fact that the correlation alert during a certain time periods. Additional restrictions can be
mechanisms require support from the circuit-switched bearer applied, such as the passive endpoint not alerting incoming calls
technology used. originated from the number that was observed uduring the offer/answer
negotiation.
Note that it cannot be guaranteed that any given correlation
mechanism will succeed even if the usage of those was agreed
beforehand. This is due to the fact that the correlation mechanisms
require support from the circuit-switched bearer technology used.
Therefore, even a single positive indication using any of these Therefore, even a single positive indication using any of these
mechanisms SHOULD be interpreted by the passive endpoint so that the mechanisms SHOULD be interpreted by the passive endpoint so that the
circuit-switched bearer establishment is related to the ongoing circuit-switched bearer establishment is related to the ongoing
session, even if the other correlation mechanisms fail. session, even if the other correlation mechanisms fail.
If, after negotiating one or more correlation mechanisms in the SDP If, after negotiating one or more correlation mechanisms in the SDP
offer/answer exchange, an endpoint receives a circuit-switched bearer offer/answer exchange, an endpoint receives a circuit-switched bearer
with no correlation information present, the endpoint has two with no correlation information present, the endpoint has two
choices: it can either treat the call as unrelated, or treat the call choices: it can either treat the call as unrelated, or treat the call
skipping to change at page 21, line 5 skipping to change at page 20, line 44
a "black hole" connection address, which has the property that a "black hole" connection address, which has the property that
packets sent to it will never leave the host which sent them. For packets sent to it will never leave the host which sent them. For
IPv4, this "black hole" connection address is 0.0.0.0, or a domain IPv4, this "black hole" connection address is 0.0.0.0, or a domain
name within the .invalid DNS top level domain. name within the .invalid DNS top level domain.
When using an E.164 address scheme in the context of third-party call When using an E.164 address scheme in the context of third-party call
control, when the User Agent needs to indicate an unknown phone control, when the User Agent needs to indicate an unknown phone
number, it MUST populate the <addrtype> of the SDP "c=" line with a number, it MUST populate the <addrtype> of the SDP "c=" line with a
"-" string. "-" string.
Note that this may result in the recipient of the initial Offer in Note that this may result in the recipient of the initial offer
rejecting the Offer if the recipient of the Offer is not aware of rejecting such offer if the recipient of the offer was not aware
its own E.164 number, and thus concluding that it will not be of its own E.164 number. Consequently it will not be possible to
possible to establish a circuit-switched bearer since neither establish a circuit-switched bearer, since neither party is aware
party is aware of their E.164 number. of their E.164 number.
5.6. Offer/Answer mode extensions 5.6. Offer/Answer mode extensions
In this section, we define extensions to the Offer/Answer model In this section, we define extensions to the Offer/Answer model
defined in The Offer/Answer Model in SDP [RFC3264] to allow for PSTN defined in The Offer/Answer Model in SDP [RFC3264] to allow for PSTN
addresses to be used with the Offer/Answer model. addresses to be used with the Offer/Answer model.
5.6.1. Generating the Initial Offer 5.6.1. Generating the Initial Offer
The Offerer, wishing to use PSTN audio or video stream, MUST populate The Offerer, wishing to use PSTN audio or video stream, MUST populate
skipping to change at page 36, line 5 skipping to change at page 36, line 5
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cuss-sip-uui] [I-D.ietf-cuss-sip-uui]
 End of changes. 15 change blocks. 
61 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/