Subject: MMUSIC minutes

From: Eve Schooler <[email-masked]>
Date: Fri, 24 Apr 1998 12:40:08 -0700 (PDT)

Hi,

Below are the minutes for the MMUSIC meeting at the LA IETF.  
The accompanying slides are:

  //ftp.isi.edu/confctrl/minutes/slides.3.98/sip.{ps,ppt}
  //ftp.isi.edu/confctrl/minutes/slides.3.98/sip-cc.ps

Within the next day or so, these will be located in the places
listed in the minutes themselves. 

Thanks,
E.

              Multiparty Multimedia Session Control (MMUSIC) 
                        Minutes from the 41st IETF
                             Los Angeles, CA
                              March 31, 1997                         

                                Co-Chairs

                     Mark Handley, [email-masked]
                     Ruth Lang, [email-masked]
                     Joerg Ott, [email-masked]
                     Eve Schooler, [email-masked]

The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for one session on March 31st at the 41st IETF.  These notes, prepared 
by Eve Schooler, summarize the presentations given and recount issues 
raised and their resolution, if any, during these presentations.  An 
on-line copy of these minutes and the accompanying slides are available 
from the MMUSIC archive area ftp://ftp.isi.edu/confctrl/minutes in the 
files ietf.3.98 and slides.3.98.{tar, tar.Z}.  Individual slide presentations 
can be obtained from the directory slides.3.98.

SIP
---

Mark Handley of USC/Information Sciences Institute gave a detailed
overview of SIP status. See the accompanying slides sip.{ps,ppt}.
In particular, he focused on an improved SIP security architecture
and presented the outstanding issues that remain before SIP is to
be advanced to Proposed Standard.  As discussed at the DC IETF,
the call-control functionality has been split from the base spec
and was discussed later in the meeting.

Issues raised:

- With end-to-end encryption, if you encrypt you may not get the same 
  routing as when you do not encrypt. In addition, a Response-Key header 
  is needed for bootstrapping.

- We expect the Respone-Key namespace to be an IANA registered space and 
  to extend the HTTP authentication space.

- Note that the fields that may change go above the Authorization header.

- One recommendation was that the PGP encryption scheme should be brought in 
  line with IPSEC, both internally and externally.

- If Hide is used, how can you determine Max-Fanout?  
  Although encrypted after Via, we can still count the number.
  Questions also arose about exact semantics, i.e., could there be 
  breadth and depth aspects to it? Note that this cannot be
  controlled when multicast is used.

- For multicast requests, parameters need to be specified for the SRM-like 
  back-off behavior of respondents.  There was some concern that multicast 
  might be a source of security problems, in that a forged source 
  address might redirect ACK response traffic to another address.  To 
  limit the impact of such a scenario, only consider multicast with local 
  scope for the base specification.

- Several proposals were made regarding how to handle the receipt of
  multiple 2xx responses.  Accept (ACK) the first one that comes back, but 
  any others should lead to responses with more information (e.g.,
  the call was refused someone else picked up at the same time), which 
  can be processed more effectively by a smart user agent.  Does this 
  conflict with the call control proposal for a 3-way merge?  In either 
  case, we need to clarify that these scenarios are different.  Another 
  opinion was that because this is an example of ill-defined temporal 
  behavior, all the SIP spec should say is that at least one callee should 
  get connected.  Yet, another opinion expressed was that SIP should
  forbid that 1 INVITE leads to more than 1 callee. In any event, it was 
  suggested that the default behavior be flexible enough to support more 
  complicated call control should it be necessary later on.

- When asked if we should constrain the time when the inviter begins
  receiving voice, the consensus was that the callee should be allowed
  to start sending either when a Status message is sent by the calle
  or when an ACK is received from the caller.

- Proxies probably should be allowed to encrypt a request, but we
  do not want to encourage or set precedent that proxies mess with 
  random fields.  

- Interface addresses vs FQDNs in Via?
  Recommend FQDNs in Via, but allow interface addresses because there 
  are boxes out there that do not have FQDNs.

Once the SIP I-D freezes, an interoperability testing session is needed 
for SIP implementations.

SIP Call Control
----------------

Jonathan Lennox of Columbia University presented the latest call-control 
I-D on behalf of Henning Schulzrinne and Jonathan Rosenberg.  See the 
accompanying slides sip-cc.ps.  Much heated discussion ensued.  Overall 
it was felt that the I-D introduced complex enough behavior, with 
functionality as yet untried, that (1) considerably more detail was 
needed in the I-D and (2) implementation experience was strongly requested.

The issues raised:

- Extensions to the Location header: 
  Regarding "features=permanent", who decides what's permanent vs temporary?  
  The client doing the registration?  What's the semantic difference and
  impact (e.g., on caching) of the two?  Further details are needed.

- Call-Dispostion:
  Further clarification was requested of how Queued is supposed to 
  cause a client to behave.  One comment was that the do-not-respond option 
  would seem to change the mandatory behavior of SIP. In fact some felt 
  that SIP was not necessarily the right protocol to perform this role (which
  begins to resemble instant messages a la the NOTIFY method discussed
  in the PIPR BOF).  What happens when 2 or more of these features happen 
  at once?

