[MMUSIC] Minutes for Paris meeting

[Colin Perkins <[e-mail]>]

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

Reported by Colin Perkins

    The MMUSIC working group met once at the 63rd IETF meeting  
(August 2005,
    Paris).  Topics under discussion included RTSP, ICE, SDP  
extensions for
    congestion status reports, buffer handling for mobility, media  
loopback,
    and content identification, requirements for IPsec negotiation,  
and Data
    Broadcasting Services. The meeting was chaired by Joerg Ott and  
Colin
    Perkins, and attended by approximately 160 people.


RTSP

    draft-ietf-mmusic-rfc2326bis-10.txt

    Magnus Westerlund outlined the changes since the previous version  
of the
    RTSP specification (outlined in the slides), and discussed open  
issues.

    Open issue: the state machine is not useful, due to automatic  
transfers
    between states, and the weak synchronisation between client and  
server.
    Magnus suggested making the state changes explicit in the  
protocol, with
    notification messages to indicate transitions. Anders Klemets  
expressed
    concern about the complexity this may introduce, noting  
similarity with
    the ANNOUNCE method. Dave Singer wondered if the transition from  
playing
    to paused could be made explicit by adding a header to the play  
response
    to state "if you do nothing else, at this time you'll be in  
pause", and
    if this would be closer to current SDP.

    Open issue: should the Allow header be included in DESCRIBE and  
SETUP?
    Anders noted that, if you support all the "normal" methods, then  
there
    is no need for the Allow header. However, if you support only a  
subset
    of the methods, or if you support additional features, Allow  
header is
    strongly recommended. Magnus agreed, and will make Allow  
conditional on
    the presence of unusual/missing features.

    Open issue: the "minimal implementation" section is difficult to  
make
    consistent with the rest of the specification, and allows  
implementers
    to be fooled into thinking they know what is required without  
reading
    the rest of the specification. Since the new specification is  
clearer
    than RFC 2326, Magnus suggests removing this section. Anders  
asked for
    this to be kept, since the specification is so big. Dave Singer  
asked
    if the minimum implementation section should say to implement all  
the
    draft, and highlight the non-obvious points. Resolution: need to  
keep
    this section, but perhaps update its content.

    Magnus made a plea for reviewers, offering to buy a beer for anyone
    who does a complete review! Dave Singer wondered if a reviews could
    be solicited from ISMA or 3GPP, since they make heavy use of RTSP.

    Magnus concluded by presenting some initial thoughts of the use  
of ICE
    with RTSP, and outlining a possible call flow to show where the  
checks
    can fit into the RTSP negotiation.


ICE

    draft-ietf-mmusic-ice-05.txt

    Jonathan Rosenberg summarised the changes in the latest version  
of the
    ICE specification (see slides). There are still five open issues  
which
    were discussed.

    Open issue 1 (STUN floods): general agreement with the proposed fix.
    Francois Audet noted that if the draft gives the impression hundreds
    of checks are needed, then people won't do the check at all -  
need to
    give reassurance in the draft, and perhaps explain that applications
    can stop after finding a working address. Dan Wing expressed concern
    about mid-call changes, and the effects these have jitter buffers in
    the applications. Dan also noted that STUN checks increase number of
    NAT bindings even when made mid-call, and may cause failures because
    of this load no matter when the STUN check is made.

    Open issue 2 (TCP or not TCP): lots of discussion, with Cullen  
Jennings,
    Dan Wing and Francois Audet arguing that inclusion of TCP support  
will
    delay the draft and introduce unnecessary coupling that might  
discourage
    implementers, and Jonathan Rosenberg, Magnus Westerlund, Dave  
Oran, and
    Jon Peterson arguing that TCP support should be included to  
compete with
    proprietary solutions. The sense of the room was to split TCP  
usage with
    ICE out into a separate draft, since the controversy surrounding  
the TCP
    support would delay the progression of the base ICE draft.

    Open issue 3 (default timers) was skipped due to lack of time.  
Please
    review and comment to the mailing list.

    Open issue 4 (STUN authentication and SIPS): no objection. Robert  
Sparks
    noted that the "sips is SHOULD use" is a requirement where people  
won't
    do it; the draft needs text making it very clear that this is  
essential.

    Open issue 5 (normative dependency on STUN).  Propose to  
reference RFC
    3489 instead of the 3489bis draft, due to questions over the  
timing of
    the 3489bis draft. No objections.


Requirements for IPsec Negotiation in the SIP Framework

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

    Makoto Saito presented some requirements for using SIP as a key  
exchange
    protocol to negotiate IPsec parameters for media streams.  
Francois Audet
    wondered if the SDP key management work was appropriate for this  
task.
    Colin Perkins asked for clarification on the requirements: why is  
this
    solution appropriate, and why not use existing methods for  
negotiating
    IPsec keys? The chairs noted that it's unclear MMUSIC has the  
experience
    to review this work, and deferred a decision to take this as a  
work item
    until it has received more review.


Requirement of service provider for the Data Broadcasting Service

    draft-lkchoi-mmusic-iptvdbs-req-00.txt

    Lark Kwon Choi presented some requirements for the data broadcasting
    service over IP networks. There were several questions seeking to
    clarify the requirements and understand what was needed from MMUSIC,
    but no conclusion was reached during the session. Further discussion
    will happen on the mailing list.


Congestion status precondition

    draft-alexander-congestion-status-preconditions-00.txt

    Corey Alexander presented a congestion status precondition, for  
use with
    the SDP preconditions framework and SIP.  Discussion focusses on  
the SDP
    parameters, rather than on the mechanism for monitoring  
congestion (that
    was discussed in AVT and TSVWG).

    Dan Wing asked why, if an RTP payload format is used, it's not  
signalled
    in the SDP? Corey explained that the ECN probing format isn't  
media used
    in the session and so didn't need to be signalled. Dan expressed  
concern
    about this inconsistency.  Jonathan Rosenberg noted that this is  
similar
    to STUN, which isn't signalled on the "m=" line either, since  
it's not a
    media format: maybe "a=candidate" lines would be a better fit,  
with STUN
    packets carrying the ECN probes rather than RTP packets?

    Joerg Ott wondered if congestion state is a persistent property  
that can
    be represented in the session state; ephemeral network  
characteristics
    are not usually considered appropriate to signal in SDP.

    Dave Oran asked if the existing SDP "qos" precondition couldn't  
be used
    as a congestion status precondition, treating unmarked ECN probes as
    evidence that the required QoS has been achieved?

    Colin Perkins concluded by noting that there is some clear  
concern over
    this proposal. Further discussion is needed on the mailing list,  
after
    the other aspects have been discussed in AVT and TSVWG.


Buffer handling attributes

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

    Xu Ming Qiang presented SDP buffer handling attributes for mobility.
    Magnus Westerlund commented that the synchronisation issues are much
    greater than discussed here, and that it's not clear that the simple
    mechanisms described solve the problem.  Dave Oran agreed, and would
    like to see the synchronisation and media slicing problem understood
    before we work on the signalling.


SDP content attribute

    draft-hautakorpi-mmusic-sdp-media-content-01.txt

    Jani Hautokorpi discussed the SDP media content attribute. This  
has been
    updated as a result of comments at the previous meeting, and  
there seems
    to be a reasonable amount of interest.

    Joerg Ott asked for clarification whether attributes are an  
enumeration
    of properties, or if there is just a single attribute per  
channel. Joerg
    also commented that the draft needs to clearly define the  
borderline for
    what makes a reasonable attribute.

    A decision regarding taking this as a work item was postponed to the
    mailing list.


SDP media loopback

    draft-ietf-mmusic-media-loopback-01.txt

    Kaynam Hedayat discussed the SDP media loopback draft,  
summarising the
    changes since the previous version (introduction of an additional  
type
    of loopback: rtp-start-loopback). Joerg Ott asked that the  
attributes
    be named "loopback:..." rather than "...-loopback", but otherwise  
there
    were no comments.

                                   - + -



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic