Subject: [MEDIACTRL] My notes on draft-ietf-mediactrl-sip-control-framework-00

From: Spencer Dawkins <[email-masked]>
Date: Tue, 01 Jan 2008 21:30:28 -0600

Comments, as Chris requested. In general this document looks good. Many of 
the comments I included are about 2119 language, and most of the rest are 
areas where you guys probably know what's intended, but I'm suggesting 
clarifications for readers who are less familiar with the document.

I included a small number of Nits, just because I noticed them in reading.

I noticed there are a bunch of places in the document that are asking for 
working group input on timer values - I'd ask the working group to give 
these some thought (soon). If we are using TCP or any TCP-like transport 
protocol, these timer values will need to accommodate TCP retransmission 
behavior (the 120-second values I was seeing in some places could be OK, but 
the 10-second values I was seeing in other places are more problematic).

To be specific - it's really grungy to pull an timed-out application-level 
message out of a TCP packet that hasn't been acknowledged yet, so is queued 
for TCP-level retransmission, and try to adjust sequence numbers, etc...

Thanks, and happy new year to all.

Spencer, as individual

Abstract

   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

Nit - in general, RFCs don't contain references to IETF working groups 
because RFCs are forever and IETF working groups are not. I'd "to meet the 
requirements of a distributed, centralized conferencing system, as defined 
by the IETF".

   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.

1.  Introduction

   Applications are often developed using an architecture where the

Nit - Is "applications" the right word here, with no qualifying adjective? 
Perhaps "real-time media applications"? After this one sentence, no problem 
with dropping the adjectives, but if a reviewer from APPS reads this 
document, we'll just confuse them.

   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 Server Control Protocol
   Requirements' document[8].  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.

   Current IETF transport device control protocols, such as megaco [7],

Nit (and a personal quirk) - yeah, megaco was developed in the IETF's TSV 
area before RAI was established, but it's not a transport protocol, strictly 
speaking - could you drop "transport" from this phrase?

   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.

2.  Conventions and Terminology

   Control Client:  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,

Nit - got an adjective for "processing capabilities" here? "no processing 
capabilities whatsoever" seems to describe entities that may not even be 
computers :-)

      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".
   Control Channel:  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.

Comment - does our dependence on a reliable transport protocol for the 
control channel show up in the control framework at all?

   Method:  A Method is the type of a framework message.  Three Methods

Nit - the sentence lists four Methods...

      are defined in this document: SYNCH, CONTROL, REPORT, and K-ALIVE.

   extended framework transaction:  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 Section 7.1.2.
      Extended framework transactions allow command failures to be
      discovered at the transaction layer.

Nit - I wish this term was something like "extended transaction lifetime" - 
it implies that the FRAMEWORK is being extended, not the transaction 
lifetime.

3.  Overview

   o  Agnostic - Generic protocol allows for easy extension.

Nit - is there an appropriate adjective for "agnostic" - perhaps 
"Application-agnostic"? SIP is agnostic along a bunch of dimensions 
(transport, media types, etc).

          +--------------SIP Traffic--------------+
          |                                       |
          v                                       v
       +-----+                                 +--+--+
       | SIP |                                 | SIP |
       |Stack|                                 |Stack|
   +---+-----+---+                         +---+-----+---+
   |   Control   |                         |   Control   |
   |   Client    |<----Control Channel---->|   Server    |
   +-------------+                         +-------------+

                       Figure 1: Basic Architecture

   The example from Figure 1 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

Comment - what's being described here is still n*(1:1), right? does the 
possibility of 1:n or m:n relationships show up in the control framework?

   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 Section 16.  The ability to have multiple
   control channels allows for stronger redundancy and the ability to
   manage high volumes of traffic in busy systems.

   Figure 4 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.

Nit - if you could use (1) and (2) for the SIP dialog and dedicated control 
channel, and (3) and (4) for the CC-UA and CC-CS dialogs, this diagram would 
be a little bit clearer.

                         +--------Control SIP Dialog(1)---------+
                         |                                      |
                         v                                      v
                      +-----+                                +--+--+
     +------(2)------>| SIP |---------------(2)------------->| SIP |
     |                |Stack|                                |Stack|
     |            +---+-----+---+                        +---+-----+---+
     |            |             |                        |             |
     |            |   Control   |<--Control Channel(1)-->|             |
     |            |   Client    |                        |   Control   |
     |            +-------------+                        |   Server    |
  +--+--+                                                |             |
  |User |                                                |             |
  |Agent|<=====================RTP(2)===================>|             |
  +-----+                                                +-------------+

                    Figure 4: Participant Architecture

