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.

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.

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.

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.

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.

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.

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.

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.

- + -