Draft meeting minutes

[Joerg Ott <[e-mail]>]

Folks,

please find attached the draft minutes of the MMUSIC meeting
at the 48th IETF in Pittsburgh.

A really big "Thank you" to Tom Taylor for efforts not only to
capture what was said during the meeting but also to do the writeup!

Please review them and send comments as soon as possible.

Cheers,
Colin & Joerg



Draft Minutes of the MMUSIC WG Meeting at the 48th IETF
=======================================================

The MMUSIC WG met twice at the 48th IETF, Monday night 1930-2200 and
Wednesday afternoon 1530-1730.  Some 180 participants attended these
meetings.  In addition, the chairs organized an informal meeting to
further the requirements discussion on SDPng which was held on
Thursday night 2200-2330.

Notes taken and written up by Tom Taylor (Thanks a lot!).


Session 1, Monday, 31 July 2000, 19:30-22:00
--------------------------------------------

1. Agenda Bashing 
   ============== 
   Joerg Ott <[e-mail]> 

The proposed agenda was as follows: 

     Agenda Bashing (Joerg Ott, 5) 

     WG Status Update (Joerg Ott, 5) 

     Mbus Update (Dirk Kutscher, 15) 
        draft-ietf-mmusic-mbus-transport-02.txt 

     Report from the RTSP Bakeoff (Ron Frederick, 30) 

     RTSP Extensions (Sean Sheedy, 15) 
          draft-sheedy-mmusic-rtsp-ext-01.txt 

The proposed agenda was accepted. 

2. WG Status Update 
   ================ 
   Joerg Ott 

a. Organization 

New WG co-chair: Colin Perkins (ISI) <[e-mail]> 
New mailing list almost ready 
Announcements of these changes await the charter page update. 

b. Conferencing Architecture (draft-ietf-mmusic-confarch-03.txt) 

Some non-substantive fixes needed -- will be done during Last Call period.  The document should go to Last Call now. 

c. SAP (draft-ietf-mmusic-sap-v2-06.txt) 

Awaiting IESG approval. 

d. SDP Source Filter (draft-ietf-mmusic-sdp-srcfilter-00.txt) 

Last Call to be issued. 

3. MBus Transport (draft-ietf-mmusic-mbus-transport-02.txt) 
   ======================================================== 
   Dirk Kutscher <[e-mail]> 

Gave URL, quick refresher 
   - local coordination mechanism 
   - the original specification was split into three drafts, one of 
     which covers transport 

Changes in mbus-transport-02 
   - heartbeat hello intervals now dynamically calculated 
      - scale per number of entities -- basic principle that the 
        total number received per unit time should be constant 
        - similar to RTCP timer reconsideration 
           - problem -- slows down bootstrapping process 
           - added mbus.ping to query for other entities 
        - considered stable 
           - could add procedures for behaviour in absence of multicast 
           - intend one more cycle before Last Call (2-8 weeks from now) 

Semantic specifications: 
   Plan: 
     - split into individual parts 
     - informational documents 

Other issues: 
     - connecting physically separate Mbus domains 
     - simple devices -- Mbus bootstrapping, allowing for broadcast 
       rather than multicast 

4. RTSP Bakeoff 
   ============ 
   Ron Frederick <[e-mail]> 

Hosted at Entera, 24-25 Jul 
27 attendees, 7 organizations 
Interoperability of various RTSP clients, proxies, and servers 

OPTIONS 
   - Passing real URL rather than * is useful when proxies are involved 
   - proxy can pass on to origin server rather than reporting its 
     capabilities 

SETUP 
   - Unclear whether servers must allow SETUP without preceding DESCRIBE 
   - Must servers allow setup on subset of tracks e.g. audio only? 

PLAY 
   - Proposed to allow * for URL when PLAY specifies a session 
   - Queued PLAY 

CSeq 
   - Should specify that the CSeq numbers should be unique within a 

     session 

RTP-info 
   - Quoting the URLs would be useful 
     Comment: Jonathan Rosenberg suggested that angle brackets be used 

   - Clarify meaning of "seq" and "rtptime" 
      - more detailed example in the specification? 

   - Should RTP-info also specify the timestamp of the first real packet 
     in the track? 

Session Header 
   - Useful to get session ID to associate state with before setting up 
     a particular media stream 

   - All session ID examples are numeric -- should show alphanumeric 

   - Should SETUP always return Session? -- needed for some types of control 

   - More explanation of session timeouts 
      - distinguish session vs. control connection 

Transport Header 
   - RTP/AVP/TCP and default multicast mutually contradictory 
        -- implies "unicast" should appear in header if TCP used 
        Comment: Steve Casner noted that the lack of multiple implementations 
      of RTP/../TCP is an issue in AVT. 

      But -- does RTP/AVP/TCP imply interleaved?  If not, no current means 
      for client to request it except by specifying channel numbers. 
      Suggestion: specify that interleaved is always implied. 

   - Port numbers: specification should clarify what it means to specify 
     only one port. 
  
   - What is the meaning of port range where port2 is not port1 + 1? 
     Christian Huitema cited an example where multiple non-adjacent ports 
     might be used.  He noted difficulties when trying to coordinate IP4 
     and IP6 port use. 
     Steve Casner reports reluctance to commit to the RTP convention. 

Proxy issues 
   - useful for proxies to add "source" field to transport to direct client 
     RTCPs 

RTP Issues 
   - Servers should take more care with sequence numbers and timestamps when 
     seeking 

   - Setting marker bit for audio in a server is difficult -- servers may not 
     know it is audio 
   - preferable to have clients rely on "seq" field in RTP-info to force playout 
     adaption to occur at the transition point -- works for both audio and video 

SDP Issues 

   - a=control: relative URL handling 
      - How to process Content-Location to obtain base 
      - legality of relative URL at session level 
      - when session-level control specified, does it replace the base URL? 

   - How to do content negotiation 
      - some non-standard extensions e.g. quiktime 

   - On video tracks, "cliprect" field very useful even when playing back at 
     natural size 

Other Issues 

   - "Stream done" notification would be useful 

   - Should RTSP proxies preserve port nos.? 
      - multiple Setups 

   - How should multiple instances of same header be handled 
      - could be legal and sensible for some but not for others 
      - Jonathan Lennox comment: same question in SIP - allow multiple 
        instances for any header which permits comma-separated list of items 

Note from Colin: be sure to share any RTP-related interop results with AVT 

5. RTSP Extensions (draft-sheedy-mmusic-rtsp-ext-01.txt) 
   ===================================================== 

   Sean Sheedy <[e-mail]> 
  
Changes since Adelaide: 

   - ATM address syntax now matches the atmsdp syntax 

   - Unified play queue control syntax 

   - Restrictions on reuse of transport 

.. 

ATM Addresses 

   - Simplified profile and lower transport -- MP2T/AVP/AAL5 

   - NSAP Address -- optional dots 

   - VPI/VCI address -- uses server-spec port addr 

   Didn't include the complete gamut of addressing possibilities 
     - doesn't see as desirable -- too complicated 

Play Queue Control 

   - Previously much interaction between play- , flush-now 
     - now combined in one command 

Reuse of transports 

   - Restricted to presentation URI, ... 

   - Wildcard URIs 
      - clarified restrictions 
      - notes interop suggestions 
      - never allowed in SETUP 

      - URI header in response indicates what specific URIs were 
        matched by wildcard 

Future 

   - Define ATM addressing syntax by reference to ATM SDP document 

   - QAM and DVB addressing syntax 

Someone noted that the transport reuse extension works only with 
simultaneous presentation 
   - typical of nCube applications 
   - would be nice if the mechanism were more general. 

Sean expressed concern that without restrictions one can get into 
trouble. 

The questioner explained that he wanted to play one item after 
another without setup between.  A typical use would be for targeted 
trailers preceding the main feature.  They would use the same codec 
and bit rate. 

It was suggested that one could at least relax the bit rate restriction 
 -- wireless has a scalable bit rate.  Sean found this acceptable. 

A further question was raised regarding bandwidth: what is the 
relationship between the quantity specified when reserving via RSVP and 
the quantity specified in the RTSP?  Which overheads are included? 

Sean indicated this needed more thought -- the relationships are clearer 
with QAM and DVB. 

RTSP Going Forward 

   - Cleanup -> Draft Standard 

     - bug fixes 
     - clarifications 
     - issues -- to go to list 

   - Implementation survey 
     - remove unnecessary parts from draft 
     - demonstrate interoperability 
       -- preconditions for getting to Draft Standard 

   - New bake-off 3-6 months from now -- details TBD 

   - Had other work items 
     - fctl extensions -- Sheedy draft + bakeoff findings 
     - fold into RTSP? 

   - Extensions for other Transports 
     - generalization needed 
     - largely SDP issue 

   - Caching 
     - work continues -- keep as separate spec. 
     - Ron Frederick asked for additional participants to talk through 
       the issues 


Session 2, Wednesday, 2 August 2000, 15:30-17:30
================================================

1. SDP Extensions for ATM (draft-rajeshkumar-mmusic-sdp-atm-02.txt) 
   ========== 
   Rajesh Kumar <[e-mail]> 

Status 
   - key question: will this be accepted as an MMUSIC work item? 
   - applications include Megaco and MGCP control of ATM connections, 
     SIP signalling for ATM 
   - Extensive comments have been received on the list at 
     [e-mail] and have been assimilated into the document. 
   - hoping to finalize in next month and forward for WG Last Call. 

Summary Of Descriptive Capabilities 
   - Bearer network identifier (ATM) 
   - ATM address self-identification 
   - VC and CID addressing 
   - RTP payload type declarations for AAL1 and AAL5 audio 
   - AAL2 profile declarations - standard, custom 
   - AAL5 applications include data, video, H.323 Annex C, af-vtoa-83 
   - correlation of service-level connections with ATM bearer 
     connections 
   - mapping of codecs into services (per Q.BICC) 
   - ATM parameters 
   - special capabilities: leaf-initiated join, anycast, lawful 
     wiretap, SVC caching. 

Rajesh displayed a few examples of the proposed syntax. 

Discussion: the reference to the AAL5/AVP transport stack is incorrect 
as it stands: a reference to a profile document is needed. 

Colin noted that SDP does not currently provide for the use of dollar 
signs ($).  It was explained that these are used for wildcarding. 

Joerg asked SDP experts to re-review the document.  He noted that it 
had made definite progress.  He had some small comments, which he 
would convey to the author off-line. 

2. SDP Media Alignment in SIP (draft-camarillo-sip-sdp-00.txt) 
   ========== 
   Gonzalo Camarillo <[e-mail]> 

Gonzalo's proposal is intended as an interim measure before SDPng 
becomes available. 

The problem is how to signal mid-session changes in media stream 
characteristics, where multiple media streams have been defined. 
A more elegant scheme is needed than matching the Nth line of the 
new SDP against the Nth line of the earlier description. 

Gonzalo provided examples justifying changes in port number: in 
cellular communications, when alternative RTP stacks are being used, 
or when the signalled device is a transcoding point. 

Gonzalo proposes a flow identifier (fid) attribute.  However, there 
is a backward compatibility problem.  The workaround is that the "a" 
line should activate the current session description. 

The question posed to the meeting was whether the proposal is seen to 
be useful.  Christian Huitema expressed his support.  There are 
situations where you want to express alternatives as opposed to 
simultaneous media flows.  You may need different routes for the 
alternatives, implying different "m=" lines.  He suggested "mediaID" 
labels for the "m=" lines, rather than "fid" as proposed. 

The key point is that a method of stating alternatives and switching 
between them is needed. 

Flemming Andreassen asked how RTCP would be managed under the 
proposal.  Gonzalo agreed that this is an open issue. 


Henning Schulzrinne wondered whether the means exist to achieve 
end-to-end agreement that this feature would be supported.  He noted 
the option to use MIME types (e.g. multipart/alternative). 

There was a remark on how a need for precisely this capability was 
identified at the RTSP bakeoff. 

Colin expressed his reaction: this was a medieval way of mangling SDP. 
Jonathan Rosenberg suggested that typically there will be no switching 
between options: the requirement is just "pick one" expression.  Colin 
suggested that was easy to express in an attribute. 

There was initial disagreement on whether one or multiple sessions 
would be needed to achieve the necessary expressiveness.  One person 
noted that there is also the need to support multiple streams 
(audio in particular) at once.  Another remarked that it is also 
desirable to be able to switch dynamically without waiting for a 
signalling round-trip.  The conclusion from this discussion was that 
the alternatives should be expressed as multiple RTP sessions. 

Christian Groves noted Megaco's use of streamIDs and multiple 
alternative sessions.  Tom Taylor added that Megaco uses additional 
semantic tags to indicate whether the intent is "pick one" or "reserve 
all so a choice can be made later". 

Henning Schulzrinne noted an appplication to DTMF routing. 

Colin concluded that the proper approach would be to use MIME 
multipart/alternative. 

3. SIP for xcast-based Multiparty Conferences 
   (draft-van-doorselaer-sip-xcast-00.txt) 
   ========== 
   Bart van Doorselaer <[e-mail]> 
          
The problem: how to set up multiparty conferences. 
   - Sip or SAP? or E-mail or web? 
   - multicast, bridge vs. mesh? 

There are three known SIP schemes: 
   - conference bridge 
      - single point of failure 
      - extra element in the conference 
      - special case of a local bridge still a single point of 
        failure 

   - distributed multi-party conference 
      - bandwidth hog 

   - classical multicast 
      - complexity of address allocation 

At this point the speaker provided a brief introduction to Xcast 
technology.  Xcast is a work in progress.  There are different 
proposals for how it should work.  Distribution is via a tree. 
The packet header contains the (multiple) destinations to 
which it is to be delivered.  In the simple Xcast case, the 
list of IP addresses in the header all use the same UDP port. 
The block diagram Bart showed placed the Xcast capability 
within the IP stack. 

The speaker walked through a three-party call setup, in five 
steps with the call initiator controlling each.  The conclusion 
was that rules need to be established for use of SDP in the   
Xcast case.  There is an issue with UDP port numbers, in that  
they are allocated dynamically.  Possible solutions are: 
   - use UDP-enhanced Xcast 
   - require the destination to allocate the same port as the 
     originator 
   - negotiate the port. 

Conclusion: Xcast is attractive for small conferences, but the 
port issue is present or the UDP-enhanced version of Xcast must 

be used. 

The speaker was asked what happens if the conference grows too 
large.  He confirmed that this would trigger a change in the 
call paradigm. 

Stephen Casner noted that Xcast may or may not be developed. 

Bart was asked whether he himself had developed an Xcast 
application.  He has not yet done so. 

The last question was what sort of device it would be run on. 

4. MPEG-4 (draft-singer-mpeg4-ip-00.txt) 
   ========== 
   David Singer <[e-mail]> 

David Singer gave a brief report on the status of the MPEG-4 
framework draft as it related to MMUSIC. 

The draft currently assumes at most one MPEG-4 session is 
specified in any SDP description.  They hope to lift that 
restriction. 

They have worked on reducing round-trips required to describe 
MPEG-4 sessions. 

RTSP requires particular care in the mapping of streams.  The 
mapping must take account that MPEG-4 features multiple 
independent streams. 

It was necessary to use MIME types to describe MPEG-4 data. 

They are working on dual consensus between ISO and the IETF. 

No comments were received. 

5. TIPHON Requirements For SDPng (draft-tiphon-background-00.txt, 
   draft-tiphon-architecture-00.txt) 
   ========== 
   Paul Sijben <[e-mail]> 

The focus of the TIPHON architectural work is on QOS parameters 
and QOS budget allocation to individual networks along the call 
path.  The TIPHON model deals with user, application, and 
transport views.  Within this framework, SDP deals with the 
application view. 

Paul's presentation suggested a set of mechanism-independent QOS 
parameters.  Parameters dependent on specific transport 
mechanisms could be examined in the future. 

The basic concept of the architecture is that the QOS budget is 
negotiated between elements on the path. 

TIPHON expects to release their documentation in the first 
quarter of 2001. 

[To understand the discussion which followed, it is necessary 
to be aware that Paul's architectural diagram showed a series 
of networks along the call path, with the signalling entities 
controlling the media entities at the boundaries between these 
networks.  Because both signalling and media pass along the same 
path in this model, signalling can meaningfully control transport 
QOS. - PTT] 

Henning Schulzrinne commented that the architecture was puzzling: 
in general, transport and signalling follow separate paths. 
Moreover, the preconditions draft (draft-manyfolks-sip-resource-01.txt) 
is available to coordinate QOS setup.  Jonathan Rosenberg 
seconded the comment on the architecture.  Radhika Roy said he 
could accept the concepts, but was not sure how they would be 
implemented. 

Paul replied to all of these comments that there has to be some 
relationship between the QOS supplier and the user for billing. 

Christian Huitema remarked that the internet requires an absolute 
separation between applications and transport -- for example, 
billing would be based on RSVP. 

Paul Sijben maintained that people were reading too much into 
the architecture.  There will be points through which media must 

pass, with transcoders as an example, and these points will get 
into a QOS discussion. 

Mark Handley expressed similar objections to other members of 
the audience.  Henning Schulzrinne maintained that there was no 
way service providers know how many MGs are in the media path. 

Richard Swale <[e-mail]> suggested that other TIPHON 
documents dealing with QOS may promote a more productive 
discussion. 

6. SDPng -- Requirements (draft-kutscher-mmusic-sdpbg-req-00.txt) 
   ========== 
   Dirk Kutscher <[e-mail]> 

A "bar BOF" on SDPng was announced at the start of this topic. 
Joerg asked for limited attendance. 

Dirk noted that he had published a URL: 
 http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ 
pointing to a collection of relevant documents.  The presentation 
would cover motivation, terminology, general requirements, session 
description requirements, and capability negotiation requirements. 

Motivation 
---------- 
   - no negotiation in SDP 
   - primary extension mechanism is through "a=" 
      - free extensibility 
      - unknown attributes ignored 
         - problem: no way to indicate attributes which MUST be 
           understood or the session fails.  
   - extensions are getting unmanageable 
  
Henning Schulzrinne suggested that the choices for indicating 
mandatory attributes are MIME or an out-of-band indication of 
intent.  Mark Handley noted that PINT solved the issue by 
specifying the "required" attribute tag. 

Dirk added one other motivation for looking at SDPng: the 
limited expressiveness of SDP. 

General Requirements 
---------- 
   - simplicity 
   - ... (see charts) 
   - security 
   - text encoding 
   - SDP-mapping (SDPng to SDP) 
      - may not always be possible 

Henning Schulzrinne suggested that this last requirement be 
dropped and replaced with an advance negotiation of SDP vs. 
SDPng.  On the other hand, it is important that the mapping from 
SDP to SDPng be simple. 

Joerg Ott noted the possibility of a gateway between the two 
protocols -- a mapping is needed in both directions. 

Mark Handley noted the value of SDP.  He indicated a requirement 
to control extensibility of the new protocol. 

Session Description Requirements 
---------- 
   - media types 
      - fit RFC 1889/1890 model of standard and dynamic payload 
        types 
      - reuse payload formats, format names 

Christian Huitema added the need to be able to specify "pick one" 
versus "support all" semantics. 

   - transport parameters 
      - different transports, QOS models, and associated parameters 
   - asymmetric configurations 
   - conciseness, structured extensibility 
      - implies grouping of definitions, ability to refer to groups. 

Capability Negotiation Requirements 
---------- 
   - model for specifying alternatives 
   - negotiation model 
      - syntax, semantics 
   - fit with SIP three-way handshake 
   - feature-unaware negotiation 
   - ability to group capabilities 

Tom Taylor noted the need for the ability to negotiate increments 
to the current session. 

   - able to express constraints 

      - simultaneous capabilities 
      - processing rules. 

Next Steps 
---------- 
   - gather more requirements 
      - Megaco input 
      - specific link layers and protocols 

Mark Handley commented that the new protocol should not obsolete 
SDP: it should be an alternative.  SDP should go to draft standard. 
If this does not happen, it will be a problem for deployed 
implementations. 

Someone else commented that SDPng should not reproduce the complexity 
of H.245.  Another comment: there could be different needs for 
different entities in the signalling path -- endpoints vs. gateways 
vs. proxies. 

7. SDP Next Steps 
   ============== 

Colin volunteered to be the RFC 2327 bis editor.  Mark noted about 
fifteen known errata. 

What is the future? 
   - need an implementation overview and interoperability statements. 

Henning asked if compatibility is necessary.  For example, it would 
be nice to get rid of the requirement for characters in the "s=" line. 
It was agreed that this can't be fixed. 

Mark was especially concerned to learn of implementations for the "v=" 
field -- it is essential to make the specification work (the time 
adjustment part), but no one seems to do it. 

8. SDPng Reprise 
   ============= 

Should SDPng break backward compatibility?  It was agreed that it 
might as well do so, since it was introducing new semantics. 

The timeline was set at a March, 2001 finish. 

The design team would be settled at the bar BOF.