One document matched: draft-westerlund-avtext-rtcp-sdes-srcname-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-westerlund-avtext-rtcp-sdes-srcname-00"
ipr="trust200902">
<front>
<title abbrev="RTCP SDES SRCNAME">RTCP SDES Item SRCNAME to Label
Individual Sources</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Bo Burman" initials="B." surname="Burman">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 13 11</phone>
<email>bo.burman@ericsson.com</email>
</address>
</author>
<author fullname="Patrik Sandgren" initials="P." surname="Sandgren">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 717 97 41</phone>
<email>patrik.sandgren@ericsson.com</email>
</address>
</author>
<date day="24" month="October" year="2011" />
<abstract>
<t>This document defines a new SDES item called SRCNAME which uniquely
identifies a single media source, like a camera or a microphone. That
way anyone receiving the SDES information from a set of interlinked RTP
sessions can determine which SSRCs are related to the same source. It
can equally be used to label SSRC multiplexed related streams, such as
FEC or Retransmission streams related to the original source stream in
the same session. In addition the new SDES item is also defined for
usage with the SDP source specific media attribute ("a=ssrc") enabling
an end-point to declare and learn the source bindings ahead of receiving
RTP/RTCP packets through signalling.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>RTP has always been a protocol that supports multiple participants
each sending their own media streams in RTP sessions. Previously many
implementations have aimed only at point to point voice over IP with a
single source in each end-point. Even client implementations aimed at
video conferences have often been built with the assumption around
central mixers that only deliver a single media stream per media type.
However, more advanced client implementations may transmit multiple
streams in the same RTP session and there may be tight relations between
different streams and their SSRCs. For example, a client with several
cameras that uses simulcast to send streams with different encodings of
the video from each camera have the need of conveying the relation of
the streams to the receiver. A similar example is a client with several
cameras that uses <xref target="RFC6190">SVC multi-session
transmission</xref> and also here the receiver needs to know which
streams relate to which video source. Other examples of tight relations
are a retransmission stream and its original stream as well as the case
of forward error correction (FEC) where a client can send source streams
and associated repair streams.</t>
<t>CNAME is not sufficient to express this relation although that is
commonly inferred from end-points that have only one media stream per
media type. The primary use of CNAME in multi-source usages is instead
to indicate which end-point and what synchronization context a
particular media stream relates to and that usually means that all
streams sent from a client have the same CNAME. We are neither relying
on using the same SSRC for all streams related to a particular media
source as it is not robust against SSRC collision and forces potentially
cascading SSRC changes between sessions. Also, using the same SSRC is
not possible when SSRC-multiplexing is used.</t>
<t>A common solution to convey the relation between streams is to use
SDP attributes. Session-multiplexed streams can be associated with an
attribute that groups different RTP sessions and SSRC-multiplexed
streams can be grouped at the media level for each RTP session. For
example, in <xref target="RFC5956">Forward Error Correction Grouping
Semantics in the Session Description Protocol</xref> an SDP media level
attribute called "ssrc-group:FEC-FR" is used for grouping FEC
associations when the different streams from a source are
SSRC-multiplexed in the same RTP session. Using SDP attributes may work
fine in the case when the receivers of the streams also get an SDP
describing the bindings of all the streams, but that is not always the
case. One such example is a conference session where clients are
communicating with each other via an RTP Translator. The RTP Translator
forwards all RTP and RTCP traffic from a client to all other clients and
the clients can be prepared to receive any number of streams of certain
specified media. When a new client joins the session the other clients
may not be notified with a SIP Update including a new SDP, instead the
clients will detect the new client's streams via RTP and RTCP. In this
case there is no way for a client to identify if certain streams are
related to each other since that information only was included in the
SDP.</t>
<t><xref target="RFC4588">RTP Retransmission Payload Format</xref>
describes a solution for finding the association between original
streams and retransmission streams when SSRC-multiplexing is used. The
association can be resolved when the receiver receives a retransmission
packet matching a retransmission request sent earlier. However, the RFC
continues with describing that this mechanism might fail if there are
two outstanding requests for the same packet sequence number in two
different original streams of a session. Therefore, to avoid ambiguity
in unicast a receiver MUST NOT have two outstanding requests for the
same packet sequence number in two different original streams before the
association is resolved. For multicast, however, this ambiguity cannot
be avoided and SSRC-multiplexing of original and retransmission streams
is therefore prohibited in multicast. By defining a solution for one to
one mapping between an original stream and any supporting streams this
issue can be avoided in the future. Note: This document does not update
RFC 4588 to use this solution, but it may be done in the future.</t>
<t>To enable an RTP session participant to determine the close relation
of different streams without the above mentioned problems, a new method
for identifying such sources is needed. <xref
target="RFC3550">RTP</xref> defines the Source Description RTCP Packet
(SDES), which contains one or more chunks, each of which is composed of
SDES items describing the SSRC identified in that chunk. None of the
present SDES items is, however, suitable for uniquely identifying a
media source.</t>
<t>Therefore we propose that one defines a new SDES item called the
SRCNAME which with a unique label identifies a single media source, like
a camera or a microphone. The source may also be a particular media mix
or conceptual stream, such as the "most active speaker" output by a RTP
mixer performing stream switching. That way anyone receiving the SDES
information from a set of interlinked RTP sessions or multiple SSRCs in
the same session can determine which SSRCs are the same source.
Connecting streams with SRCNAME can be done irrespective of which
multiplexing type is used and it solves the problems with the current
solutions described above.</t>
<t>It is, however, possible that a receiver will receive the RTP streams
before receiving SDES packets with all SRCNAME items and that would mean
that the receiver cannot make the connections between SSRCs and SRCNAMEs
when starting to receive the media. <xref
target="RFC5576">"Source-Specific Media Attributes in the Session
Description Protocol (SDP)"</xref> defines a way of declaring different
attributes for SSRCs in each session in SDP and if a new source
attribute is added to this framework it would be suitable for conveying
the connections between SSRCs and SRCNAMEs before the media
communication starts. Thus, in addition to the new SDES item we also
define a new SDP source-specific media attribute called srcname, which
enables an end-point to declare and learn the source bindings ahead of
receiving RTP/RTCP packets. Of course, this new SDP source attribute
will not be useful for the case described above when clients did not get
updates with new client's stream bindings, but it will be useful in most
other cases.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor="sec-2" title="SDES Item SRCNAME">
<t>Source Descriptions are a method that should work with all RTP
topologies (assuming that any intermediary node is supporting this item)
and existing RTP extensions. Thus we propose that one defines a new SDES
item called the SRCNAME which with a unique identifier identifies a
single media source, like a camera, a microphone, a particular media
mix, or conceptual stream. That way anyone receiving the SDES
information from a set of interlinked RTP sessions or SSRCs in a single
session can determine which SSRCs are related to the same source.</t>
<t>The SRCNAME is RECOMMENDED to be per communication session unique
random identifiers generated according to <xref
target="RFC6222">"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)"</xref> with the addition that a local counter
enumerating the sources on the host also is concatenated to the key in
step 4 prior to calculating the hash. The SRCNAME included in an RTCP
packet MUST fulfill the requirements Section 6.5 in <xref
target="RFC3550">RTP</xref> puts on SDES item values in general. These
requirements is that it is a <xref target="RFC3629">UTF-8</xref> string
that have a maximum length of 255 bytes.</t>
<t>This SRCNAME's relation to CNAME is the following. CNAME represents
an end-point and a synchronization context. If the different sources
identified by SRCNAMEs should be played out synchronized when receiving
them in a multi-stream context, then the sources need to be in the same
synchronization context. Thus in all cases, all SSRCs with the same
SRCNAME will have the same CNAME. A given CNAME may contain multiple
sets of sources using different SRCNAMEs.</t>
<t>The SDES SRCNAME item follows the same format as the other SDES items
defined in <xref target="RFC3550">RTP</xref>:</t>
<figure>
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRCNAME=TBA1 | length | source name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<!--TBA1 will replaced with a number assigned by IANA. -->
</figure>
<t>When using the SRCNAME SDES item it is equally important to CNAME,
thus it is RECOMMENDED to be included in all full compound RTCP packets
being sent. It MAY also be included in non-compound packets in cases
where the implementation believes that there might be new receivers
needing the information.</t>
</section>
<section anchor="sec-3" title="SRCNAME in SDP">
<t><xref target="RFC5576">"Source-Specific Media Attributes in the
Session Description Protocol (SDP)"</xref> defines a way of declaring
attributes for SSRC in each session in SDP. With a new SDES item, one
can use this framework to define how also the SRCNAME can be provided in
the SDP for each SSRC in each RTP session, thus enabling an end-point to
declare and learn the source bindings ahead of receiving RTP/RTCP
packets.</t>
<t>Hence, we propose a new SDP source attribute called srcname with the
following structure:</t>
<figure>
<artwork><![CDATA[a=ssrc:<ssrc-id> srcname:<srcname>
]]></artwork>
</figure>
<t>The srcname value MUST be identical to the SRCNAME value the media
sender will send in the SDES SRCNAME item in the SDES RTCP packets.</t>
<t>Formal<xref target="RFC5234"> ABNF syntax</xref> for the "srcname"
attribute:</t>
<figure>
<artwork><![CDATA[srcname-attr = "srcname:" srcname
ssrcname = byte-string
; The definition of "byte-string" is in RFC 4566.
attribute =/ srcname-attr
; The definition of "attribute" is in RFC 4566.
]]></artwork>
</figure>
<t></t>
</section>
<section anchor="sec-4" title="Examples">
<t>This section shows SDP examples of declaring the SRCNAME in SDP. Only
the relevant parts of the SDP are shown to improve readability. Please
note that the below examples are all hypothetical as no decision has yet
been to use the SRCNAME mechanism with the respective example.</t>
<section title="Simulcast">
<t>In this use case the end-point is a client with a single audio
source and two video sources and it uses simulcast for sending
different encodings of the same video source. This example is based on
<xref target="I-D.westerlund-avtcore-rtp-simulcast">Using Simulcast in
RTP sessions</xref>. The following SDP describes this.</t>
<figure>
<artwork><![CDATA[s=Simulcast enabled client
m=audio 49200 RTP/AVP 96
a=rtpmap:96 G719/48000/2
a=ssrc:521923924 cname:alice@foo.example.com
a=ssrc:521923924 srcname:2b:45:c7:12:83:e6
a=mid:1
m=video 49300 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42c01e
a=imageattr:* send [x=640,y=360] recv [x=640,y=360] [x=320,y=180]
a=ssrc:192392452 cname:alice@foo.example.com
a=ssrc:192392452 srcname:a3:d3:4b:f1:22:12
a=ssrc:834753488 cname:alice@foo.example.com
a=ssrc:834753488 srcname:7a:39:a9:3e:28:f7
a=mid:2
a=content:main
m=video 49400 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42c00d
a=imageattr:96 send [x=320,y=180]
a=ssrc:239245219 cname:alice@foo.example.com
a=ssrc:239245219 srcname:a3:d3:4b:f1:22:12
a=ssrc:734623563 cname:alice@foo.example.com
a=ssrc:734623563 srcname:7a:39:a9:3e:28:f7
a=mid:3
a=sendonly
]]></artwork>
</figure>
<t>The audio session is proposing to use one stereo stream of G.719
and the video sessions are proposing to send two different encodings
of each video source, one with the resolution 640x360 and one with
320x180. The end-point also declares the SSRCs it intends to use with
bindings to CNAME and SRCNAME, enabling the receiver of the SDP to
bind together the video streams that originates from the same video
camera.</t>
<t>The use of the srcname attribute in the SDP is optional and the
information can be retrieved from RTCP reporting, but it will then not
be possible to correctly relate the video sources until the first RTCP
report is received.</t>
</section>
<section title="SVC with multi-session transmission">
<t>Here an example is shown of a client that uses SVC with
multi-session transmission as described in <xref target="RFC6190">RTP
Payload Format for Scalable Video Coding</xref>. <xref
target="RFC6190">RTP Payload Format for Scalable Video Coding</xref>
only describes examples for a client with one video source and the
decoder dependencies of the different sessions are grouped using the
Session grouping DDP attribute as defined in <xref
target="RFC5583">Signaling Media Decoding Dependency in the Session
Description Protocol (SDP)</xref> and implicitly CNAME.</t>
<t>However, if a client has two video sources and wishes to use
multi-session transmission and send streams from both sources in each
session an additional grouping mechanism is needed to group the
different streams in the different sessions. SRCNAME is suitable for
this and here we show an example where the DDP attribute groups the
different sessions and the SRCNAME is used to relate the different
SSRCs in each RTP session to one of the two video sources.</t>
<figure>
<artwork><![CDATA[s=SVC MST client
a=group:DDP L1 L2 L3
m=video 20000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=1;
mst-mode=NI-TC; sprop-parameter-sets={sps0},{pps0};
a=ssrc:743947584 cname:bob@foo.example.com
a=ssrc:743947584 srcname:7e:83:c1:82:e8:a6
a=ssrc:283894947 cname:bob@foo.example.com
a=ssrc:283894947 srcname:b3:8d:f1:18:c5:84
a=mid:L1
m=video 20002 RTP/AVP 97
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
mst-mode=NI-T; sprop-parameter-sets={sps1},{pps1};
a=ssrc:492784823 cname:bob@foo.example.com
a=ssrc:492784823 srcname:7e:83:c1:82:e8:a6
a=ssrc:892362397 cname:bob@foo.example.com
a=ssrc:892362397 srcname:b3:8d:f1:18:c5:84
a=mid:L2
a=depend:97 lay L1:96
m=video 20004 RTP/AVP 98
a=rtpmap:98 H264-SVC/90000
a=fmtp:98 profile-level-id=53001F; packetization-mode=1;
mst-mode=NI-T; sprop-parameter-sets={sps2},{pps2};
a=ssrc:184562894 cname:bob@foo.example.com
a=ssrc:184562894 srcname:7e:83:c1:82:e8:a6
a=ssrc:305605682 cname:bob@foo.example.com
a=ssrc:305605682 srcname:b3:8d:f1:18:c5:84
a=mid:L3
a=depend:98 lay L1:96 L2:97
]]></artwork>
</figure>
<t>Thus, the client declares that it will send two video streams in
each RTP session and the receiver is then able to relate the streams
in the different sessions by using the SRCNAME binding. Without the
SRCNAME binding it would not be possible for the receiver to know
which streams belong to the same source.</t>
</section>
<section title="Retransmission">
<t>This use case shows how SRCNAME can be used to connect
retransmission streams to the original streams in the case of SSRC
multiplexed <xref target="RFC4588">RTP retransmission</xref>. This is
included to exemplify how RTP retransmission could be updated to
provide explicit bindings between the source and the repair stream,
but just an example and not a specification.</t>
<figure>
<artwork><![CDATA[s=SSRC-multiplexed retransmission client
m=audio 49200 RTP/AVP 96
a=rtpmap:96 G719/48000/2
a=ssrc:521923924 cname:carol@foo.example.com
a=ssrc:521923924 srcname:88:3a:93:c1:3f:71
a=mid:1
m=video 49300 RTP/AVP 96 97
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=42c01e
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=200
a=ssrc:192392452 cname:carol@foo.example.com
a=ssrc:192392452 srcname:7b:6e:23:8b:31:a8
a=ssrc:834753488 cname:carol@foo.example.com
a=ssrc:834753488 srcname:7b:6e:23:8b:31:a8
a=ssrc:682394013 cname:carol@foo.example.com
a=ssrc:682394013 srcname:c4:98:d9:1a:fc:58
a=ssrc:284576129 cname:carol@foo.example.com
a=ssrc:284576129 srcname:c4:98:d9:1a:fc:58
a=mid:2
]]></artwork>
</figure>
<t>The client proposes to send two original video streams in the video
session and a retransmission stream for each one of them. The
retransmission streams are associated with the respective original
stream by using the same SRCNAME and a receiver would then know which
original stream a certain retransmission stream is associated with.
This solves the ambiguity problem when SSRC-multiplexing is used for
retransmission and it enables SSRC-multiplexing of original and
retransmission streams to be used also in multicast sessions.</t>
</section>
<section title="Forward Error Correction">
<t><xref target="RFC5956">Forward Error Correction Grouping Semantics
in the Session Description Protocol</xref> defines two SDP attributes
for grouping the associated source and FEC-based repair streams. One
can be used for grouping different RTP sessions and the other can be
used for grouping SSRCs in the same RTP session, i.e. when session-
respective SSRC-multiplexing is used. However, it may be advantageous
to SSRC-multiplex the source streams in one RTP session and the repair
streams in another since that gives a receiver the possibility to
reject the repair session in case it does not support the proposed
FEC. In this case the above mentioned grouping attributes cannot be
used to associate the repair streams with the respective source stream
since grouping of SSRCs cannot be made across RTP sessions. The
following example shows how SRCNAME can be used for that.</t>
<figure>
<artwork><![CDATA[s=FEC client
a=group:FEC-FR 1 2
m=video 49200 RTP/AVP 100
a=rtpmap:100 MP2T/90000
a=ssrc:847612849 cname:dave@foo.example.com
a=ssrc:847612849 srcname:45:a8:f4:19:b4:c3
a=ssrc:558237845 cname:dave@foo.example.com
a=ssrc:558237845 srcname:b8:58:29:c7:2f:9e
a=mid:1
m=application 49300 RTP/AVP 101
a=rtpmap:101 1d-interleaved-parityfec/90000
a=fmtp:101 L=5; D=10; repair-window=200000
a=ssrc:389572053 cname:dave@foo.example.com
a=ssrc:389572053 srcname:45:a8:f4:19:b4:c3
a=ssrc:185729479 cname:dave@foo.example.com
a=ssrc:185729479 srcname:b8:58:29:c7:2f:9e
a=mid:2
]]></artwork>
</figure>
<t>In this example the client proposes to send two video streams in
one session and two repair streams in the other session. The repair
streams are associated with the respective video stream by using the
same SRCNAME. When receiving either this SDP or the SDES SRCNAME
packets a receiver can make the connection between the source streams
and the repair streams. Even a client not receiving the SDP will be
able to do the association if it has established one RTP session for
receiving source streams and another for receiving repair streams.</t>
</section>
</section>
<section title="Usage with the Offer/Answer Model">
<t>The SDP offer/answer procedures for the a=ssrc is specified in <xref
target="RFC5576">Source-Specific Media Attributes in the Session
Description Protocol (SDP)</xref>.</t>
</section>
<section title="Backward Compatibility">
<t>Clients not supporting SRCNAME will not have the possibility to bind
different streams to a specific media source, since they will not
understand the SRCNAME SDES item. However, sending SRCNAME SDES items to
a client not supporting it should not impose any problems since all
clients should be prepared that new SDES items may be specified
according to <xref target="RFC3550">RTP</xref>.</t>
<t>According to the definition of SDP attributes in <xref
target="RFC4566">SDP: Session Description Protocol</xref>, if an
attribute is received that is not understood, it MUST be ignored by the
receiver. So a receiver not supporting the ssrc attribute will simply
ignore it.</t>
<t><xref target="RFC5576">Source-Specific Media Attributes in the
Session Description Protocol (SDP)</xref> defines rules of how new
source attributes should be registered, which means that a receiver
supporting RFC5576 should be prepared that new source attributes may be
defined. This means that a user supporting some of the source attributes
should not have any problems when the user receives an SDP with unknown
source attributes.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>Following the guidelines in <xref target="RFC4566">SDP</xref>, in
<xref target="RFC5888">The Session Description Protocol (SDP) Grouping
Framework</xref>, and in <xref target="RFC3550">RTP</xref>, the IANA is
requested to register:</t>
<t><list style="numbers">
<t>A new SDES item named SRCNAME, as defined in <xref
target="sec-2"></xref>. This item needs to be assigned an identifier
TBA1.</t>
<t>A new SDP source attribute named srcname, as defined in <xref
target="sec-3"></xref>.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The SDES SRCNAMEs being opaque identifiers could potentially carry
additional meanings or function as overt channel. If the SRCNAME would
be permanent between sessions, they have the potential for compromising
the users’ privacy as they can be tracked between sessions. See
<xref target="RFC6222">Guidelines for Choosing RTP Control Protocol
(RTCP) Canonical Names (CNAMEs)</xref> for more discussion.</t>
<t>A third party modification of the srcname labels either in the RTCP
SDES items or in the SDP a=ssrc attribute can cause service disruption.
By modifying labels the wrong streams could be associated, with
potentially serious effects including media disruptions. If streams that
are to be associated aren't associated, then another type of failures
occur. To prevent modification, insertion or deletion of the srcname
labels the carrying channel needs to be protected by integrity
protection and source authentication. For RTCP various solutions exist,
such as <xref target="RFC3711">SRTP</xref>, <xref
target="RFC4347">DTLS</xref>, <xref target="RFC4301">IPsec</xref>. For
protecting the SDP the signalling channel needs to provide protection.
For <xref target="RFC3261">SIP S/MIME</xref> are the ideal, and hop by
hop<xref target="RFC5246"> TLS</xref> provides at least some protection,
although not perfect. For SDP's retrieved using <xref
target="RFC2326">RTSP DESCRIBE</xref> TLS would be the RECOMMENDED
solution.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.3629'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.5234'?>
<?rfc include='reference.RFC.5576'?>
<?rfc include='reference.RFC.6222'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.westerlund-avtcore-rtp-simulcast'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.4347'?>
<?rfc include='reference.RFC.2326'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3711'?>
<?rfc include='reference.RFC.4588'?>
<?rfc include='reference.RFC.5246'?>
<?rfc include='reference.RFC.5583'?>
<?rfc include='reference.RFC.5888'?>
<?rfc include='reference.RFC.5956'?>
<?rfc include='reference.RFC.6190'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:49 |