Subject: [MMUSIC] SDP Capability Negotation: Minutes of 12/12/06 conference call

From: Flemming Andreasen <[email-masked]>
Date: Sun, 17 Dec 2006 17:12:50 -0500

Greetings

The SDP Capability Negotiation Design team held its first conference 
call on 12/12/06. The attendees were:

Flemming Andreasen
Thomas Stach
Roni Even
Bob Gilman
Matt Lepinski
Colin Perkins
Xavier Marjou
Joerg Ott

1) We briefly discussed the scope of the problem we want to solve and 
agreed it was larger than just solving "best-effort" SRTP. There was 
general agreement with the IETF 67 MMUSIC minutes on problem scope, 
which says that we should produce a common, generic but modular solution 
to do SDP capability negotiation that allows for incremental pieces to 
be deployed (i.e. keep in mind that it should provide a solution for 
things needed now like best effort SRTP).

2) The team then discussed the deliverables to be produced by the team. 
We agreed we will have two:
- a requirements document
- a solution document
The current requirements document is 
draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt, which 
will be turned into a WG document in the next iteration. We do not 
intend to turn this document into an RFC, but may include the pure 
requirements aspect of it in the solution document later (e.g. as an 
appendix).

3) The team then proceeded to review the current requirements 
(draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt). There 
was general consensus on the requirements, except as detailed below.

REQ-50 (alternative transport protocol and media combinations) may have 
interactions with ICE. We need to consider these interactions further.

REQ-80 on backwards compatibility for SIP lead to some discussion around 
what it actually means to be backwards compatible for SIP.  For example, 
would rejection of an offer due to unsupported extensions be considered 
backwards compatible ? The answer is clearly "no" due to the 
heterogeneous error response forking problem (HERFP) in SIP. To help 
frame the discussion, Joerg suggested that there are three different 
types of backwards compatibility:
- Best-case:      Automatic fallback to a minimal baseline when 
extension not supported
- Worst-case:   Offer is rejected
- Misbehaves:   The answerer does something that was not intended

The intent with the requirement is for "best-case" backwards 
compatibility and there was general consensus around that, with the 
caveat being that we may revisit it later if it proves to difficult to 
meet (or requires us trading off important functionality).  The 
requirement will be clarified accordingly.

Colin noted that a related issue is how backwards compatibility may 
affect middle-boxes and whether REQ-80 extends to those as well. There 
was general consensus that we cannot provide complete backwards 
compatibility to middle-boxes, however we should not ignore it 
completely either. Properties similar to those provided by ICE, where an 
updated offer/exchange with the final result is performed after the 
initial exchange, were seen as desirable (albeit not an absolute) 
requirement. There was general consensus on this point and a requirement 
to that effect will be added.

REQ-120 discusses the answerer simply choosing from the set of potential 
configurations included in the offer. There was general consensus on the 
requirement, however the team discussed whether the answerer should be 
able to include additional capabilities in the answer (above and beyond 
what was included in the offer). There was consensus to add a new 
requirement saying it would be nice to have the ability to specify 
additional media streams (latent capabilities) in both the offer and the 
answer. We do not want to do a lot of extra work to enable that, however 
if it happens to fall out (or be enabled) by the mechanism that would be 
nice. Clearly not a MUST requirement.

REQ-130 says the mechanism "must work in the presence of SIP Forking". 
It's not clear what "works" mean. The requirement needs to be firmed out 
to state that it should not work less well than current offer/answer 
procedures with SIP forking. The mechanism MUST NOT introduce any new 
failures.

REQ-150 says it MUST be possible to specify valid combinations of media 
lines. There was some pushback on (and none in favor of) having this as 
a MUST requirement. There was team consensus on it being a useful 
capability, e.g. to account for devices with small form factors that 
would preclude certain combinations of media. There has however been 
people (not present on the call) arguing for this requirement 
previously, so requires further list discussion.

REQ-160 says it MUST be possible to specify valid combinations of media 
formats between media streams. There was significant pushback on having 
this as a MUST requirement as it gets complicated very quickly (e.g. 
extend it to frames, resolution, etc.). We may have the capability but 
several team members felt it should not be a requirement (and none on 
the call argued that it should). Roni noted that current video 
implementations typically does not implement such a mechanism (e.g. in 
H.323). Thomas provided a use case where a single UA front-ends two 
devices, each of which can support a single audio and a single video 
codec (all of which differ). The requirement would enable the UA to 
express this in a single offer. Joerg suggested this may be a corner 
case and there may be alternative solutions for it. As for REQ-150, 
there has however been people (not present on the call) arguing for this 
requirement previously so requires further list discussion.

REQ-300 addresses the modularity and extensibility aspect of the SDP 
capability negotiation mechanism. There was general team consensus on it 
but also a decision to extend it to clearly identify which version of 
SDP capability an entity supports as well as clearly indicating which 
capability negotiation extensions are supported, as well as which 
capability negotiation extensions are required to be supported by the 
answerer (similar to SIP "Supported" and "Require" headers).

REQ-310 suggests that REQ-50, REQ-150, and REQ-160 are not part of the 
core (required) functionality, but instead are enhancements. Colin felt 
that REQ-50 should be part of the core, whereas Matt did not - further 
list discussion required. Team consensus that REQ-150 and REQ-160 will 
be enhancements which led to the question as to whether they should then 
be part of the core specification or not ? Joerg noted that if we don't 
develop solutions for them at the same time as we develop the core 
solution itself, we may not have the right structure in place. There was 
general consensus on this point.

Additional requirements:
Joerg brought up the issue of layered codecs which may use multiple 
media descriptions (m= lines). How do we express that in terms of 
capability negotiation and what are the requirements associated with 
that ? Team agreed this requires further consideration and Joerg agreed 
to provide some text on it.

Flemming will produce an updated requirements document in accordance 
with the above.

4) Discuss general direction for solution
Finally, the team briefly discussed the general direction for the 
solution. Flemming suggested using the solution proposed in 
(draft-andreasen-mmusic-sdp-capability-negotiation-01.txt) as a 
baseline, and update it in accordance with the requirements as well as 
outlined previously (in particular, it will no longer reuse the RFC 3407 
syntax). There was team consensus to continue down this path, and 
Flemming will produce an updated proposal for the solution document in 
accordance with this.

Thanks

-- Flemming

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