- New headers Also, Replaces and Requested-by:
  How does authentication work with these headers?
  Why not use BYE in a call transfer?
  Table 1 and 2 need to clarify Location usage as R or r or both.
  Precise error messages for each scenario are still a big issue to be
  resolved.

  In terms of feature redundancy, what is the difference between an
  INVITE with an Also and Replaces (to myself), and a BYE with an Also 
  of someone else?  Although the former (INVITE with Replaces of self) 
  is rather awkward, it is legal to do a blind transfer with this mechanism.
  However, we need to be careful (e.g., with PBX's) that there remains a 
  single user in conference (imagine robot-to-robot 3rd party transfers).

- Semantics:
  (To, From, Call-Id) uniquely identifies a transaction and "leg" of a
  call.  But, some felt that this scheme overloaded the endpoint names.

  In addition, there was general discussion about the destinction between
  various identifiers: the user, session, and call ids.  In particular,
  the question was asked, what's the difference between a session and a call?  
  Does a call refer to a single "leg" or INVITE, whereas session is the 
  overall "object" among all users; or alternatively, is the call meant to 
  cover the overall conference?  In any event, clarification is needed.

- Open Issues:
  Asked how a third-party requester should be informed of the progress
  and result of a request, people felt none of the proposed solutions were 
  ideal (STATUS request, application/sip payload, 1xx responses).  It was 
  reiterated that more precise error message handling may help here.

- Examples: 
  A more palatable example other than telemarketing was requested :-) 
  In discussing the issue of transitioning from a mesh to an MCU, one 
  issue raised was if there is a method of notification of all parties 
  on the calls for meshes.

SAP Security
------------

Ian Brown from University College London reported that SAP security is 
nearly complete.  The only major change since the last IETF meeting was 
making PGP support a MUST and S/MIME support a SHOULD.  The draft currently 
references the old PGP standard (RFC 1991), which mandates RSA and IDEA 
support, both of which are encumbered algorithms.  The solution is to 
use the new version of PGP, which will be slotted in as soon as possible; 
it mandates Cast, Triple-DES and Diffie-Hellman, all of which are considered 
unencumbered.  The UCL implementation is almost done and eventually will 
support the latest version of PGP.

Status of WG documents
----------------------

* SAP - Basically SAP is ready to become an Experimental Standard.
  Although it has clear long-term scaling issues, it is probably appropriate 
  for the next 1 to 2 years.  Within a couple month timeframe, the base spec 
  will be merged with the SAP security spec.  

* SDP - After resolving outstanding namespace issues between SDP, RTP, 
  and MIME, SDP has been published as RFC 2327 and has advanced to
  Proposed Standard status.  There is some interest in drafting 
  a recommendation on SDP format parameters.

* RTSP - After being stalled on SDP-related issues, RTSP has been 
  published as RFC 2326 and has been advanced to Proposed Standard
  status.

* SIP - The I-D is on the brink of being re-issued, and should advance
  to Propose Standard within 2-3 months.

* SAP security - Will be rolled into the SAP base spec.

* SIP security - The current SIP I-D now encompasses this work.

* SIP call-control - Still a fairly controversial topic.  The natural home 
  for this work was SIPTEL, but now that SIPTEL has become IPTEL, call
  control is no longer in the charter.  For now, the work will carry on in 
  the MMUSIC working group, but we will collect feedback on a long term 
  home for it.

* Conference Architecture - This I-D is more or less done.  We simply 
  need to make sure that it is an accurate representation of what really
  exists now  --  as it was originally drafted a couple years ago.

* ITU Interoperability - A moving target!  This draft has expired.  
  If rewritten, should it aim to describe what goes in a gateway between 
  MMUSIC and ITU protocols (H.323 and H.245)?  The major concern is that 
  we should not get into this business.  One suggestion is to re-activate 
  the I-D in IPTEL, if and when several gateway implementations have emerged.  
  One Transport AD advised that such a document was not necessarily needed at 
  this point.  However, others thought an I-D that served to compare and 
  contrast MMUSIC and ITU approaches might be useful.

* SCCP - The simple conference control protocol continues evolution as
  it undergoes implementation.  We hope to re-issue the I-D before next IETF.

* The Agreement Protocol - An early I-D in the WG, which has since
  expired.  It is closer in spirit to SCCP, in that it supports 
  general mechanisms for closer coordination sessions with varying policies.  
  There are no current plans to resurrect it, but there is sporadic 
  interest in continuing the work.  One related suggestion was to 
  extend SDP to carry more complicated policy information.

* Conference or Coordination Bus - The idea that there exists a local 
  coordination protocol among components on a single host (e.g., among
  media agents such as audio and video and shared workspaces, which
  might be used to implement voice-to-follow-video operation, or floor
  control, etc.). Is this a protocol the working group should take on?