One document matched: draft-boulton-sip-control-framework-04.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>A Control Framework for the Session Initiation Protocol (SIP)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="A Control Framework for the Session Initiation Protocol (SIP)">
<meta name="generator" content="xml2rfc v1.31 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.full td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">C. Boulton</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Ubiquity Software Corporation</td></tr>
<tr><td class="header">Intended status: Informational</td><td class="header">T. Melanchuk</td></tr>
<tr><td class="header">Expires: April 26, 2007</td><td class="header">BlankSpace</td></tr>
<tr><td class="header"> </td><td class="header">S. McGlashan</td></tr>
<tr><td class="header"> </td><td class="header">Hewlett-Packard</td></tr>
<tr><td class="header"> </td><td class="header">A. Shiratzky</td></tr>
<tr><td class="header"> </td><td class="header">Radvision</td></tr>
<tr><td class="header"> </td><td class="header">October 23, 2006</td></tr>
</table></td></tr></table>
<h1><br />A Control Framework for the Session Initiation Protocol (SIP)<br />draft-boulton-sip-control-Framework-04</h1>
<h3>Status of this Memo</h3>
<p>
By submitting this Internet-Draft,
each author represents that any applicable patent or other IPR claims of which
he or she is aware have been or will be disclosed,
and any of which he or she becomes aware will be disclosed,
in accordance with Section 6 of BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on April 26, 2007.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2006).</p>
<h3>Abstract</h3>
<p>This document describes a Framework and protocol for application deployment
where the application logic and processing are distributed. The framework uses
the Session Initiation Protocol (SIP) to establish an application-level control
mechanism between application servers and associated external servers
such as media servers.
</p>
<p>The motivation for the creation of this Framework is to provide an interface
suitable to meet the requirements of a distributed, centralized conference system,
as defined by the XCON work group of the IETF. It is not, however, limited to
this scope and it is envisioned that this generic Framework will be used for a
wide variety of de-coupled control architectures between network entities.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#terminology">2.</a>
Conventions and Terminology<br />
<a href="#sec:overview">3.</a>
Overview<br />
<a href="#anchor2">4.</a>
Locating External Server Resources<br />
<a href="#sec:UAC">5.</a>
Control Client SIP UAC Behavior - Control Channel Setup<br />
<a href="#sec:UAC_media_dialog">5.1.</a>
Control Client SIP UAC Behavior - Media Dialogs<br />
<a href="#sec:UAS">6.</a>
Control Server SIP UAS Behavior - Control Channel Setup<br />
<a href="#sec:CommandCon">7.</a>
Control Framework Interactions<br />
<a href="#sec:constructing_requests">7.1.</a>
Constructing Requests<br />
<a href="#sec:sending_control">7.1.1.</a>
Sending CONTROL<br />
<a href="#sec:sending_report">7.1.2.</a>
Sending REPORT<br />
<a href="#sec:constructing_responses">7.2.</a>
Constructing Responses<br />
<a href="#sec:response_code_descriptions">8.</a>
Response Code Descriptions<br />
<a href="#sec:200">8.1.</a>
200 Response Code<br />
<a href="#sec:202">8.2.</a>
202 Response Code<br />
<a href="#sec:400">8.3.</a>
400 Response Code<br />
<a href="#sec:403">8.4.</a>
403 Response Code<br />
<a href="#sec:481">8.5.</a>
481 Response Code<br />
<a href="#sec:500">8.6.</a>
500 Response Code<br />
<a href="#sec:Control_Packages">9.</a>
Control Packages<br />
<a href="#sec:Control_Package_Name">9.1.</a>
Control Package Name<br />
<a href="#sec:Message_Usage">9.2.</a>
Framework Message Usage<br />
<a href="#anchor3">9.3.</a>
Common XML Support<br />
<a href="#sec:Control_Bodies">9.4.</a>
CONTROL Message Bodies<br />
<a href="#sec:REPORT_Bodies">9.5.</a>
REPORT Message Bodies<br />
<a href="#sec:Event">9.5.1.</a>
Events<br />
<a href="#sec:Examples">9.6.</a>
Examples<br />
<a href="#sec:NAT">10.</a>
Network Address Translation (NAT)<br />
<a href="#sec:formal_syntax">11.</a>
Formal Syntax<br />
<a href="#sec:sip_formal_syntax">11.1.</a>
SIP Formal Syntax<br />
<a href="#sec:control_formal_syntax">11.2.</a>
Control Framework Formal Syntax<br />
<a href="#Examples">12.</a>
Examples<br />
<a href="#anchor4">13.</a>
Security Considerations<br />
<a href="#sec:IANA_Considerations">14.</a>
IANA Considerations<br />
<a href="#anchor5">14.1.</a>
IANA Registration of the 'escs' Option Tag<br />
<a href="#anchor6">14.2.</a>
Control Package Registration Information<br />
<a href="#anchor7">14.2.1.</a>
Control Package Registration Template<br />
<a href="#anchor8">14.3.</a>
SDP Transport Protocol<br />
<a href="#anchor9">14.3.1.</a>
TCP/ESCS<br />
<a href="#sec:tcp_tag">14.3.2.</a>
TCP/TLS/ESCS<br />
<a href="#anchor10">14.4.</a>
SDP Attribute Names<br />
<a href="#anchor11">14.5.</a>
SIP Response Codes<br />
<a href="#anchor12">15.</a>
Acknowledgments<br />
<a href="#sec:appendix_a">16.</a>
Appendix A<br />
<a href="#sec:dialog_xml">16.1.</a>
Common Dialog/Multiparty Reference Schema<br />
<a href="#rfc.references1">17.</a>
References<br />
<a href="#rfc.references1">17.1.</a>
Normative References<br />
<a href="#rfc.references2">17.2.</a>
Informative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>Applications are often developed using an architecture where the application
logic and processing activities are distributed. Commonly, the application logic
runs on "application servers" whilst the processing runs on external
servers, such as "media servers". This document focuses on the framework
and protocol between the application server and external processing server. The
motivation for this framework comes from a set of requirements for Media Server
Control, which can be found in the 'Media Control Protocol Framework'
document<a class='info' href='#I-D.dolly-xcon-mediacntrlframe'>[8]<span> (</span><span class='info'>Dolly, M., “Media Control Protocol Requirements,” September 2006.</span><span>)</span></a>. While the Framework
is not media server control specific, it is the primary driver and use case for
this work. It is intended that the framework contained in this document will
be used for a plethora of appropriate device control scenarios.
</p>
<p>This document does not define a SIP based extension that can be used directly
for the control of external components. The framework mechanism must be extended
by other documents that are known as "Control Packages". A comprehensive
set of guidelines for creating "Control Packages" is described in
<a class='info' href='#sec:Control_Packages'>Section 9<span> (</span><span class='info'>Control Packages</span><span>)</span></a>.
</p>
<p>Current IETF transport device control protocols, such as
<a class='info' href='#RFC3525'>megaco<span> (</span><span class='info'>Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, “Gateway Control Protocol Version 1,” June 2003.</span><span>)</span></a> [7], while excellent for controlling media
gateways that bridge separate networks, are troublesome for supporting media-rich
applications in SIP networks, because they duplicate many of the functions inherent
in SIP. Rather than relying on single protocol session establishment, application
developers need to translate between two separate mechanisms.
</p>
<p>Application servers traditionally use SIP third party call control
<a class='info' href='#RFC3725'>RFC 3725<span> (</span><span class='info'>Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.</span><span>)</span></a> [11] to establish media sessions from SIP user
agents to a media server. SIP, as defined in <a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2],
also provides the ideal rendezvous mechanism for establishing and maintaining
control connections to external server components. The control connections can
then be used to exchange explicit command/response interactions that allow for
media control and associated command response results.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Conventions and Terminology</h3>
<p>In this document, <a class='info' href='#RFC2119'>BCP 14/RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [1] defines the
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant implementations.
</p>
<p>The following additional terms are defined for use in this document:
</p>
<blockquote class="text"><dl>
<dt>B2BUA:</dt>
<dd> A B2BUA is a Back-to-Back SIP User Agent.
</dd>
<dt>Control Server:</dt>
<dd> A Control Server is an entity that performs
a service, such as media processing, on behalf of a Control Client.
For example, a media server offers mixing, announcement, tone
detection and generation, and play and record services. The
Control Server in this case, has a direct
<a class='info' href='#RFC3550'>RTP<span> (</span><span class='info'>Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.</span><span>)</span></a> [14] relationship with the source or sink
of the media flow. In this document, we often refer to the Control
Server simply as "the Server".
</dd>
<dt>Control Client:</dt>
<dd> A Control Client is an entity that
requests processing from a Control Server. Note that the Control
Client may not have any processing capabilities whatsoever. For example,
the Control Client may be an Application Server (B2BUA) or other endpoint
requesting manipulation of a third-party's media stream, that terminates on
a media server acting in the role of a Control Server. In this
document, we often refer to the Control Client
simply as "the Client".
</dd>
<dt>Control Channel:</dt>
<dd> A Control Channel is a reliable
connection between a Client and Server that is used to exchange
Framework messages. The term "Connection" is used
synonymously within this document.
</dd>
<dt>Framework Message:</dt>
<dd> A Framework Message is a message
on a Control Channel that has a type corresponding to one of
the Methods defined in this document. A Framework message is
often referred to by its method, such as a "CONTROL message".
</dd>
<dt>Method:</dt>
<dd> A Method is the type of a framework message.
Three Methods are defined in this document: SYNCH, CONTROL, and REPORT.
</dd>
<dt>Control Command:</dt>
<dd> A Control Command is an application
level request from a Client to a Server. Control Commands are carried in the
body of CONTROL messages. Control Commands are defined in separate
specifications known as "Control Packages".
</dd>
<dt>framework transaction:</dt>
<dd> A framework transaction
is defined as a sequence composed of a control framework
message originated by either a Control Client or Control Server
and responded to with a control Framework response code message.
Note that the control framework has no "provisional" responses.
A control framework transaction MUST complete within Transaction-Timeout
time.
</dd>
<dt>extended framework transaction:</dt>
<dd> An extended framework
transaction is used to extend the lifetime of a CONTROL method
transaction when the Control Command it carries cannot be completed within
Command-Timeout milliseconds. A Server extends the lifetime of a
CONTROL method transaction by sending a 202 response code followed
by one or more REPORT transactions as specified in
<a class='info' href='#sec:sending_report'>Section 7.1.2<span> (</span><span class='info'>Sending REPORT</span><span>)</span></a>.
Extended framework transactions allow command failures
to be discovered at the transaction layer.
</dd>
<dt>Transaction-Timeout:</dt>
<dd> the maximum allowed time between
a control Client or Server issuing a framework message
and receiving a corresponding response. The value for the timeout
should be based on a multiple of the network RTT plus Command-Timeout
milliseconds to allow for message parsing and processing.
</dd>
<dt></dt>
<dd>[timm: Do we want to differentiate between Control
and Report transaction times - the latter does need to allow for
command processing. Do we even need a transaction time for REPORT
messages or is it sufficient to simply have transaction times
for CONTROL messages and rely on TCP for REPORT?] What about SYNCH?
It currently has its own independent timing.
</dd>
</dl></blockquote><p>
</p>
<a name="sec:overview"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Overview</h3>
<p>This document details mechanisms for establishing, using, and terminating a
reliable channel using SIP for the purpose of controlling an external server. The
following text provides a non-normative overview of the mechanisms used. Detailed,
normative guidelines are provided later in the document.
</p>
<p>Control channels are negotiated using standard SIP mechanisms that would be
used in a similar manner to creating a SIP voice session.
<a class='info' href='#fig:basic_arch'>Figure 1<span> (</span><span class='info'>Basic Architecture</span><span>)</span></a> illustrates a simplified view of the proposed
mechanism. It highlights a separation of the SIP signaling traffic and the
associated control channel that is established as a result of the SIP interactions.
</p>
<p>The use of SIP for the specified mechanism provides many inherent
capabilities which include:-
</p>
<ul class="text">
<li>Service location - Use SIP Proxies or Back-to-Back User Agents for
discovering Control Servers.
</li>
<li>Security mechanisms - Leverage established security mechanisms such
as Transport Layer Security (TLS) and Client Authentication.
</li>
<li>Connection maintenance - The ability to re-negotiate a connection,
ensure it is active, audit parameters, and so forth.
</li>
<li>Agnostic - Generic protocol allows for easy extension.
</li>
</ul><p>
</p>
<p>As mentioned in the previous list, one of the main benefits of using SIP as the
session control protocol is the "Service Location" facilities provided.
This applies at both a routing level, where <a class='info' href='#RFC3263'>RFC 3263<span> (</span><span class='info'>Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.</span><span>)</span></a> [4]
provides the physical location of devices, and at the Service level, using Caller
Preferences<a class='info' href='#RFC3840'>[12]<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.</span><span>)</span></a> and Callee Capabilities<a class='info' href='#RFC3841'>[13]<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.</span><span>)</span></a>.
The ability to select a Control Server based on Service level capabilities is
extremely powerful when considering a distributed, clustered architecture
containing varying services (for example Voice, Video, IM). More detail on
locating Control Server resources using these techniques is outlined in
<a class='info' href='#sec:UAC'>Section 5<span> (</span><span class='info'>Control Client SIP UAC Behavior - Control Channel Setup</span><span>)</span></a> of this document.
</p><br /><hr class="insert" />
<a name="fig:basic_arch"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1: Basic Architecture </b></font><br /></td></tr></table><hr class="insert" />
<p>The example from <a class='info' href='#fig:basic_arch'>Figure 1<span> (</span><span class='info'>Basic Architecture</span><span>)</span></a> conveys a 1:1 connection
between the Control Client and the Control Server. It is possible, if required,
for multiple control channels using separate SIP dialogs to be established between
the Control Client and the Control Server entities. Any of the connections created
between the two entities can then be used for Server control interactions.
The control connections are agnostic to any media sessions. Specific media
session information can be incorporated in control
interaction commands (which themselves are defined in external packages)
using the XML schema defined in <a class='info' href='#sec:appendix_a'>Section 16<span> (</span><span class='info'>Appendix A</span><span>)</span></a>.
The ability to have multiple control channels allows for
stronger redundancy and the ability to manage high volumes of traffic in busy
systems.
</p>
<p>[Editors Note: Still under discussion. How does an app server know, when there
are multiple external servers, which specific server has any given media session?
Next version of the draft will discuss the correlation procedures. The App server
needs a control channel with the media server and needs to know which channel to
use once the media session has been established. Sounds like a GRUU usage?]
</p>
<p>Consider the following simple example for session establishment between a Client
and a Server (Note: Some lines in the examples are removed for clarity
and brevity). Note that the roles discussed are logical and can change during a
session, if the Control Package allows.
</p>
<p>The Client constructs and sends a SIP INVITE request to the external Server.
The request contains the SIP option tag "escs" in a SIP
"Require" header for the purpose of forcing the use of the mechanism
described in this document. The SDP payload includes the required information for
control channel negotiation. The <a class='info' href='#RFC4145'>COMEDIA<span> (</span><span class='info'>Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.</span><span>)</span></a> [6]
specification for setting up and maintaining reliable connections is used (more
detail available in later sections).
</p>
<p>The client MUST include details of control packages that are supported and,
more specifically, that will be used within the control channel created. This is
achieved through the inclusion of a SIP "Control-Packages" header. The
"Control-Packages" header is defined and described later in this
document.
</p>
<p>Client Sends to External Server:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
INVITE sip:External-Server@example.com SIP/2.0
To: <sip:External-Server@example.com>
From: <sip:Client@example.com>;tag=64823746
Require: escs
Control-Packages: <example-package>
Call-ID: 7823987HJHG6
Content-Type: application/sdp
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 controller.example.com
m=application 7575 TCP/ESCS
a=setup:active
a=connection:new
</pre></div>
<p>On receiving the INVITE request, the external Server supporting this mechanism
generates a 200 OK response containing appropriate SDP.
</p>
<p>External Server Sends to Client:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SIP/2.0 200 OK
To: <sip:External-Server@example.com>;tag=28943879
From: <sip:Client@example.com>;tag=64823746
Call-ID: 7823987HJHG6
Content-Type: application/sdp
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 mserver.example.com
m=application 7563 TCP/ESCS
a=setup:passive
a=connection:new
</pre></div>
<p>The Control Client receives the SIP 200 OK response and extracts the relevant
information (also sending a SIP ACK). It creates an outgoing (as specified by the
SDP 'setup:' attribute) TCP connection to the Control Server. The connection address
(taken from 'c=') and port (taken from 'm=')are used to identify the remote part
in the new connection.
</p>
<p>Once established, the newly created connection can be used to exchange control
language requests and responses. If required, after the control channel has been
setup, media sessions can be established using standard SIP third party call
control.
</p>
<p>[Editors Note: See previous note:this is where we may need to mention how an App
Server knows which external Server is responsible for any given media session.]
</p>
<p><a class='info' href='#fig:call_arch'>Figure 4<span> (</span><span class='info'>Participant Architecture</span><span>)</span></a> provides a simplified example where the proposed
framework is used to control a User Agent's RTP session. (1) in brackets represents
the SIP dialog and dedicated control channel previously described in this overview
section.
</p><br /><hr class="insert" />
<a name="fig:call_arch"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+--------Control SIP Dialog(1)---------+
| |
v v
+-----+ +--+--+
+------(2)------>| SIP |---------------(2)------------->| SIP |
| |Stack| |Stack|
| +---+-----+---+ +---+-----+---+
| | | | |
| | Control |<--Control Channel(1)-->| |
| | Client | | Control |
| +-------------+ | Server |
+--+--+ | |
|User | | |
|Agent|<=====================RTP(2)===================>| |
+-----+ +-------------+
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 4: Participant Architecture </b></font><br /></td></tr></table><hr class="insert" />
<p>(2) from <a class='info' href='#fig:call_arch'>Figure 4<span> (</span><span class='info'>Participant Architecture</span><span>)</span></a> represents the User Agent SIP dialog
interactions and associated media flow. A User Agent would create a SIP dialog
with the Control Client entity. The Control Client entity will also create a
related dialog to the Control Server (B2BUA type functionality). Using the
interaction illustrated by (2), the User Agent is able to negotiate media
capabilities with the Control Server using standard SIP mechanisms as defined
in <a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2] and
<a class='info' href='#RFC3264'>RFC 3264<span> (</span><span class='info'>Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.</span><span>)</span></a> [5].
</p>
<p>If not present in the SDP received by the Control Client from the User Agent(2),
a media label SDP attribute, which is defined in
<a class='info' href='#I-D.ietf-mmusic-sdp-media-label'>[10]<span> (</span><span class='info'>Levin, O. and G. Camarillo, “The SDP (Session Description Protocol) Label Attribute,” January 2005.</span><span>)</span></a>, should be inserted for every
media description (identified as m= line as defined in
<a class='info' href='#I-D.ietf-mmusic-sdp-new'>[9]<span> (</span><span class='info'>Handley, M., “SDP: Session Description Protocol,” January 2006.</span><span>)</span></a>). This provides flexibility for the
Control Client, because it can generate control messages that specify a particular
Media stream (between User Agent and Control Server) within a SIP media dialog.
If a Media label is not included in the control message, it applies to all
media associated with the dialog.
</p>
<p>A non 2xx class SIP response received for the INVITE request indicates that
no SIP dialog has been created and is treated as specified
<a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2]. One exception to this is the "496"
(TODO:need to pick an appropriate response code) response code whose operation is
defined in <a class='info' href='#sec:UAS'>Section 6<span> (</span><span class='info'>Control Server SIP UAS Behavior - Control Channel Setup</span><span>)</span></a>.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Locating External Server Resources</h3>
<p>Section will describe mechanisms for locating an external Server.
</p>
<a name="sec:UAC"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Control Client SIP UAC Behavior - Control Channel Setup</h3>
<p>On creating a new SIP INVITE request, a UAC can insist on using the mechanisms
defined in this document. This is achieved by inserting a SIP Require header
containing the option tag 'escs'. A SIP Require header with the value 'escs' MUST
NOT be present in any other SIP request type.
</p>
<p>If on creating a new SIP INVITE request, a UAC does not want to insist on the
usage of the mechanisms defined in this document but merely that it supports them,
a SIP Supported header MUST be included in the request with the option tag 'escs'.
</p>
<p>The SIP INVITE MUST include a SIP "Control-Packages" header which MUST
contain at least one valid entry and can contain multiple control packages if
required.
</p>
<p>If a reliable response is received (as defined
<a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2] and <a class='info' href='#RFC3262'>RFC 3262<span> (</span><span class='info'>Rosenberg, J. and H. Schulzrinne, “Reliability of Provisional Responses in Session Initiation Protocol (SIP),” June 2002.</span><span>)</span></a> [3])
that contains a SIP Require header containing the option tag 'escs', the mechanisms
defined in this document are applicable to the newly created dialog.
</p>
<p>Before the UAC can send a request, it MUST include a valid session description
using the Session Description Protocol defined in
<a class='info' href='#I-D.ietf-mmusic-sdp-new'>[9]<span> (</span><span class='info'>Handley, M., “SDP: Session Description Protocol,” January 2006.</span><span>)</span></a>. The following information defines the
composition of some specific elements of the SDP payload that MUST be adhered to
for compliancy to this specification.
</p>
<p>The Connection Data line in the SDP payload is constructed as specified in
<a class='info' href='#I-D.ietf-mmusic-sdp-new'>[9]<span> (</span><span class='info'>Handley, M., “SDP: Session Description Protocol,” January 2006.</span><span>)</span></a>:
</p>
<p>c=<nettype> <addrtype> <connection-address>
</p>
<p>The first sub-field, <nettype>, MUST equal the value "IN". The
second sub-field, <addrtype>, MUST equal either "IP4" or "IP6".
The third sub-field for Connection Data is <connection-address>. This supplies
a representation of the SDP originators address, for example dns/IP representation.
The address will be the network address used for connections in this specification.
</p>
<p>Example:
</p>
<p>c=IN IP4 controller.example.com
</p>
<p>The SDP MUST contain a corresponding Media Description entry for compliance to
this specification:
</p>
<p>m=<media> <port> <proto>
</p>
<p>The first "sub-field" <media> MUST equal the value "application".
The second sub-field, <port>, MUST represent a port on which the constructing client
can receive an incoming connection if required. The port is used in combination with the
address specified in the 'Connection Data line defined previously to supply connection
details. If the constructing client can't receive incoming connections it MUST still
enter a valid port range entry. The use of the port value '0' has the same meaning as
defined in the SDP specification<a class='info' href='#I-D.ietf-mmusic-sdp-new'>[9]<span> (</span><span class='info'>Handley, M., “SDP: Session Description Protocol,” January 2006.</span><span>)</span></a>. The third
sub-field, <proto>, MUST equal the value "TCP/ESCS" as defined in
<a class='info' href='#sec:tcp_tag'>Section 14.3.2<span> (</span><span class='info'>TCP/TLS/ESCS</span><span>)</span></a> of this document.
</p>
<p>[Editors note: Need to cover other protocols so not TCP specific]
</p>
<p>The SDP MUST also contain a number of SDP media attributes(a=) that are specifically
defined in the COMEDIA specification. The attributes provide connection negotiation
and maintenance parameters. A client conforming to this specification SHOULD support
all the possible values defined for media attributes from the
<a class='info' href='#RFC4145'>COMEDIA<span> (</span><span class='info'>Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.</span><span>)</span></a> [6] specification but MAY choose not to support values
if it can definitely determine they will never be used (for example will only ever
initiate outgoing connections). It is RECOMMENDED that a Controlling UAC initiate
a connection to an external Server but that an external Server MAY negotiate and
initiate a connection using COMEDIA, if network topology prohibits initiating
connections in a certain direction. An example of the attributes is:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
a=setup:active
a=connection:new
</pre></div>
<p>This example demonstrates a new connection that will be initiated from the
owner of the SDP payload. The connection details are contained in the SDP
answer received from the UAS. A full example of an SDP payload compliant to this
specification can be viewed in <a class='info' href='#sec:overview'>Section 3<span> (</span><span class='info'>Overview</span><span>)</span></a>. Once the SDP has been
constructed along with the remainder of the SIP INVITE request (as defined in
<a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2]), it can be sent to the appropriate location.
The SIP dialog and appropriate control connection is then established.
</p>
<a name="sec:UAC_media_dialog"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Control Client SIP UAC Behavior - Media Dialogs</h3>
<p>It is intended that the Control framework will be used within a variety of
architectures for a wide range of functions. One of the primary functions will
be the use of the control channel to apply specific Control package commands
to co-existing SIP dialogs that have been established with the same remote
server, for example the manipulation of audio dialogs connected to a media
server.
</p>
<p>Such co-existing dialogs will pass through the Control Client (see
<a class='info' href='#fig:call_arch'>Figure 4<span> (</span><span class='info'>Participant Architecture</span><span>)</span></a>) entity and may contain more than one Media
Description (as defined by "m=" in the SDP). The Control Client
SHOULD include a media label attribute (B2BUA functionality), as defined in
<a class='info' href='#I-D.ietf-mmusic-sdp-media-label'>[10]<span> (</span><span class='info'>Levin, O. and G. Camarillo, “The SDP (Session Description Protocol) Label Attribute,” January 2005.</span><span>)</span></a>, for each "m="
definition. A Control Client constructing the SDP MAY choose not to include
the media label SDP attribute if it does not require direct control on a per
media stream basis.
</p>
<p>This framework identifies the common re-use of referencing media dialogs
and has specified a connection reference attribute that can optionally be
imported into any Control Package. It is intended that this will reduce
repetitive specifying of dialog reference language. The schema can be found
in <a class='info' href='#sec:dialog_xml'>Section 16.1<span> (</span><span class='info'>Common Dialog/Multiparty Reference Schema</span><span>)</span></a> in Appendix A.
</p>
<p>Similarly, the ability to identify and apply commands to a group of
media dialogs is also identified as a common structure that could be defined
and re-used (for example playing a prompt to all participants in a Conference).
The schema for such operations can also be found in
<a class='info' href='#sec:dialog_xml'>Section 16.1<span> (</span><span class='info'>Common Dialog/Multiparty Reference Schema</span><span>)</span></a> in Appendix A.
</p>
<p>Support for both the common attributes described here is specified as part
of each Control Package definition, as detailed in
<a class='info' href='#sec:Control_Packages'>Section 9<span> (</span><span class='info'>Control Packages</span><span>)</span></a>.
</p>
<a name="sec:UAS"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
Control Server SIP UAS Behavior - Control Channel Setup</h3>
<p>On receiving a SIP INVITE request, an external Server(UAS) inspects the message
for indications of support for the mechanisms defined in this specification.
This is achieved through the presence of the SIP Supported and Require headers
containing the option tag 'escs'. If the external Server wishes to construct a
reliable response that conveys support for the extension, it should follow the
mechanisms defined in <a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2] for responding to
SIP supported and Require headers. If support is conveyed in a reliable SIP
provisional response, the mechanisms in <a class='info' href='#RFC3262'>RFC 3262<span> (</span><span class='info'>Rosenberg, J. and H. Schulzrinne, “Reliability of Provisional Responses in Session Initiation Protocol (SIP),” June 2002.</span><span>)</span></a> [3]
MUST also be used.
</p>
<p>When constructing a SIP success response, the SDP payload MUST be constructed
using the semantics(Connection, Media and attribute) defined in
<a class='info' href='#sec:UAC'>Section 5<span> (</span><span class='info'>Control Client SIP UAC Behavior - Control Channel Setup</span><span>)</span></a> using valid local settings and also with full compliance
to the COMEDIA<a class='info' href='#RFC4145'>[6]<span> (</span><span class='info'>Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.</span><span>)</span></a> specification. For example, the SDP
attributes included in the answer constructed for the example offer provided
in <a class='info' href='#sec:UAC'>Section 5<span> (</span><span class='info'>Control Client SIP UAC Behavior - Control Channel Setup</span><span>)</span></a> would look as illustrated below:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
a=setup:passive
a=connection:new
</pre></div>
<p>Once the SIP success response has been constructed, it is sent using standard
SIP mechanisms. Depending on the contents of the SDP payloads that were negotiated
using the Offer/Answer exchange, a reliable connection will be established between
the Controlling UAC and external Server UAS entities. The connection is now
available to exchange commands, as defined in "Control Packages" and
described in <a class='info' href='#sec:Control_Packages'>Section 9<span> (</span><span class='info'>Control Packages</span><span>)</span></a>. The state of the SIP Dialog
and the associated Control channel are now explicitly linked. If either party
wishes to terminate a Control channel is simply issues a SIP termination request
(SIP BYE request). The Control Channel therefore lives for the duration of the SIP
dialog.
</p>
<p>If the UAS does not support the extension contained in a SIP Supported or
Require header it MUST respond as detailed in
<a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2]. If the UAS does support the SIP extension
contained in a SIP Require or Supported header but does not support one or more of
the Control packages, as represented in the "Control-Packages" SIP
header, it MUST respond with a SIP "496 Unknown Control Package"
response code. The error response MUST conform to
<a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2] and MUST also include a
"Control-Packages" SIP header which lists the control packages from the
request that the UAS does not support. This provides the Controlling UAC with an
explicit reason for failure and allows for re-submission of the request without the
un-supported control package.
</p>
<p>A SIP entity receiving a SIP OPTIONS request MUST respond appropriately as
defined in <a class='info' href='#RFC3261'>RFC 3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2]. This involves providing
information relating to supported SIP extensions in the 'Supported' message header.
For this extension a value of 'escs' MUST be included. Additionally, a SIP entity
MUST include all the additional control packages that are associated with the
Control channel. This is achieved by including a 'Control-Packages' SIP message
header listing all relevant supported Control package tokens.
</p>
<a name="sec:CommandCon"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Control Framework Interactions</h3>
<p>The use of the COMEDIA specification in this document allows for a Control
Channel to be set up in either direction as a result of the SIP INVITE transaction.
While providing a flexible negotiation mechanism, it does provide certain
correlation problems between the channel and the overlying SIP dialog. Remember
that the two are implicitly linked and so need a robust correlation mechanism. A
Control Client receiving an incoming connection (whether it be acting in the role
of UAC or UAS) has no way of identifying the associated SIP dialog as it could be
simply listening for all incoming connections on a specific port. As a
consequence, some rules are applied to allow a connecting (defined as 'active'
role in COMEDIA) client to identify the associated SIP dialog that triggered the
connection. The following steps provide an identification mechanism that MUST
be carried out before any other signaling is carried out on the newly created
Control channel.
</p>
<ul class="text">
<li>Once connected, the client initiating the connection (as determined
by COMEDIA) MUST immediately send a Control Framework SYNCH request.
The SYNCH request will be constructed as defined in
<a class='info' href='#sec:control_formal_syntax'>Section 11.2<span> (</span><span class='info'>Control Framework Formal Syntax</span><span>)</span></a> and MUST only contain one
message header, 'dialog-id', which contains the SIP dialog
information.
</li>
<li>The 'dialog-id' message header is constructed by concatenating the
Local-tag, Call-ID and Remote-tag (as defined in
<a class='info' href='#sec:control_formal_syntax'>Section 11.2<span> (</span><span class='info'>Control Framework Formal Syntax</span><span>)</span></a>) from the SIP dialog and
separating with a '~'. See syntax defined in
<a class='info' href='#sec:dialog_xml'>Section 16.1<span> (</span><span class='info'>Common Dialog/Multiparty Reference Schema</span><span>)</span></a> in Appendix A and examples in
<a class='info' href='#sec:Examples'>Section 9.6<span> (</span><span class='info'>Examples</span><span>)</span></a>. For example, if the SIP dialog had values
of 'Local-tag=HKJDH', 'Remote-tag=JJSUSHJ' and
'Call-ID=8shKUHSUKHW@example.com' - the 'dialog-id' header would look
like this: 'dialog-id=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'.
</li>
<li>The client who initiated the connection MUST then send the SYNCH
request. It should then wait for a period of 5 seconds to receive a
response. It MAY choose a longer time to wait but it should not be shorter
than 5 seconds.
</li>
<li>If no response is received for the SYNCH control message, a timeout
occurs and the control channel is terminated along with the associated SIP
dialog (issue a BYE request).
</li>
<li>If the client who initiated a connection receives a 481 response, this
implies that the SYNCH request was received but no associated SIP dialog
exists. This also results in the control channel being terminated along
with the associated SIP dialog (issue a BYE request).
</li>
<li>All other error responses received for the SYNCH request are treated as
detailed in this specification and also result in the termination of the
control channel and the associated SIP dialog (issue a BYE request).
</li>
<li>The receipt of a 200 response to a SYNCH message implies that the SIP
dialog and control connection have been successfully correlated. The
control channel can now be used for further interactions.
</li>
</ul>
<p>Once a successful control channel has been established, as defined in
<a class='info' href='#sec:UAC'>Section 5<span> (</span><span class='info'>Control Client SIP UAC Behavior - Control Channel Setup</span><span>)</span></a> and <a class='info' href='#sec:UAS'>Section 6<span> (</span><span class='info'>Control Server SIP UAS Behavior - Control Channel Setup</span><span>)</span></a> (and the connection has been
correlated, as described in previous paragraph), the two entities are now in a position
to exchange relevant control framework messages. The remainder of this section
provides details of the core set of methods and responses that MUST be supported for
the core control framework. Future extensions to this document MAY define new
methods and responses.
</p>
<a name="sec:constructing_requests"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.
Constructing Requests</h3>
<p>An entity acting as a Control Client is now able to construct and send new
requests on a control channel and MUST adhere to the syntax defined in
<a class='info' href='#sec:formal_syntax'>Section 11<span> (</span><span class='info'>Formal Syntax</span><span>)</span></a>. Control Commands MUST also adhere to the syntax
defined by the Control Packages negotiated in <a class='info' href='#sec:UAC'>Section 5<span> (</span><span class='info'>Control Client SIP UAC Behavior - Control Channel Setup</span><span>)</span></a> and
<a class='info' href='#sec:UAS'>Section 6<span> (</span><span class='info'>Control Server SIP UAS Behavior - Control Channel Setup</span><span>)</span></a> of this document. A Control Client MUST create a
unique transaction and associated identifier per request transaction. The
transaction identifier is then included in the first line of a control
framework message along with the method type (as defined in the ABNF in
<a class='info' href='#sec:formal_syntax'>Section 11<span> (</span><span class='info'>Formal Syntax</span><span>)</span></a>). The first line starts with the SCFW token
for the purpose of easily extracting the transaction identifier. The
transaction identifier MUST be globally unique over space and time. All
required mandatory and optional control framework headers are then inserted
into the control message with appropriate values (see relevant individual
header information for explicit detail). A "Control-Package" header MUST also
be inserted with the value indicating the Control Package to which this specific
request applies (Multiple packages can be negotiated per control channel).
</p>
<p>Any framework message that contains an associated
payload MUST also include a 'Content-Length' message header which represents
the size of the message body in decimal number of octets. If no associated
payload is to be added to the message, a 'Content-Length' header with
a value of '0' MUST be included.
</p>
<p>When all of the headers have been included in the framework
message, it is sent down the control channel established in
<a class='info' href='#sec:UAC'>Section 5<span> (</span><span class='info'>Control Client SIP UAC Behavior - Control Channel Setup</span><span>)</span></a>.
</p>
<p>It is a requirement that a Server receiving such a request
respond quickkly with an appropriate response (as defined in
<a class='info' href='#sec:constructing_responses'>Section 7.2<span> (</span><span class='info'>Constructing Responses</span><span>)</span></a>). A Control Client entity needs
to wait for Transaction-Time time for a response before considering the
transaction a failure.
</p>
<a name="sec:sending_control"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1.1"></a><h3>7.1.1.
Sending CONTROL</h3>
<p>A 'CONTROL' message is used by Control Client to
invoke control commands on a Control Server. The
message is constructed in the same way as any standard Control Framework
message, as discussed previously in <a class='info' href='#sec:constructing_requests'>Section 7.1<span> (</span><span class='info'>Constructing Requests</span><span>)</span></a>
and
defined in <a class='info' href='#sec:formal_syntax'>Section 11<span> (</span><span class='info'>Formal Syntax</span><span>)</span></a>. A CONTROL message MAY
contain a message body. The explicit control command(s) of the message
payload contained in a CONTROL message are specified in separate
Control Package specifications. These specifications MUST conform
to the format defined in <a class='info' href='#sec:Control_Bodies'>Section 9.4<span> (</span><span class='info'>CONTROL Message Bodies</span><span>)</span></a>.
</p>
<a name="sec:sending_report"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1.2"></a><h3>7.1.2.
Sending REPORT</h3>
<p>A 'REPORT' message is used by a Control Server in two situations.
The first situation occurs when processing of a Control Command extends
beyond a Command-Timeout. In this case a 202 response is returned.
Status updates and the final results of the command are then returned
in subsequent REPORT messages.
The second situation allows REPORT to be used as an event notification
mechanism where events are correlated with the original CONTROL message.
In this case, REPORT messages may be sent after the original transaction
or extended transaction has completed.
</p>
<p>All REPORT messages MUST contain the same transaction ID in the request
start line that was present in the original CONTROL transaction. This
allows both extended transactions and event notifications to be
correlated with the original CONTROL transaction.
</p>
<a name="sec:reporting_status"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1.2.1"></a><h3>7.1.2.1.
Reporting the Status of Extended Transactions</h3>
<p>On receiving a CONTROL message, a Control Server
MUST respond within Command-Timeout with a status code for the request,
as specified in <a class='info' href='#sec:constructing_responses'>Section 7.2<span> (</span><span class='info'>Constructing Responses</span><span>)</span></a>.
If the command completed within that time, a 200 response code
would have been sent. If the command did not complete within that
time, the response code 202 would have been sent
indicating that the requested command is still being
processed and the CONTROL transaction is being extended.
The REPORT method is used to update the status of the
extended transaction.
</p>
<p>A Control Server issuing a 202 response MUST
immediately issue a REPORT message. The initial REPORT message MUST
contain a 'Seq' (Sequence) message header with a value equal to '1'
(It should be noted that the 'Seq' numbers at both Control Client
Control Server for framework messages are independent). The initial
REPORT message MUST also contain a 'Status' message header with a value
of 'pending'. This initial REPORT message MUST NOT contain a message
body and is primarily used to establish a subsequent message
transaction based on the initial CONTROL message.
</p>
<p>All REPORT messages for an extended CONTROL transaction MUST contain a
'Timeout' message header. This header will contain a value in delta
seconds that represents the amount of time the recipient of the
REPORT message must wait before assuming that there has been a
problem and terminating the extended transaction and associated
state. On receiving a REPORT message with a 'Status' header of
'pending' or 'update', the Control Client MUST
reset the counter for the associated extended
CONTROL transaction to the indicated timeout period. If the
timeout period approaches with no intended REPORT messages being
generated, the entity acting as a Control Framework UAS for the
interaction MUST generate a REPORT message containing, as defined in
this paragraph, a 'Status' header of 'pending'. Such a message acts
as a timeout refresh and in no way impacts the extended transaction,
because no message body or semantics are permitted. It is
RECOMMENDED that a minimum value of 10 and a maximum of ?? is used
for the value of the 'Timeout' message header. It is also
RECOMMENDED that a Control Server refresh the timeout period
of the CONTROL transaction at an interval that is not too close to
the expiry time. A value of 80% of the timeout period could be used,
for example a timeout period of 10 seconds would be refreshed after 8
seconds.
</p>
<p>Subsequent REPORT messages that provide additional information
relating to the extended CONTROL transaction MUST also include and
increment by 1 the 'Seq' header value. They MUST also include a
'Status' header with a value of 'update'. These REPORT messages
sent to update the extended CONTROL transaction status MAY contain
a message body, as defined by individual Control Packages and specified in
Section 9.5. A REPORT message sent updating the extended transaction also
acts as a timeout refresh, as described earlier in this section.
This will result in a transaction timeout period at the initiator of
the request being reset to the interval contained in the 'Timeout'
message header.
</p>
<p>When all processing for an extended CONTROL transaction has taken place,
the entity acting as a Control Server MUST send a terminating REPORT
message. The terminating REPORT message MUST increment the value in
the 'Seq' message header by the value of '1' from the previous REPORT
message. It MUST also include a 'Status' header with a value of
'terminate' and MAY contain a message body. A Control Framework UAC
can then clean up any pending state associated with the original
control transaction.
</p>
<a name="sec:reporting_events"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1.2.2"></a><h3>7.1.2.2.
Reporting Asynchronous Events</h3>
<p>Commands that are carried in CONTROL messages can request that the Server
notify the Client about events that occur sometime in the future.
It is not desirable to use extended Control transactions for these
types of commands for two reasons. First, an event never occurring is
often correct behavior. Second, events may occur long after the original
request for their notification.
</p>
<p>REPORT messages can be used to notify events. REPORT messages that
notify events MUST contain a 'Status' header of 'Notify'. They MUST NOT
contain either a 'Timeout' or 'Seq' header and any such headers MUST be
ignored when the REPORT message has a 'Status' of 'notify'.
The REPORT message MAY contain a message body.
</p>
<a name="sec:constructing_responses"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.
Constructing Responses</h3>
<p>A Control Client or Server, on receiving a request, MUST generate a response
within Command-Time time. The response MUST conform to the ABNF
defined in <a class='info' href='#sec:formal_syntax'>Section 11<span> (</span><span class='info'>Formal Syntax</span><span>)</span></a>. The first line of the response
MUST contain the transaction identifier used in first line of the request,
as defined in <a class='info' href='#sec:constructing_requests'>Section 7.1<span> (</span><span class='info'>Constructing Requests</span><span>)</span></a>. Responses MUST NOT
include the 'Status' or 'Timeout' message headers - if they are included they have
no meaning or semantics.
</p>
<p>A Control Client or Server MUST then include a status code in the first line
of the constructed response. A CONTROL request that has been understood, and
either the relevant actions for the control command have completed or
a control command error is detected, uses the 200 status code
as defined in <a class='info' href='#sec:200'>Section 8.1<span> (</span><span class='info'>200 Response Code</span><span>)</span></a>. A 200 response MAY include message bodies.
If a 200 response does contain a payload it
MUST include a Content-Length header. A 200 is the only response defined in this
specification that allows a message body to be included.
A client receiving a 200 class response
then considers the control command completed. A CONTROL request that is received
and understood but requires processing that extends beyond Command-Time time
will return a 202 status code in
the response. This will be followed immediately by an initial REPORT message as
defined in <a class='info' href='#sec:sending_report'>Section 7.1.2<span> (</span><span class='info'>Sending REPORT</span><span>)</span></a>. A Control Package
SHOULD explicitly define the circumstances under which either 200 or 202 with
subsequent processing takes place.
</p>
<p>If a Control Client or Server encounters problems with either a
REPORT or CONTROL request, an appropriate error code should be used in the
response, as listed in <a class='info' href='#sec:response_code_descriptions'>Section 8<span> (</span><span class='info'>Response Code Descriptions</span><span>)</span></a>. The
generation of a non 2xx class response code to either a CONTROL or REPORT
message will result in failure of the transaction, and all associated state and
resources should be terminated. The response code may provide an explicit
indication of why the transaction failed, which might result in a re-submission
of the request.
</p>
<p>[timm]: how can an error response provide an explicit indication of
the reason for the transaction failure when only a 200 response allows
message bodies?
</p>
<a name="sec:response_code_descriptions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Response Code Descriptions</h3>
<p>The following response codes are defined for transaction responses to methods
defined in <a class='info' href='#sec:constructing_requests'>Section 7.1<span> (</span><span class='info'>Constructing Requests</span><span>)</span></a>. All response codes in this
section MUST be supported and can be used in response to both CONTROL and REPORT
messages except that a 202 MUST NOT be generated in response to a
REPORT message.
</p>
<p>Note that these response codes apply to framework transactions only.
Success or error indications for control commands MUST be treated as the
result of a control command and returned in either a 200 response or
REPORT message.
</p>
<a name="sec:200"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.1"></a><h3>8.1.
200 Response Code</h3>
<p>The 200 code indicates the completion of a successful transaction.
</p>
<a name="sec:202"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.2"></a><h3>8.2.
202 Response Code</h3>
<p>The 202 response code indicates the completion of a successful transaction with
additional information to be provided at a later time through the REPORT mechanism
defined in <a class='info' href='#sec:sending_report'>Section 7.1.2<span> (</span><span class='info'>Sending REPORT</span><span>)</span></a>.
</p>
<a name="sec:400"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.3"></a><h3>8.3.
400 Response Code</h3>
<p>The 400 response indicates that the request was syntactically incorrect.
</p>
<a name="sec:403"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.4"></a><h3>8.4.
403 Response Code</h3>
<p>The 400 response indicates that the requested operation is illegal.
</p>
<a name="sec:481"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.5"></a><h3>8.5.
481 Response Code</h3>
<p>The 481 response indicates that the intended target of the request
does not exist.
</p>
<a name="sec:500"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.6"></a><h3>8.6.
500 Response Code</h3>
<p>The 500 response indicates that the recipient does not understand
the request
</p>
<a name="sec:Control_Packages"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
Control Packages</h3>
<p>"Control Packages" are intended to specify behavior that extends the
the capability defined in this document. "Control Packages" are not
allowed to weaken "MUST" and "SHOULD" strength statements
that are detailed in this document. A "Control Package" may
strengthen "SHOULD" to "MUST" if justified by the specific
usage of the framework.
</p>
<p>In addition to normal sections expected in a standards-track RFC and SIP
extension documents, authors of "Control Packages" need to address
each of the issues detailed in the following subsections. The following sections
MUST be used as a template and included appropriately in all Control-Packages.
</p>
<a name="sec:Control_Package_Name"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.1"></a><h3>9.1.
Control Package Name</h3>
<p>This section MUST be present in all extensions to this document and
provides a token name for the Control Package. The section MUST
include information that appears in the IANA registration of the token.
Information on registering control package event tokens is contained in
<a class='info' href='#sec:IANA_Considerations'>Section 14<span> (</span><span class='info'>IANA Considerations</span><span>)</span></a>. The package name MUST also
register a version number for the package. This enables updates to the
package to be registered where appropriate. An initial version of a package
MUST start with the value '1.0'. Subsequent versions MUST increment this
number if the same package name is to be used. The exact increment is left
to the discretion of the package author.
</p>
<a name="sec:Message_Usage"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.2"></a><h3>9.2.
Framework Message Usage</h3>
<p>The Control Framework defines a number of message primitives that can
be used to exchange commands and information. There are no limitations
restricting the directionality of messages passed down a control channel.
This section of a Control package document should explicitly detail the
control messages that can be used as well as provide an indication of
directionality between entities. This will include which role type is
allowed to initiate a request type.
</p>
<p>[Editors Note: Need to examine text.]
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.3"></a><h3>9.3.
Common XML Support</h3>
<p>This optional section is only included in a Control Package if the attributes
for media dialog or Conference reference are required. The
Control Package will make strong statements (MUST strength) if the XML schema
defined in <a class='info' href='#sec:dialog_xml'>Section 16.1<span> (</span><span class='info'>Common Dialog/Multiparty Reference Schema</span><span>)</span></a> in Appendix A is to be supported. If
only part of the schema is required (for example just 'connection-id' or
just conf-id), the Control Package will make equally strong (MUST strength)
statements.
</p>
<a name="sec:Control_Bodies"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.4"></a><h3>9.4.
CONTROL Message Bodies</h3>
<p>This mandatory section of a Control Package defines the control body
that can be contained within a CONTROL command request, as defined in
<a class='info' href='#sec:CommandCon'>Section 7<span> (</span><span class='info'>Control Framework Interactions</span><span>)</span></a> (or that no control package body is required).
This section should indicate the location of detailed syntax definitions
and semantics for the appropriate body types.
</p>
<a name="sec:REPORT_Bodies"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.5"></a><h3>9.5.
REPORT Message Bodies</h3>
<p>This mandatory section of a Control Package defines the REPORT body
that can be contained within a REPORT command request, as defined in
<a class='info' href='#sec:CommandCon'>Section 7<span> (</span><span class='info'>Control Framework Interactions</span><span>)</span></a> (or that no report package body is required).
This section should indicate the location of detailed syntax definitions
and semantics for the appropriate body types. It should be noted that the
Control Framework specification does allow for payloads to exist in
200 responses to CONTROL messages (as defined in this document). An entity
that is prepared to receive a payload type in a REPORT message MUST
also be prepared to receive the same payload in a 200 response to a
CONTROL message.
</p>
<a name="sec:Event"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.5.1"></a><h3>9.5.1.
Events</h3>
<p>A Control Package can optionally include one or more subscriptions that
allow a controlling client to receive specific event updates in REPORT
message bodies. The mechanisms that installs/un-installs subscriptions
is not specified in document and is considered out of scope.
Event notifications are always carried in REPORT messages MUST conform
to the rules detailed in <a class='info' href='#sec:reporting_events'>Section 7.1.2.2<span> (</span><span class='info'>Reporting Asynchronous Events</span><span>)</span></a>. This
section of a Control Package definition MUST specify details of the
payload expected to be received from subscriptions that have been
installed.
</p>
<p>[Editors Note: Ongoing discussions relating to a generic
subscription/event mechanism across all packages.]
</p>
<a name="sec:Examples"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.6"></a><h3>9.6.
Examples</h3>
<p>It is strongly RECOMMENDED that Control Packages provide a range of
message flows that represent common flows using the package and this
framework document.
</p>
<a name="sec:NAT"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.
Network Address Translation (NAT)</h3>
<p>[Editors Note: This section will look at geographically distributed systems where NAT
traversal might be an issue. It will look at both the SIP media dialog
traversal and the control channel traversal.]
</p>
<a name="sec:formal_syntax"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.
Formal Syntax</h3>
<a name="sec:sip_formal_syntax"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.1"></a><h3>11.1.
SIP Formal Syntax</h3>
<p>The ABNF for the "Control-Packages" SIP header is as follows:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
Control-Packages = "Control-Packages" HCOLON control-package-value
*(COMMA control-package-value)
control-package-value = control-package-name "/" control-package-version
control-package-name = token
control-package-version = 1*DIGIT "." 1*DIGIT
</pre></div>
<a name="sec:control_formal_syntax"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.2"></a><h3>11.2.
Control Framework Formal Syntax</h3>
<p>The Control Framework interactions use the UTF-8 transformation format as defined
in <a class='info' href='#RFC3629'>RFC3629<span> (</span><span class='info'>Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.</span><span>)</span></a> [15]. The syntax in this section uses the Augmented
Backus-Naur Form (ABNF) as defined in <a class='info' href='#RFC2234'>RFC2234<span> (</span><span class='info'>Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [16].
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
control-req-or-resp = control-request / control-response
control-request = control-req-start headers [control-content]
control-response = control-resp-start headers
control-req-start = pSCFW SP transact-id SP method CRLF
control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF
comment = utf8text
pSCFW = %x53.43.46.57; SCFW in caps
transact-id = alpha-num-token
method = mCONTROL / mREPORT / mSYNCH / other-method
mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps
mREPORT = %x52.45.50.4F.52.54; REPORT in caps
mSYNCH = %x53.59.4E.43.48; SYNCH in caps
other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this and other documents
headers = Content-Length
/Control-Package
/Status
/Seq
/Timeout
/Dialog-id
/ext-header
Content-Length = "Content-Length:" SP 1*DIGIT
Control-Package = "Control-Package:" SP 1*alpha-num-token
Status = "Status:" SP ("pending" / "update" / "terminate" )
Timeout = "Timeout:" SP 1*DIGIT
Seq = "Seq:" SP 1*DIGIT
Dialog-id = "Dialog-id:" SP dialog-id-string
dialog-id-string = alpha-num-token "~" alpha-num-token ["~" alpha-num-token]
alpha-num-token = alphanum 3*31alpha-num-tokent-char
alpha-num-tokent-char = alphanum / "." / "-" / "+" / "%" / "="
control-content = Content-Type 2CRLF data CRLF
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param )
type = token
subtype = token
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
data = *OCTET
ext-header = hname ":" SP hval CRLF
hname = ALPHA *token
hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
</pre></div>
<p>
The following table details a summary of the headers that can be contained in Control Framework
interactions. The "where" columns details where headers can be used:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
R: header field may only appear in requests;
r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used;
An empty entry in the "where" column indicates that the header
field may be present in all requests and responses.
</pre></div>
<p>
The remaining columns list the specified methods and the presence of a specific header:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
m: The header field is mandatory.
o: The header field is optional.
</pre></div><br /><hr class="insert" />
<a name="fig:table1"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
Header field Where CONTROL REPORT SYNCH
___________________________________________________
Content-Length o o -
Control-Package R m - -
Seq - m -
Status R - m -
Timeout R - m -
Dialog-id R - - m
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 11: Table 1 </b></font><br /></td></tr></table><hr class="insert" />
<a name="Examples"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.
Examples</h3>
<p>The following examples provide an abstracted flow of Control Channel establishment and Control
Framework message exchange. The SIP signaling is prefixed with the token 'SIP'. All other
messages are Control Framework interactions defined in this document.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
Control Client Control Server
| |
| (1) SIP INVITE |
| ----------------------------------------> |
| |
| (2) SIP 200 |
| <--------------------------------------- |
| |
| (3) SIP ACK |
| ----------------------------------------> |
| |
|==>=======================================>==|
| Control Channel Established |
|==>=======================================>==|
| |
| (4) SYNCH |
| ----------------------------------------> |
| |
| (5) 200 |
| <--------------------------------------- |
| |
| (6) CONTROL |
| ----------------------------------------> |
| |
| (7) 202 |
| <--------------------------------------- |
| |
| (8) REPORT (pending) |
| <---------------------------------------- |
| |
| (9) 200 |
| ----------------------------------------> |
| |
| (10) REPORT (update) |
| <---------------------------------------- |
| |
| (11) 200 |
| ----------------------------------------> |
| |
| (12) REPORT (terminate) |
| <---------------------------------------- |
| |
| (13) 200 |
| ----------------------------------------> |
| |
| (14) SIP BYE |
| ----------------------------------------> |
| |
| (15) SIP 200 |
| <--------------------------------------- |
|=============================================|
| Control Channel Terminated |
|=============================================|
| |
</pre></div>
<ol class="text">
<li>Control Client->Control Server (SIP): INVITE sip:control-server@example.com
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
INVITE sip:control-server@example.com SIP/2.0
To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Require: escs
Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc1.example.com>
Content-Type: application/sdp
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 control-client.example.com
m=application 7575 TCP/ESCS
a=setup:active
a=connection:new
</pre></div>
<li>Control Server->Control Client (SIP): 200 OK
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Require: escs
Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com
Contact: <sip:control-client@pc2.example.com>
Content-Type: application/sdp
v=0
o=originator 2890844526 2890842808 IN IP4 controller.example,com
s=-
c=IN IP4 control-server.example.com
m=application 7575 TCP/ESCS
a=setup:passive
a=connection:new
</pre></div>
<li>Control Client->Control Server (SIP): ACK
</li>
<li>Control Client opens a TCP connection to the Control Server. The connection
can now be used to exchange control framework messages.
Control Client-->Control Server (Control Framework Message): SYNCH.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW 8djae7khauj SYNCH
Dialog-id: 8937498~893jhoeihjr8392@example.com~023983774
</pre></div>
<li>Control Server-->Control Client (Control Framework Message): 200.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW 8djae7khauj 200
</pre></div>
<li>Control Client opens a TCP connection to the Control Server. The connection
can now be used to exchange control framework messages.
Control Client-->Control Server (Control Framework Message): CONTROL.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq CONTROL
Control-Package: <package-name>
Content-Length: 11
<XML BLOB/>
</pre></div>
<li>Control Server-->Control Client (Control Framework Message): 202.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq 202
</pre></div>
<li>Control Server-->Control Client (Control Framework Message): REPORT.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq REPORT
Seq: 1
Status: pending
Timeout: 10
</pre></div>
<li>Control Client-->Control Server (Control Framework Message): 200.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq 200
Seq: 1
</pre></div>
<li>Control Server-->Control Client (Control Framework Message): REPORT.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq REPORT
Seq: 2
Status: update
Timeout: 10
<XML BLOB/>
</pre></div>
<li>Control Client-->Control Server (Control Framework Message): 200.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq 200
Seq: 2
</pre></div>
<li>Control Server-->Control Client (Control Framework Message): REPORT.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq REPORT
Seq: 3
Status: terminate
Timeout: 10
<XML BLOB/>
</pre></div>
<li>Control Client-->Control Server (Control Framework Message): 200.
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SCFW i387yeiqyiq 200
Seq: 3
</pre></div>
<li>Control Client->Control Server (SIP): BYE
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
BYE sip:control-client@pc2.example.com SIP/2.0
To: <sip:control-server@example.com>
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE
Require: escs
Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com
</pre></div>
<li>Control Server->Control Client (SIP): 200 OK
</li><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
SIP/2.0 200 OK
To: <sip:control-server@example.com>;tag=023983774
From: <sip:control-client@example.com>;tag=8937498
Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789
CSeq: 2 BYE
Require: escs
Control-Packages: <example-package>
Call-ID: 893jhoeihjr8392@example.com
</pre></div>
</ol>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.13"></a><h3>13.
Security Considerations</h3>
<p>Security Considerations to be included in later versions of this document.
</p>
<a name="sec:IANA_Considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14"></a><h3>14.
IANA Considerations</h3>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.1"></a><h3>14.1.
IANA Registration of the 'escs' Option Tag</h3>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.2"></a><h3>14.2.
Control Package Registration Information</h3>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.2.1"></a><h3>14.2.1.
Control Package Registration Template</h3>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.3"></a><h3>14.3.
SDP Transport Protocol</h3>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.3.1"></a><h3>14.3.1.
TCP/ESCS</h3>
<a name="sec:tcp_tag"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.3.2"></a><h3>14.3.2.
TCP/TLS/ESCS</h3>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.4"></a><h3>14.4.
SDP Attribute Names</h3>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14.5"></a><h3>14.5.
SIP Response Codes</h3>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.15"></a><h3>15.
Acknowledgments</h3>
<p>The authors would like to thank Ian Evans and Michael Bardzinski of Ubiquity Software,
Adnan Saleem of Convedia, and Dave Morgan for useful review and input to this work. Eric
Burger contributed to the early phases of this work.
</p>
<a name="sec:appendix_a"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.16"></a><h3>16.
Appendix A</h3>
<p>During the creation of the Control Framework it has become clear that there are number
of components that are common across multiple packages. It has become apparent that
it would be useful to collect such re-usable components in a central location. In the short
term this appendix provides the place holder for the utilities and it is the intention that
this section will eventually form the basis of an initial 'Utilities Document' that can be
used by Control Packages.
</p>
<a name="sec:dialog_xml"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.16.1"></a><h3>16.1.
Common Dialog/Multiparty Reference Schema</h3>
<p>The following schema provides some common attributes for allowing Control Packages to apply
specific commands to a particular SIP media dialog (also referred to as Connection) or
conference. If used within a Control Package the Connection and multiparty attributes will be
imported and used appropriately to specifically identify either a SIP dialog or a conference
instance. If used within a package, the value contained in the 'connection-id' attribute
MUST be constructed by concatenating the 'Local' and 'Remote' SIP dialog identifier
tags as defined in <a class='info' href='#RFC3261'>RFC3261<span> (</span><span class='info'>Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> [2]. They MUST then be separated using
the '~' character. So the format would be:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
'Local Dialog tag' + '~' + 'Remote Dialog tag'
</pre></div>
<p>As an example, for an entity that has a SIP Local dialog identifier of '7HDY839' and a
Remote dialog identifier of 'HJKSkyHS', the 'connection-id' attribute for a Control Framework
command would be:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
7HDY839~HJKSkyHS
</pre></div>
<p>If a session description has more than one media description (as identified by 'm=' in
<a class='info' href='#I-D.ietf-mmusic-sdp-new'>[9]<span> (</span><span class='info'>Handley, M., “SDP: Session Description Protocol,” January 2006.</span><span>)</span></a>) it is possible to explicitly reference them
individually. When constructing the 'connection-id' attribute for a command that applies to a
specific media ('m=') in an SDP description, an optional third component can be concatenated
to the Connection reference key. It is again separated using the '~' character and uses the
'label' attribute as specified in <a class='info' href='#I-D.ietf-mmusic-sdp-media-label'>[10]<span> (</span><span class='info'>Levin, O. and G. Camarillo, “The SDP (Session Description Protocol) Label Attribute,” January 2005.</span><span>)</span></a>. So the
format would be:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
'Local Dialog tag' + '~' + 'Remote Dialog tag' + '~' + 'Label Attribute'
</pre></div>
<p>As an example, for an entity that has a SIP Local dialog identifier of '7HDY839', a
Remote dialog identifier of 'HJKSkyHS' and an SDP label attribute of 'HUwkuh7ns', the
'connection-id' attribute for a Control Framework command would be:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
7HDY839~HJKSkyHS~HUwkuh7ns
</pre></div>
<p>It should be noted that Control Framework requests initiated in conjunction with a
SIP dialog will produce a different 'connection-id' value depending on the directionality
of the request, for example Local and Remote tags are locally identifiable.
</p>
<p>As with the Connection attribute previously defined,
it is also useful to have the ability to apply specific control framework
commands to a number of related dialogs, such as a multiparty call. This
typically consists of a number of media dialogs that are logically bound
by a single identifier. The following schema allows for control
framework commands to explicitly reference such a grouping through a 'conf'
XML container. If used by a Control Package, any control XML referenced by the
attribute applies to all related media dialogs. Unlike the dialog attribute,
the 'conf-id' attribute does not need
to be constructed based on the overlying SIP dialog. The 'conf-id' attribute
value is system specific and should be selected with relevant context and
uniqueness.
</p>
<p>The full schema follows:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- xs:include schemaLocation="common-schema.xsd"/ -->
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>SIP Connection and Conf Identifiers</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connection-id" type="xsd:string"/>
<xsd:attribute name="conf-id" type="xsd:string"/>
</xsd:attributeGroup>
</xs:schema>
</pre></div>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.17"></a><h3>17.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>17.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC2119">[1]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>17.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC3261">[2]</a></td>
<td class="author-text">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “<a href="ftp://ftp.isi.edu/in-notes/rfc3261.txt">SIP: Session Initiation Protocol</a>,” RFC 3261, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3262">[3]</a></td>
<td class="author-text">Rosenberg, J. and H. Schulzrinne, “<a href="ftp://ftp.isi.edu/in-notes/rfc3262.txt">Reliability of Provisional Responses in Session Initiation Protocol (SIP)</a>,” RFC 3262, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3263">[4]</a></td>
<td class="author-text">Rosenberg, J. and H. Schulzrinne, “<a href="ftp://ftp.isi.edu/in-notes/rfc3263.txt">Session Initiation Protocol (SIP): Locating SIP Servers</a>,” RFC 3263, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3264">[5]</a></td>
<td class="author-text">Rosenberg, J. and H. Schulzrinne, “<a href="ftp://ftp.isi.edu/in-notes/rfc3264.txt">An Offer/Answer Model with Session Description Protocol (SDP)</a>,” RFC 3264, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4145">[6]</a></td>
<td class="author-text">Yon, D. and G. Camarillo, “<a href="ftp://ftp.isi.edu/in-notes/rfc4145.txt">TCP-Based Media Transport in the Session Description Protocol (SDP)</a>,” RFC 4145, September 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3525">[7]</a></td>
<td class="author-text">Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, “<a href="ftp://ftp.isi.edu/in-notes/rfc3525.txt">Gateway Control Protocol Version 1</a>,” RFC 3525, June 2003.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.dolly-xcon-mediacntrlframe">[8]</a></td>
<td class="author-text">Dolly, M., “<a href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-02.txt">Media Control Protocol Requirements</a>,” draft-dolly-xcon-mediacntrlframe-02 (work in progress), September 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.ietf-mmusic-sdp-new">[9]</a></td>
<td class="author-text">Handley, M., “<a href="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-26.txt">SDP: Session Description Protocol</a>,” draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.ietf-mmusic-sdp-media-label">[10]</a></td>
<td class="author-text">Levin, O. and G. Camarillo, “<a href="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-label-01.txt">The SDP (Session Description Protocol) Label Attribute</a>,” draft-ietf-mmusic-sdp-media-label-01 (work in progress), January 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3725">[11]</a></td>
<td class="author-text">Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “<a href="ftp://ftp.isi.edu/in-notes/rfc3725.txt">Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)</a>,” BCP 85, RFC 3725, April 2004.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3840">[12]</a></td>
<td class="author-text">Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “<a href="ftp://ftp.isi.edu/in-notes/rfc3840.txt">Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)</a>,” RFC 3840, August 2004.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3841">[13]</a></td>
<td class="author-text">Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “<a href="ftp://ftp.isi.edu/in-notes/rfc3841.txt">Caller Preferences for the Session Initiation Protocol (SIP)</a>,” RFC 3841, August 2004.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3550">[14]</a></td>
<td class="author-text">Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “<a href="ftp://ftp.isi.edu/in-notes/rfc3550.txt">RTP: A Transport Protocol for Real-Time Applications</a>,” STD 64, RFC 3550, July 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3550.txt">TXT</a>, <a href="ftp://ftp.isi.edu/in-notes/rfc3550.ps">PS</a>, <a href="ftp://ftp.isi.edu/in-notes/rfc3550.pdf">PDF</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3629">[15]</a></td>
<td class="author-text">Yergeau, F., “<a href="ftp://ftp.isi.edu/in-notes/rfc3629.txt">UTF-8, a transformation format of ISO 10646</a>,” STD 63, RFC 3629, November 2003.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2234">[16]</a></td>
<td class="author-text"><a href="mailto:dcrocker@imc.org">Crocker, D., Ed.</a> and <a href="mailto:paulo@turnpike.com">P. Overell</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2234.txt">Augmented BNF for Syntax Specifications: ABNF</a>,” RFC 2234, November 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2234.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2234.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2234.xml">XML</a>).</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Chris Boulton</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ubiquity Software Corporation</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Building 3</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Wern Fawr Lane</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">St Mellons</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Cardiff, South Wales CF3 5EA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:cboulton@ubiquitysoftware.com">cboulton@ubiquitysoftware.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Tim Melanchuk</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">BlankSpace</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:tim.melanchuk@gmail.com">tim.melanchuk@gmail.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Scott McGlashan</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Hewlett-Packard</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Gustav III:s boulevard 36</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">SE-16985 Stockholm, Sweden</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:scott.mcglashan@hp.com">scott.mcglashan@hp.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Asher Shiratzky</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Radvision</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">24 Raoul Wallenberg st</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Tel-Aviv, Israel</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ashers@radvision.com">ashers@radvision.com</a></td></tr>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright © The Internet Society (2006).</p>
<p class='copyright'>
This document is subject to the rights,
licenses and restrictions contained in BCP 78,
and except as set forth therein,
the authors retain all their rights.</p>
<p class='copyright'>
This document and the information contained herein are provided
on an “AS IS” basis and THE CONTRIBUTOR,
THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES,
EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Intellectual Property</h3>
<p class='copyright'>
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.</p>
<p class='copyright'>
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
The IETF invites any interested party to bring to its attention
any copyrights,
patents or patent applications,
or other
proprietary rights that may cover technology that may be required
to implement this standard.
Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is provided by
the IETF Administrative Support Activity (IASA).</p>
</body></html>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:02 |