4.  Locating External Server Resources

   [Editors Note: Section will describe mechanisms for locating an
   external Server.]

Comment - do you need any help with this section, or is it just part of the 
next revision cycle?

5.  Control Client SIP UAC Behavior - Control Channel Setup

   On creating a new SIP INVITE request for control channel setup, a UAC
   MUST construct the protocol message as defined in RFC 3261 [2].

Comment (probably for Eric) - this is sticky - do we mean 3261, or do we 
mean SIP? Ignore this for now unless there's an obvious answer, of course.

   Before the UAC can send an INVITE request, it MAY include a valid

Nit - is this saying "the UAC MAY include ... in an INVITE request"? This 
might be clearer.

   session description (an 'offer' as defined in RFC 3264 [5]) using the
   Session Description Protocol defined in [9].  The following
   information defines the composition of some specific elements of the
   SDP payload that MUST be adhered to for compliancy to this
   specification when used in an SIP SDP offer.

   The SDP MUST also contain a number of SDP media attributes(a=) that
   are specifically defined in the COMEDIA [6] specification.  The
   attributes provide connection negotiation and maintenance parameters.
   A client conforming to this specification SHOULD support all the

Comment (probably for Eric) - I would prefer "SHOULD support unless" to 
"SHOULD support but MAY choose not to" - do you have an objection? Same 
comment on the next RECOMMENDED/MAY further down the paragraph, and 
elsewhere in the document ...

   possible values defined for media attributes from the COMEDIA [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:

                           a=setup:active
                           a=connection:new

5.1.  Control Client SIP UAC Behavior - Media Dialogs

   Such co-existing dialogs will pass through the Control Client (see
   Figure 4) 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 [10], for
   each "m=" definition.  A Control Client constructing the SDP MAY

Comment - again, I'd prefer "SHOULD include unless"...

   choose not to include the media label SDP attribute if it does not
   require direct control on a per media stream basis.

6.  Control Server SIP UAS Behavior - Control Channel Setup

   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 inspection of the
   Sessions Description of the SIP INVITE message and identifying
   support for the appropriate media type.  If the external Server
   wishes to construct a reliable response that conveys support for the
   extension, it should follow the mechanisms defined in RFC 3261 [2].
   If support is conveyed in a reliable SIP provisional response, the
   mechanisms in RFC 3262 [3] MUST also be used.  It should be noted
   that the SDP offer is not restricted to the initial INVITE request
   and maybe appear in any series of messages that are compliant to RFC

Nit - s/maybe/may/

   3261 [2], RFC 3262 [3], and RFC 3264 [5]

7.  Control Framework Interactions

   o  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.

Comment - why is this not "MUST wait for at least 5 seconds to receive a 
response"?

   It should be noted that SYNCH messages can be sent at any point while
   the Control Channel is open from either side, once the initial
   exchange is complete.  It should also be noted that if present, the

Comment - are subsequent SYNCH messages basically no-ops? keep-alives? any 
semantics?

   contents of the "Keep-Alive" and "Dialog-ID" headers should not
   change and new values have no relevance as they are both negotiated
   for the lifetime of the session.

Comment - so, the rule is that you can drop these headers but you can't 
change the header content, but the receiver should be ignoring the header 
content anyway? Is there a reason why not "sender MUST NOT change"/"receiver 
MUST ignore"? (When we allow changes and then ignore them, this makes 
debugging from network traces more difficult, because you can't know what 
values were in use by looking at the packets)

7.1.  Constructing Requests

   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 Section 11 (Note: either client can act as a control
   client depending on individual package requirements).  Control
   Commands MUST also adhere to the syntax defined by the Control
   Packages negotiated in Section 5 and Section 6 of this document.  A
   Control Client MUST create a unique transaction and associated
   identifier per request transaction.  The transaction identifier is

Comment - I'm sorry, but "MUST create a unique transaction and associated 
identifier" wasn't clear to me. Is this one action or two? Or should this be 
"MUST create a unique associated identifier"?

   then included in the first line of a control framework message along
   with the method type (as defined in the ABNF in Section 11).  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

