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.
- + -
|