Re: [MMUSIC] Review draft-ietf-mmusic-sdp-mux-attributes-06

["Stach, Thomas" <[e-mail]>]

Suhas,
just a few replies below ...

 
5.7 a=crypto
I don’t think the text goes far enough. 
The category TRANSPORT can only be applied if one assumes that all bundled m-lines contain the a=crypto attribute and together with the same crypto suite.
Otherwise, if you want to bundle m-lines offering SRTP with some that offer RTP, the RTP m-lines would have inherit the SRTP master key and would be encrypted.
One resolution could be a restriction to bundle only m-lines that all offer SRTP and use the same SRTP keying mechanism.
 
[Suhas]. This was the assumption made as required by Section 10.1.1 of BUNDLE draft which mandates the proto value for all the m=lines BUNDLED MUST be same. Thus bundling RTP/AVP with RTP/SAVP for example is not allowed by design.
[TS] Yes, you're right
 
Alternatively, you could also apply the NORMAL category and use the key material as provided for the corresponding m-line, if any.
The correct key material for a specific RTP stream would have to be determined via the RTP header extension from draft-bundle.
Using NORMAL in such a way would also allow for bundling of RTP and SRTP m-lines, even if the keying material is provided by different key exchange mechanism like MIKEY and SDP Security Descriptions.

[Suhas] - I would prefer deferring this to future specifications on defining the procedures to use different keying mechanisms for SRTP keys in a given Bundle group.
[TS] OK. This might get more complex than it looks at first sight. TRANSPORT keeps thing simple.

OTOH even if there are m=lines that differ in the keying mechanisms, the category TRANSPORT implies that the keying mechanism corresponding the BUNDLE address needs to be considered. So the Offerer/Answerer has a choice on choosing which m=line's BUNDLE-tag appears first in the BUNDLE group.
 
 
5.14 a=rtcp attribute
The category needs to be changed from IDENTICAL to TRANSPORT.
Otherwise it conflicts with https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-14#section-10.3.2 
In case of a=rtcp-mux draft-bundle prescribes a=rtcp with a port identical to the RTP port and deliberately avoided choosing identical RTP ports in the m-lines.
If ICE is used, a=rtcp would carry the default RTCP candidate, which again would not necessarily be identical for all m-lines.

[Suhas] : Completely agree. Thanks for catching this. I will update the draft to reflect the same 
 
5.35 a=key-mgmt attribute 
 
The table is a bit misleading as it seems to imply that there is a a=mikey attribute, where the prtcl-id  value in the a=key-mgmt attribute is actually meant. Similar as for section 5.7 the prtcl-id  would need to be the same for all bundled m-lines. 
The key-mgmt-data part (i.e. keying material) of the a=key-mgmt attribute could however still be different for each m-lines similar as for the a=crypto attribute. 
Due to the similarities with a=crypto (or a=fingerprint in section 5.36) I think that TRANSPORT (or NORMAL as proposed above) is a better fit than IDENTICAL. 
 
5.39 ZRTP
Similar to section 5.7, the RTP header extension from draft-bundle would allow that the a=ZRTP-hash can be associated to the corresponding media stream. With that I don’t see why this can’t be changed from NOT RECOMMENDED to NORMAL. 
TRANSPORT couldn’t probably used as not all m-lines are required to use a=ZRTP-hash

[Suhas] :  NOT RECOMMENDED still seems to be appropriate for the very same reason that some of the media lines might not have zrtp-hash undefined.  However, in future if there exists a specification that describes the header extension for using zrtp-hash in BUNDLE scenario, we can always upgrade the mux category referencing that specification.
[TS] OK

I'm also fine with the rest of your responses.


Regards
Thomas