There's a more fundamental architectural issue we need to agree on first, namely the scope of the problem we want to solve. It's difficult to design and compare solutions without agreement on this important point, and clearly different drafts have different scope presently. Having said that, rather than answering the specific question of whether you need to specifically indicate the negotiated profile on the "m=" line or not (which I agree is important, but probably more in the design phase), I'd like to take a step back and offer a couple of general design guidelines here that I believe are important to any solution to whatever agreed upon problem space we end up with:
1) Be explicit. Whatever we do needs to be signaled explicitly and should not rely on either one or both sides inferring the intentions of the other side based on some conventions for how particular existing SDP parameters and attributes happen to be included, omitted or combined in SDP. Syntax and parsing is easy; semantics is where the real work is, so let's not try and cut any syntatical corners here. I've seen it done in the past (more than once), and the result is always the same: unclear semantics in an ever growing list of cases, and future upgrades and changes become a nightmare.
2) Don't abandon current practice unless we have to. SDP and the offer/answer model is based on one side (offerer) indicating what it can and would like to do, and the other side (answerer) choosing from that and indicating the selected subset (possibly plus some additional parameters). There are explicit parameters defined for a lot of information already, and while it's certainly possible to change all of that, we sholdn't unless we have to. Case in point: If there is a way to communicate the profile, payload types, transport protocol, etc. being used, then let's reuse that. Again, I'm not as concerned about syntax as I am about semantics, which not only has to be specified for such new parameters, but now also needs to consider how they relate and interact with already defined semantics for the existing parameters.
3) Middle boxes exist and they need be able to infer things from the SDP. Whether we like it or not, middle boxes exist and we need to account for them. Cable, wireless, and wireline all have some type of SIP "proxy" (or rather B2BUA) that needs to inspect SIP signaling and either authorize and/or actually reserve QoS based on what it sees negotiated. Yes, I know this is outside the traditional IETF model, but we are looking for a solution to real-life problems here and hence we can't ignore this (or alternatively, we may have two different sets of problems to look at). The implication of this one is that the signaling channel (SDP) must provide some indication of what is actually going on (whether in an m= line or something else).
-- Flemming EKR wrote:
As people will recall, in the RTPSEC meeting in Montreal it became clear that we needed some way to support best-effort encryption. Loosely speaking, it seems to me that there are two major ways to do this: - Have nothing in the signalling and probe in the media plane as ZRTP does in bump in the wire mode. - Have something in the offer that says "I will speak SRTP" but doesn't require it. There have been a bunch of different suggestions about how to do this (draft-andreasen-mmusic-sdp-capability-negotiation-01, draft-kaplan-mmusic-best-effort-srtp-01, draft-zimmermann-avt-zrtp-02, etc...). Regardless of which key management protocol we ultimately choose, we need to sort the fundamental architectural issue of: Does the signalling (SDP) have to reflect RTP/SAVP? If the answer to this question is "Yes", then we either need to: 1. Have some convenient way to offer multiple profiles (Flemming's draft surveys the space of options here). 2. Do an UPDATE with RTP/SAVP for every secure connection. I get the impression people find this distasteful. If the answer is "No", then you can simplify the offer/answer exchange by having the signal that you will do security in an a-line, but at the cost of having the profile no longer reflect what's on the wire. In either case, it seems like deciding this architectural issue is something we need to do before we spend a lot of time discussing the details of mechanisms. -Ekr _______________________________________________ mmusic mailing list mmusic@xxxxxxxx https://www1.ietf.org/mailman/listinfo/mmusic