Subject: [MMUSIC] SDP Capability Negotation: Minutes of 1/9/07 design team conference call

From: Flemming Andreasen <[email-masked]>
Date: Thu, 11 Jan 2007 18:02:33 -0500

Greetings

The SDP Capability Negotiation Design team had a conference call on 
1/9/07. The attendees were:

    Flemming Andreasen
    Matt Lepinski
    Cullen Jennings
    Bob Gilman
    Thomas Stach
    Roni Even
    Colin Perkins

The focus of the call was to discuss the current SDP Capability 
Negotiation solution document  
(draft-ietf-mmusic-sdp-capability-negotiation-00.txt).

There was general consensus within the design team on the direction the 
solution is taking and hence the team agreed to move forward based on 
solution proposed in the document. The team then moved on to discuss the 
following open issues:

1) Version indication and semantics
2) Option tags outside of SDP Capability Negotiation
3) Reliance on attribute order
4) Session versus media-level capabilities

1) Version indication and semantics
The current draft defines a "cver" attribute to indicate the version of 
the SDP capability negotiation framework being used. Questions had been 
raised about how this would actually work outside of the currently 
defined version 0, since there is no ability to indicate multiple 
versions or procedures for what to do.

The team discussed different approaches to dealing with version 
negotiation, ranging from the current text, which provides only a way to 
indicate the currently used version and then reject in case of version 
mismatch, to more sophisticated approaches allowing for version 
negotiation. Colin felt it was important to preseve simplicity. Bob 
Gilman suggested we should rather use the option-tag mechanism (with 
csup/supported and creq/require) to convey version information as that 
would provide for some level of graceful backwards compatibility. This 
seemed to bring the best of both worlds and team agreed to pursue that 
path.

The "cver" attribute will thus be removed and an option-tag for version 
0 defined.

2) Option tags outside of SDP Capability Negotiation
The document notes that the option tag mechanism defined for the SDP 
Capability Negotiation would be generally useful for SDP, and hence the 
scope of the mechanism could be enhanced. The team asked Colin for 
guidance as a chair, and Colin expressed a preference for limiting the 
scope to SDP capability negotiation, since there is an urgent need to 
produce a solution for this, and enhanced scope will only serve to delay 
it. The team agreed with this and hence the scope of the option-tags 
will remain as-is.

3) Reliance on attribute order
Currently, some attributes (e.g. "pcfg" for potential configurations") 
rely on the order in which they are provided to express their order of 
preference. The document notes this as a potential concern with 
middle-boxes that may reorder attributes at the session-level or within 
a particular media stream. Such reordering would be problematic.

The team felt, that it was entirely possible that such middle-boxes 
exist (i.e. entities that reorder attributes they do not understand, but 
otherwise pass them through unmodified) and hence the solution should 
avoid ordering dependencies. For the "pcfg" attribute, this implies that 
an explicit ordering indication must be added. Any other attributes with 
ordering requirements must be updated accordingly too.

4) Session versus media-level capabilities
This is the most complicated problem in the current solution document 
and the team spent a significant amount of time discussing it. The 
structure and format of media capabilities in the current proposal is 
based on the SDP "m=" line. This implies that we have payload types 
(with media-level scope) that need to be accompanied by rtpmaps and 
possibly fmtp attributes for RTP-based transport protocols, whereas 
other transport protocols may use a different format. MSRP for example 
specifies "m=message 7654 TCP/MSRP *" whereas other media formats (such 
as T.38 over UDP) uses a MIME type/subtype structure (e.g. instead of 
"message/*"). This lack of a universal format and interpretation of 
media formats in the "m=" line is in large part what drove the desire to 
reuse the existing format (easier development and no need for additional 
specification of how to represent media formats in SDP Capability 
Negotiation - just use the "m=" line format). Discussion on this 
particular item lead to the conclusion that SDP actually intended for 
the media format to be an actual MIME type (the subtype specifically) 
with the only exception to this rule being RTP-based transport protocols 
(which instead use payload formats). The team agreed to ask the MSRP 
authors if they can change the current MSRP representation in SDP 
accordingly.

Use of payload types in media capabilities at the session level (or 
between media streams) has the problem that payload type mappings are 
media stream specific. For example, payload type 96 may be mapped to 
"G729" in one media stream, and "H264" in another media stream. When 
used at the session level or between media streams, we therefore run 
into potential issues with overlap between streams.

Given the current complexitites in this area, the discussed whether we 
actually need to support media stream capabilities at the session level 
(and/or between media streams). There are two motivations for doing so:
1) Allows for smaller SDP since media capabilities for a particular 
media format will never have to be included more than once. Potential 
configurations (at the session level and/or in more than media stream) 
can then reference the globally defined media capability.
2) Allows us to actually express media capabilites and potential 
configurations at the session level which enables us to indicate 
additional media streams supported, but not offered currently.

Due to real-life UDP limitations, it was felt that message size cannot 
be ignored, and hence that motivation stands. Similarly, several design 
team members believed it was important to allow for potential 
configurations at the session level as well.

The team then discussed three different options for how to actually 
support this:
A) Have media capabilites always use MIME types. In the case of 
RTP-based transports, a mapping to payload types will then be part of 
the actual configuration. The existing "m=" lines will still remain as-is.
B) Use payload types at the session level with clear grouping of 
parameters to their associated latent "m=" line. Two suboptions here:
B1) Allow sesssion-level capabilities to be used at the media level (for 
efficiency) and define rules to deal with potential inconsistencies
B2) Do not allow them to be used at the media level (simpler, but more 
verbose).
C) Use "m=" line with a port set to zero if you want to offer latent 
media stream capabilities.

The team did not conclude on which option would be preferred, in large 
part because the complexities and issues associated with each were not 
well understood. The team therefore agreed to outline a solution for 
each of the three options and base further discussion on that. Bob 
Gilman graciously volunteered to do this before the next call (which 
will take place on 1/17 at the usual time).

Thanks

-- Flemming

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