Comment - the way I'm reading section 7.1.2.2, I'm wondering if a 
transaction identifier can ever be safely reused - is it possible for the 
requestor to know that (1) the transaction has completed and (2) the 
responder will never send an event with that transaction identifier? I think 
these are the two conditions for reusing a transaction identifier, if I'm 
following this text.

   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 using the SYNCH control message that
   is discussed in this section along with the mechanism from
   Section 7.1.4).

7.1.2.1.  Reporting the Status of Extended Transactions

   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

Nit (I think) - is this "at the Control Client and at the Control Server"? 
(missing "and"?)

   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.

   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

Nit - "reset the timer"?

   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 "Upper-
   limit" 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.

7.1.2.2.  Reporting Asynchronous Events

   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.

Comment - it is possible for a requester to know that there will be no more 
events for a specific transaction ID, right? Might be useful to point that 
out here.

Comment - Also, I'm not seeing a description of what transaction ID is used 
for event reporting - is it the transaction ID that included a Status header 
of "Notify"?

7.1.3.  Control Channel Keep-Alive

   It is reasonable to expect this document to be used in various
   network architectures.  This will include a wide range of deployments
   where the clients could be co-located in a secured, private domain or
   spread across disparate domains that require traversal of devices
   such as Network Address Translators (NAT) and Firewalls (which is
   covered in Section 10).  It is important, therefore, that this
   document provides a 'keep-alive' mechanism that enables the control
   channel being created to firstly be kept active during times of
   inactivity (most Firewalls have a timeout period after which
   connections are closed) and also provide the ability for application
   level failure detection.  It should be noted at this point that the
   following procedures apply explicitly to the control channel being
   created and for details relating to a SIP keep-alive mechanism
   implementers should seek guidance from SIP Outbound [11].  The
   following 'keep-alive' procedures SHOULD be implemented by all
   entities but MAY NOT be implemented if it can be guaranteed that

Nit - "MAY NOT" isn't actually in 2119 (amazing but true). But I'd prefer 
"SHOULD be implemented unless"...

   deployments will only occur with entities in a co-located domain.  It
   should be noted that choosing to not implement the 'keep-alive'
   mechanism in this section, even when in a co-located architecture,
   will reduce the ability to detect application level errors -
   especially during long periods of in-activity.

Comment - if it's not too insulting to users of this specification, it might 
be worth pointing out that if you guarantee that everything is co-located 
when you deploy a system and don't implement the keep-alive mechanism, 
network topology changes can cause problems if you suddenly are traversing a 
NAT or firewall...

7.1.3.1.  Timeout Negotiation

   o  Once negotiated, the keep-alive applies for the remainder of the
      Control Framework session.  Any subsequent SYNCH messages
      generated in the control channel do not impact the negotiated
      keep-alive property of the session.  The "Keep-Alive" header MUST
      NOT be included in subsequent SYNCH messages as it has no meaning.
      If it is present it MUST be ignored.

Comment - this is actually the style of send-conservative, accept-liberal I 
was suggesting in previous comments.

7.1.3.2.  Generating Keep-Alive Messages

   When acting as an 'active' client, a 'K-ALIVE' Control Framework
   message MUST be generated before the local 'keep-alive' timer fires.
   An active client is free to send the K-ALIVE Control Framework
   message when ever it chooses.  A guideline of 80% of the local 'keep-
   alive' timer is suggested.  The 'passive' client MUST generate a 200
   OK Control Framework response to the K-ALIVE message and reset the
   local 'keep-alive' timer.  No other Control Framework response is
   valid.  On receiving the 200 OK Control Framework message, the
   'active' client MUST reset the local 'keep-alive' timer.  If no 200
   OK response is received to the K-ALIVE Control Framework message,
   before the local 'keep-alive' timer fires, the 'active' client SHOULD
   tear down the SIP dialog and recover the associated control channel
   resources.  The 'active' client MAY choose to try and recover the
   connection by renegotiation using COMEDIA.  It should be noted that

Comment - am I reading this correctly? the 'active' client SHOULD tear down 
the SIP dialog, but MAY try to recover the connection instead? Is there a 
reason that we wouldn't pick one of the two? Same comment in "passive" 
description immediately following.

   the local 'active' keep-alive timer MUST be reset on receipt of any
   Control Framework message (request or response) from the passive
   client.

   When acting as a 'passive' client, a 'K-ALIVE' Control Framework
   message MUST be received before the local 'keep-alive' timer fires.
   The 'passive' client MUST generate a 200 OK control framework
   response to the K-ALIVE Control Framework message.  On sending the
   200 OK response, the 'passive' client MUST reset the local 'keep-
   alive' timer.  If no K-ALIVE message is received before the local
   'keep-alive' timer fires, the 'passive' client SHOULD tear down the
   SIP dialog and recover the associated control channel resources.  The
   'active' client MAY try to and recover the connection by
   renegotiating using COMEDIA.  It should be noted that the local
   'passive' keep-alive timer MUST be reset on receipt of any Control
   Framework message (request or response) from the active client.

