One document matched: draft-yang-dispatch-sip-connection-address-type-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY RFC4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY RFC5234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY I-D.ietf-mmusic-sdp-misc-cap PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-misc-cap'>
<!ENTITY I-D.ietf-mmusic-sdp-capability-negotiation PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-capability-negotiation'>
<!ENTITY I-D.ietf-mmusic-sdp-media-capabilities PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-media-capabilities'>
]>
<rfc category="std" ipr="trust200902" docName="draft-yang-dispatch-sip-connection-address-type-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<front>
<title abbrev="SIP Connection Address Type">Session Description Protocol (SDP) Extension for a SIP Connection Address Type</title>
<author initials="L." surname="Yang" fullname="Lili Yang">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>B2, Huawei Industrial Base</street>
<code>518129</code>
<country>China</country>
</postal>
<phone>+86 136 3263 2065</phone>
<email>kadyyang@huawei.com</email>
</address>
</author>
<author initials="G." surname="Mayer" fullname="Georg Mayer">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>Erdbergstraße 89/20</street>
<code>1030</code>
<city>Wien</city>
<country>Austria</country>
</postal>
<phone>+43 699 1900 5758</phone>
<email>georg.mayer@huawei.com </email>
</address>
</author>
<date month="June" year="2010" />
<area>RAI</area>
<workgroup>Network Working Group</workgroup>
<abstract>
<t>This memo describes use cases, requirements, and protocol extensions for using the
Session Description Protocol (SDP) Offer/Answer model for a SIP connection address
type in order to provide a mechanism which allows the transport of a SIP URI within
the SDP connection line, for use when the actual IP addresses are not known at
offer/answer time.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>There are different scenarios in which a device needs to establish a media session which
is not terminated locally at the establishing device, but at a different entity.
Such an entity can for example be a TV set, which shows the video portion of a
multimedia phone call, whilst the voice portion is still handled by the local phone,
which acts as the controller of the session. Other scenarios require that a device can
redirect parts of a session towards a specific media server in the network, e.g. for
playing announcements or advertisement to a user.
</t>
<t>When the controlling device has access to the IP address of the entity to which it wants to
redirect the media stream, existing SDP capabilities are sufficient (simply include
those IP addresses in the SDP exchange). However, in some scenarios it is not guaranteed
that the controlling device has access to this IP address. In some cases the address of
the related entity is only known as a URI, e.g. a SIP URI.
</t>
</section>
<section anchor="conv" title="Conventions Used in this Document">
<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 RFC-2119 [RFC2119].
</t>
</section>
<section anchor="req" title="Requirements">
<t>This section presents the general requirements that are specific for
the establishment of the collaborative session:
</t>
<t><list style='format REQ-%d:'>
<t>a mechanism that allows a device to redirect a local media stream
to a dedicated media server within the network (e.g. a streaming
server or a TV set), where only a SIP / SIPS URI of the media server
is known to the device, i.e. no IP address is known.
</t>
<t>a mechanism that allows two or more devices to find out whether the remote
device supports SIP / SIPS URI addressing of SDP media streams.
</t>
</list></t>
</section>
<section anchor="overview" title="Overview of Operation">
<t>The mechanism defined in this memo extends SDP and allows describing the transport of a
SIP URI within connection line. New tokens are registered in the "C="
lines to be able to describe a SIP URI. These SDP extensions are described in Section 5.2.
</t>
<section anchor="example" title="Example">
<t>In this example, Alice (sip:alice@example1.net) calls Bob (sip:bob@example-remote.net).
Alice wants to establish two different media streams:
</t>
<t><list style='numbers'>
<t>a voice media stream from Alice's device,
registered with IP address 192.0.2.5
</t>
<t>a video media stream from Anna's device,
of which Alice only knows the SIP address sip:anna@example2.net
</t>
</list></t>
<t>In order to achieve this, Alice needs to indicate the following indications in the SDP:
<figure>
<artwork><![CDATA[
m=audio 49170 RTP/AVP 0 8 3
c=IN IP4 192.0.2.5
m=video 9 RTP/AVP 34
c=URI SIPURI sip:anna@example2.net
]]></artwork>
</figure>
</t>
</section>
</section>
<section anchor="desc" title="Protocol Description">
<section anchor="level" title="Level of Compliance">
<t>Implementations of this specification MUST implement the SDP extensions described
in Section 5.2.
</t>
</section>
<section anchor="extSDP" title="Extensions to SDP">
<t>This section provides the syntax and semantics of the extensions required for
providing a description in SDP of audio or video media streams which are
established at an entity of which only the SIP address is available.
</t>
<section anchor="conndata" title="Connection Data">
<t>According to SDP [RFC4566], the connection data line in SDP has the following
syntax:
</t>
<t> c=<nettype> <addrtype> <connection-address>
</t>
<t>Where <nettype> indicates the network type, <addrtype> indicates the
address type, and the <connection-address> is the connection address,
which is dependent on the address type.
</t>
<t>At the moment, the only network type defined is "IN", which indicates
Internet network type. The address types "IP4" and "IP6" indicate the
type of IP addresses.
</t>
<t>This memo defines a new network type for describing a SIP-based
telecommunication infrastructure.
</t>
</section>
<section anchor="advexample" title="Advanced SDP example">
<t>Using the mechanisms described in SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] and extensions thereof
(SDP media capabilities Negotiation[I-D.ietf-mmusic-sdp-media-capabilities]
and SDP MiscellaneousCapabilities [I-D.ietf-mmusic-sdp-misc-cap]) it is
possible to construct an SDP offer where audio and video media can be
offered using either an IP address or a SIP URI.
<figure>
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
c=IN IP4 192.0.2.5
a=creq:ccap-v0
m=audio 49170 RTP/AVP 0 8 3
m=video 49174 RTP/AVP 34
a=ccap:1 URI SIPSURI sips:anne@example.com
]]></artwork>
<postamble>Figure 1 : SDP offer with SIP network
type connection data alternative
</postamble>
</figure>
</t>
<t>In this example, if the remote side does not support the SIP network type connection
data for the video stream, the video stream would automatically be terminated
by the originating endpoint at IP address 192.0.2.5.
</t>
<t>If the terminating endpoint supports the SIP network type connection data, it will
respond as follows:
<figure>
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
c=IN IP4 192.0.2.5
a=creq:ccap-v0
m=audio 49170 RTP/AVP 0 8 3
m=video 49174 RTP/AVP 34
c=URI SIPSURI sips:anne@example.com
]]></artwork>
<postamble>Figure 2 : SDP offer with SIP network type connection data accepted
</postamble>
</figure>
</t>
</section>
</section>
</section>
<section anchor="syntax" title="Formal Syntax">
<t>The following is the formal Augmented Backus-Naur Form (ABNF) [RFC5234] syntax that
supports the extensions defined in this specification. The syntax is built above the
SDP [RFC4566] grammar. Implementations according to this specification MUST be compliant
with this syntax.
</t>
<t>If the terminating endpoint supports the SIP network type connection data, it will
respond as follows:
<figure>
<artwork><![CDATA[
; extension to the connection field originally specified
; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;nettype and addrtype are defined in RFC 4566
connection-address /= URI-address / "-"
URI-address = SIP-URI/SIPS-URI
]]></artwork>
<postamble>Figure 3 : Formal Syntax of the SDP extensions
</postamble>
</figure>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document provides an extension on top of 4566 [RFC4566].
As such, the security considerations of that document apply.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document instructs IANA to register a number of SDP tokens according to the following data.
</t>
<t>NOTE to IANA: please replace "(this RFC)" with the RFC number for this specification when it
is available - thanks!
</t>
<section anchor="nettype" title='Registration of a new "nettype" value'>
<t>This memo provides instructions to IANA to register a new "nettype"
in the Session Description Protocol Parameters registry [1].
The registration data, according to RFC 4566 [RFC4566] follows.
<figure>
<artwork><![CDATA[
Type SDP Name Reference
---- ------------------ ---------
nettype URI [(this RFC)]
]]></artwork>
</figure>
</t>
</section>
<section anchor="addrtype" title='Registration of a new "addrtype" value'>
<t>This memo provides instructions to IANA to register a new "addrtype"
in the Session Description Protocol Parameters registry [1].
The registration data, according to RFC 4566 [RFC4566] follows.
<figure>
<artwork><![CDATA[
Type SDP Name Reference
---- ------------------ ---------
addrtype SIPURI [(this RFC)]
SIPSURI [(this RFC)]
]]></artwork>
</figure>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3264;
&RFC4566;
&RFC5234;
</references>
<references title="Informative References">
&RFC3261;
&I-D.ietf-mmusic-sdp-misc-cap;
&I-D.ietf-mmusic-sdp-capability-negotiation;
&I-D.ietf-mmusic-sdp-media-capabilities;
</references>
<section anchor='uris' title="URIs">
<t>
<figure>
<artwork><![CDATA[
[1] <http://www.iana.org/assignments/sdp-parameters>
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:37:52 |