Subject: [mediactrl] DRAFT Minutes for Meeting at IETF 66

From: "Burger, Eric" <[email-masked]>
Date: Thu, 20 Jul 2006 20:01:24 +0100

D R A F T    D R A F T    D R A F T    D R A F T

Please reply to this message ONLY with corrections to the minutes /
attendees.  Please create new threads if you want to discuss the
content.

Please send your comments to me / the list by next Friday, 28 July 2006,
so I can submit them for the IETF minutes.

Media Control (mediactrl) Ad Hoc
Tuesday 12 July 2006, 1510 - 1700 ET

Attendees
---------
Tom Taylor
Martin Dolly
Roni Even
Mary Barnes
Chris Boulton
Asher Shiratzky
Tim Melanchuk
Jim McEachern
Peili Xu
Adnan Saleem
Dale R. Worley
Eric Burger

Chair: Eric Burger
Scribe: Eric Burger

SUMMARY
=======
1. Roni to review requirements document.
2. Tim to create architecture document.
3. One and only one IETF Standard protocol and markup (family) comes out
of this work.
4. Security discussion: why (and how) we cannot allow any random AS to
control any random SIP dialog at the MS.
5. Next step: Eric to draft charter.

Agenda
------
Protocol Requirements
<http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01
.txt>

Supplemental reading for requirements
<http://www.ietf.org/internet-drafts/draft-even-media-server-req-01.txt>

Control Framework
<http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework
-03.txt>

Charter Discussion

Next Steps & Work Plan

Discussion
==========

Requirements Document
---------------------
The requirements document needs review by Roni: focus on media mixing
requirements.

Scope discussion: is manageability in the framework?  There are already
two management requirements: the AS can audit the MS, and the MS can
send performance / resource information to the AS.

The consensus is that general management interface capabilities
(visibility into the resources) is not part of the protocol framework.
We will mention the requirements in the requirements document.  However,
what this discussion pointed out is we need an architecture document.
This document will contain what the functional "boxes" are, how they fit
together, and how they operate.  Tim will be the editor of this
document.  Martin and Roni will supply text.

Framework Document
------------------
Consensus that naked SIP does not make sense.  The control channel needs
to be established first.  Since it is the AS that sends INVITEs to the
MS, there are no situations (other than network path congestion) where a
media dialog will hit the MS before the control dialog.  That situation
is a failure case anyway, which the AS can handle.

Consensus that there will be one and only one IETF Standard markup
family and protocol.

Consensus to mention RFC 4240 in framework.

Discussion over whether there can be markup loaded in the initial media
dialog INVITE or not.  One argument is "no": there is already an
established control channel, so markup can go through that channel.  The
other argument is "yes": it is easy for an application to think in terms
of "establish a session and play this prompt" than to think in terms of
"first, establish a session; second, associate a control channel with
that session; third, play a prompt."  Besides the complexity of the
application, this introduces potentially long latencies between the
INVITE and first utterance.  On the other, other hand, this situation
only makes sense for an INVITE with the initial part of an IVR
interaction.

Security Issue discussion:
Although possible to have the control channel come later, it makes it
considerably easier for the MS to establish security associations
between the control dialog and bearer dialogs.  Eric described the
security issue thus: we cannot have a protocol where any random AS can
take control of a bearer dialog.  There has to be some sort of trust
relationship between the bearer dialog and control channel.  Eric went
on to describe two methods of how to establish that trust.  These
methods are not exhaustive; there may be better models.

Method #1
Explicit association between control channel and media dialog

In this method, the MS issues a token (cookie) to the AS over the
control channel.  When the AS directs an endpoint to the MS, the AS
includes the token with the session negotiation (INVITE).  From that
point on, the MS knows the control channel associated with the token is
the owner of the session.

If a first control channel wishes to relinquish control of the media
channel to a second control channel, the first control channel
explicitly tells the media server of the change.

UAC                 AS1                 MS                  AS2
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |Establish Control Channel              |
 |                   |------------------>|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |token1             |                   |
 |                   |<------------------|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |INVITE sip:[email-masked]      |                   |
 |------------------>|                   |                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |INVITE (w/ token1) |                   |
 |                   |------------------>|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |200 OK             |                   |
 |                   |<------------------|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |200 OK             |                   |                   |
 |<------------------|                   |                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |ACK                |                   |                   |
 |------------------>|                   |                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |ACK                |                   |
 |                   |------------------>|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |(application dialog)                   |
 |                   |...................|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |Establish Control Channel
 |                   |                   |<------------------|
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |token2             |
 |                   |                   |------------------>|
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |Magic token exchange                   |
 |                   |.......................................|
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |Handoff dialog to token2 control       |
 |                   |------------------>|                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |You've got dialog  |
 |                   |                   |------------------>|
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |(application dialog)
 |                   |                   |...................|
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |                   |
 |                   |                   |                   |

In this scenario, the MS knows it is OK for a given control channel to
issue commands over a given SIP dialog because the dialog was created
with that control channel's token.  To hand off control, something needs
to tell the MS that a new control channel owns the SIP dialog.

Method #2:
Explicit Token Control

UAC                   AS1                   MS                    AS2
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |Establish Control Channel                  |
 |                     |-------------------->|                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |token1               |                     |
 |                     |<--------------------|                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |INVITE sip:[email-masked]          |                     |
 |-------------------->|                     |                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |INVITE w/ token1     |                     |
 |                     |-------------------->|                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |200 OK (w/ dialog-token)                   |
 |                     |<--------------------|                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |200 OK               |                     |                     |
 |<--------------------|                     |                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |ACK                  |                     |                     |
 |-------------------->|                     |                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |ACK                  |                     |
 |                     |-------------------->|                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |(application dialog, |                     |
 |                     | w/ dialog-token)    |                     |
 |                     |.....................|                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |Magic token exchange |                     |
 |                     |...........................................|
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |                     |(application dialog, |
 |                     |                     | w/ dialog-token)    |
 |                     |                     |.....................|
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |                     |                     |
 |                     |                     |                     |

In this scenario, the MS knows it is OK for a given control channel to
issue commands for a given SIP dialog because the command itself holds
the token.

Next Steps
==========
Eric will propose a charter for Interest Group review.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.