7.1.4.  Package Negotiation

   As part of the SYNCH message exchange a client generating the request
   MUST include a "Packages" header, as defined in Section 11.  The
   "Packages " header will contain a list of all Control Framework
   packages that can be supported within this control session (from the
   perspective of the entity creating the SYNCH message).  All tokens
   MUST be official SIP Control Framework packages that adhere to the

Comment - I'm not sure why "official" is required, especially for 
interoperability (since SYNCH receivers ignore any packages they don't 
recognize anyway)

   rules set out in Section 9.  The initial SYNCH message MUST at least
   contain a single value.

7.2.  Constructing Responses

   If a Control Client or Server encounters problems with either a
   Control Framework request (like REPORT or CONTROL), an appropriate
   error code should be used in the response, as listed in Section 8.
   The generation of a non 2xx class response code to either a Control
   Framework request (like CONTROL or REPORT) will result in failure of

Nit - "will indicate 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.

8.  Response Code Descriptions

9.  Control Packages

   "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

Comment - I agree on not weakening MUSTs and agree on strengthening SHOULD 
to MUST, but I'm not sure how you weaken SHOULDs, and if you don't conform 
to a SHOULD, the other end has to be prepared to accommodate what you did 
instead (rather than simply declaring an error, as would be appropriate when 
a MUST isn't satisfied).

   detailed in this document.  A "Control Package" may strengthen
   "SHOULD" to "MUST" if justified by the specific usage of the
   framework.

   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.

Comment - probably not a 2119 MUST...

9.6.  Examples

   It is strongly RECOMMENDED that Control Packages provide a range of

Nit - this isn't actually a 2119 RECOMMENDED (not required for 
interoperability, right?)

   message flows that represent common flows using the package and this
   framework document.

10.  Network Address Translation (NAT)

   [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.
   Should this be in a separate doc?]

Comment - a separate doc would be OK with me. If we weren't finishing up the 
mediactrl architecture draft, we could have put it there, too, but I don't 
see any reason to hold up the architecture draft for this discussion.

11.  Formal Syntax

11.1.  Control Framework Formal Syntax

 /Keep-alive

Comment - I am okay with "K-ALIVE" because it's referring to a specific type 
of keepalive. Is it possible for us to qualify "Keep-alive" here, so it 
doesn't look so generic?

   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:

          R: header field may only appear in requests;

          r: header field may only appear in responses;

Nit - could you mention here that "blank" means the header field may appear 
in either requests or 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.

   The remaining columns list the specified methods and the presence of
   a specific header:

           m: The header field is mandatory.
           o: The header field is optional.
           -: The header field is not applicable (ignored if present).

         Header field        Where    CONTROL REPORT SYNCH K-ALIVE
         ___________________________________________________________
         Content-Length                  o      o      -      -
         Control-Package       R         m      -      -      -
         Seq                             -      m      -      -
         Status                R         -      m      -      -
         Timeout               R         -      m      -      -
         Dialog-ID             R         -      -      m      -
         Packages                        -      -      m      -
         Supported             r         -      -      o      -
         Keep-Alive            R         -      -      o      -

                            Figure 10: Table 1

12.  Examples

   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.

Nit - could you add a paragraph that describes the abstracted flow at a high 
level? Maybe something like "In this example, the Control Client establishes 
a control channel, SYNCHs with the Control Server, and issues a CONTROL 
request that can't be completed within "transaction-timeout" seconds, so the 
Control Server returns a 202 response code and then follows with REPORTs 
until the requested action has been completed"

13.  Security Considerations

   Security Considerations to be included in later versions of this
   document.

Comment - got a vision for what level of security considerations are 
appropriate in a framework document?

16.  Appendix A

Comment - I've come to expect that appendices aren't normative in most 
RFCs - if this becomes normative for packages that use these common 
facilities, the material should probably be moved into the body of the 
document. 

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl