[MMUSIC] Draft minutes from Vancouver

Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
====================================================================

Reported by Colin Perkins

    The MMUSIC working group met once at the 64th IETF meeting  
(Vancouver,
    November 2005).  Topics under discussion included ICE, RTSP, RTSP/ 
SIP
    inter-working, and SDP connectivity preconditions, security for  
early
    media, identification of QoS mechanisms for preconditions, seamless
    session mobility, and codec specific parameters. The meeting was  
chaired
    by Joerg Ott and Colin Perkins and attended by some 140  
participants.


ICE

    draft-ietf-mmusic-ice-06.txt
    draft-rosenberg-mmusic-ice-tcp-00.txt

    Jonathan Rosenberg discussed the updated ICE specification  
starting with
    a summary of the extensive changes since the previous draft (see  
slides
    for details), then moving on to a detailed discussion of the key  
changes.

    The specification of how to use TCP alternatives with ICE has been
    moved into a separate draft. There was some detailed discussion  
of the
    new draft, in particular Cullen Jennings asked why it's not  
possible to
    run ICE TCP using the same port as the original candidate pair?  
This in
    turn led to a discussion of simultaneous open, with Cullen and  
Flemming
    Andreasen discussing whether simultaneous open could be made to  
work in
    ICE TCP, to facilitate operation through symmetric NATs. It was  
noted
    that a BEHAVE compliant NAT will allow simultaneous open without  
a TURN
    relay, but this is not allowed in ICE TCP (since some operating  
systems
    may have problems with simultaneous open of TCP connections).  It  
was
    suggested that change ICE TCP from "MUST open from different  
port" to
    "MUST open from different port and MAY attempt open from the same  
port"
    to resolve this issue.

    The consensus of the room was that it is appropriate to accept  
ICE-TCP
    as an MMUSIC work item.

    Robert Sparks noted that the new ICE draft has many examples,  
some of
    which are rather complex, and suggested splitting them out into a  
new
    draft to simplify the base draft. Jonathan wasn't keen on this,  
seeing
    benefit in the examples, and they compromised by agreeing to move  
the
    complex example to an appendix, replacing it in the main text with a
    simpler example.

    The -06 version of ICE solves the race condition noted during the  
62nd
    IETF meeting using a mechanism based on PRACK and UPDATE.  There  
was a
    heated discussion of this mechanism, with many people complaining  
that
    PRACK and UPDATE are complex and difficult to implement, and  
requesting
    an alternative ICE formulation which doesn't require them. Others  
noted
    that this mechanism was discussed in a previous working group  
session,
    and suggested that the complexity argument was overblown. There  
was no
    resolution to this discussion in the meeting, and after a review  
of the
    issues, an ad-hoc meeting was scheduled to discuss the issues in  
detail
    later in the week (notes from the side meeting were sent to the  
mailing
    list on 14th November 2005).


RTSP

    draft-ietf-mmusic-rfc2326bis-11.txt
    draft-ietf-mmusic-rtsp-nat-04.txt

    Magnus Westerlund reviewed the changes in the latest version of  
the RTSP
    specification. The main changes are: changed version number from  
1.1 to
    2.0; updated the ABNF to conform to RFC 4234 and noted that any  
"string"
    in ABNF is case-insensitive; clarified use of the Allow header in  
SETUP
    and DESCRIBE methods, use of the Transport header parameter  
"mode", and
    use of SET_PARAMETER payloads. The specification is considered  
largely
    complete, except that the minimal implementation section needs  
revising,
    and there is a need for editorial review and simplification.

    Anders Klemets asked if the use of the Range header in PAUSE  
commands is
    a candidate for simplification, since it's one of the more  
complex parts
    of the specification. Magnus replied that this isn't under  
consideration
    since its removal would remove the ability to signal "play  
exactly this
    segment".

    The scheduled discussion of how ICE can be used with RTSP did not  
take
    place, due to the overrun of the previous ICE discussion.


RTSP/SIP inter-working

    Jonathan Rosenberg briefly discussed RTSP/SIP inter-working,  
skipping his
    prepared presentation due to lack of time, and noting that there  
appears
    to be interest in this subject, and that he'll put together an  
initial
    draft. People who are interested in this work should contact  
Jonathan
    to contribute to the proposal.


SDP Content Attribute

    draft-ietf-mmusic-sdp-media-content-00.txt

    Jani Hautakorpi briefly outlined the concept of the SDP content  
attribute
    draft, and noted that the latest draft is now clearly delineated  
from the
    work done in other working groups. It also includes pre-defined  
values of
    the attribute.

    Magnus Westerlund suggested that the next version of the draft  
clarify
    that the content attribute is declarative in the offer/answer  
model, not
    subject to negotiation. Joerg Ott encouraged review, reminding  
the group
    that it will take a while to setup the IANA registry to accept  
further
    registrations, so it is desirable to ensure the initial list of  
labels
    is appropriate and largely complete.


SDP Connectivity Precondition

    draft-ietf-mmusic-connectivity-precon-01.txt

    Flemming Andreasen discussed the SDP Connectivity Precondition.   
This
    completed working group last call without substantive issues, but  
the
    authors felt a few changes were warranted, and submitted the -01  
draft.
    Changes in this version include: the recommended baseline method of
    connectivity checks for datagram transport was changed from RTP  
No-op to
    ICE; procedures associated with using ICE to verify connectivity  
were
    clarified; and it was clarified that the semantics of the  
connectivity
    preconditions do not include verification of the peer identify. This
    draft will be updated to match future changes in ICE, and is  
intended
    to progress in tandem with ICE (on which there is now a normative
    dependency).


Early Media for SDP Security Descriptions

    draft-wing-mmusic-sdes-early-media-00.txt

    Dan Wing and Rob Raymond discussed early media and security  
descriptions
    for SDP.  The issue here is that early media can't be secured  
until the
    SDP answer arrives, and this can potentially cause clipping.  A  
possible
    solution is to use security preconditions, but this adds  
additional call
    setup time and is complex to implement, therefore this draft  
proposes to
    include a key for the called party to use in the initial SDP  
offer. This
    doesn't require PRACK of preconditions, and so is simpler to  
implement.
    There are some open issues regarding use of MKI, early media  
forking,
    and retargeting.

    Dave Oran repeated a comment from the ICE discussion that PRACK  
will be
    needed eventually, and that implementers need to accept its  
complexity.
    He also agreed that this is the logical solution, should one not  
wish to
    implement PRACK. There was discussion regarding the usefulness of  
secure
    early media, with the general consensus that it was useful. There  
was no
    consensus on this particular proposal however: an approach going  
forward
    would be to consider the requirements and constraints, and how  
they are
    addressed by existing mechanisms, before completing the details  
of this
    proposal.


QoS Mechanism Identification in SDP

    draft-polk-mmusic-qos-mechanism-identification-00.txt

    Gonzalo Camarillo discussed a new draft that proposes ways to  
indicate
    which QoS mechanism is to be used for media streams.  This can be  
used
    with the QoS precondition and the SDP offer/answer model, for  
example,
    to negotiate either RSVP or NSIS. Gonzalo posed two questions: is  
there
    a need to agree on something else in addition to the mechanism to  
use
    (e.g. parameters for the mechanism), and if so should the draft  
discuss
    how to agree those parameters?

    Flemming Andreasen asked how things like within-network RSVP proxies
    interact with this sort of mechanism? Jonathan Rosenberg asked  
where the
    fallback to a different QoS scheme was handled? E.g. if one  
wishes to
    try NSIS then fallback to RSVP when not available, is that  
handled by
    the QoS layer or does it need to be signalled in SDP? These  
questions
    led to further requirements discussion, rather than consideration  
of the
    details of the draft.

    There was no clear consensus to accept this as an MMUSIC work  
item. The
    chairs noted that there was general interest in the concept  
though, and
    suggested that draft be further revised as an individual draft  
with more
    requirements discussion, and we can revisit the decision to  
accept this
    as a work item at next meeting.


Requirements for IPsec Negotiation in the SIP Framework

    draft-saito-mmusic-ipsec-negotiation-req-01.txt

    Makoto Saito discussed requirements for IPsec negotiation in the SIP
    framework. This draft discusses why one might want to use SDP offer/
    answer with sdescriptions/mikey to negotiate IPsec parameters, which
    can be applied to secure the media streams.

    Colin Perkins noted that IPsec can be used to secure arbitrary  
sessions,
    not just multiparty multimedia sessions, and wondered if SDP  
offer/answer
    is an appropriate base for such negotiation, or if this is  
outside the
    scope of MMUSIC? Others, including Jon Peterson, considered this  
in scope,
    since it requires extensions to sdescriptons. Jon Peterson and  
Joerg Ott
    noted, however, that there is no obvious community interest in  
the work,
    and as a result it seems premature to consider it as an MMUSIC  
work item.


SDP Extensions for Seamless Session Mobility

    draft-mingqiang-mmusic-session-mobility-attribute-01.txt

    Xu Mingqiang discussed requirements for seamless session mobility,
    aiming to transfer a streaming media session between devices without
    disruption to the playout. Compared to the version discussed at the
    previous meeting, this draft contains a more detailed requirements
    discussion, without presupposing a particular solution.

    Magnus Westerlund and Colin Perkins noted that the draft still  
confuses
    several problems that should be treated separately, for example  
moving
    sessions between users and synchronised playout. Further  
clarification
    of requirements is needed, treating problems individually, rather  
than
    with a systems focus.


Codec Specific Parameter in SDP

    draft-xu-mmusic-sdp-codec-param-00

    Peili Xu discussed adding general codec parameters to SDP. There  
are two
    requirements here: 1) a per-codec equivalent to "a=ptime:",  
rather than a
    media level parameter as currently defined; and 2) codec level  
transport
    addresses, to divert certain payload formats away from the  
addresses on
    the c= and m= lines, for example to insert a transcoder.

    Magnus Westerlund noted that the second requirement can be solved  
using
    a separate signalled session incorporating the transcoder. Joerg  
Ott and
    Colin Perkins agreed, suggesting both requirements might be  
solved using
    existing protocols and mechanisms. Further clarification of  
requirements
    and the degree to which existing mechanisms apply is needed  
before this
    draft can proceed.

				   - + -


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic