Re: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.txt

["Charles Eckel (eckelcu)" <[e-mail]>]

I think this is a useful document; However, I do have a few comments and concerns regarding its focus and relationship with other drafts.

1) Section 3, Motivations. It currently reads as follows:

   This section looks at the motivations why an additional solution is
   needed assuming that you can do both the classical method of having
   one RTP session per transport flow as defined by the RTP
   specification [RFC3550] and when you have multiple media types within
   one RTP session [I-D.ietf-avtcore-multi-media-rtp-session].

How about the following instead:

   This section looks at the motivations for standardizing two mechanisms 
   for multiplexing multiple media types within a single transport flow:
  1) having one RTP session per transport flow, as defined by the RTP
   specification [RFC3550], and multiplexing multiple RTP session per transport
   flow, as defined in this document ( or elsewhere if preferred to split it out).
  2) having  multiple media types within one RTP session, as defined in
  [I-D.ietf-avtcore-multi-media-rtp-session].

2) Sections 3.1 and 3.2 are motivations for (2) and are duplicated in  [I-D.ietf-avtcore-multi-media-rtp-session] , whereas sections 3.3 and 3.4 are motivations for (1). Perhaps it is best to remove sections 3.1 and 3.2 and let this draft focus on the reasons why (1) is needed, as that is real focus of this draft.

3) Section 3.5 is more a statement of the requirement for a way to negotiate (1) vs (2), rather than a motivation for either.

4) Section 6.2, Signaling, contains the following:

   The 'session-mux-id' attribute is included for a media description,
   in order to indicate the Session ID for that particular media
   description.  Every media description that shares a common attribute
   value is assumed to be part of a single RTP session.  

Is that true? I think you meant to say these may exist in one or more RTP sessions, with the RTP sessions being multiplexed on a single transport flow.
And the later it reads as follows:

   An SDP Offerer
   MUST include the 'session-mux-id' attribute for every media
   description associated with a 'SHIM' group.  If the SDP Answer does
   not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based
   layering.  However, if that is separate RTP sessions or BUNDLE is
   determined on what was present in the offer and answer.  This will
   depend on what the offering party likes to happen. 

You lost me here. Hopefully some  rewording would help.

Cheers,
Charles

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Magnus Westerlund
> Sent: Monday, October 22, 2012 11:31 AM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: New Version Notification for draft-westerlund-
> avtcore-transport-multiplexing-04.txt
> 
> WG,
> (As individual)
> 
> We have now submitted an update to the multiplexing of multiple RTP
> sessions over a single transport (SHIM). The changes in this version are:
> 
> - Making the SHIM 2 bytes, pre-fixed and it include a fixed pattern for
> STUN and DTLS separation.
> - Propose that we do some key-derivation for different RTP sessions so
> that a single key-management sequence can key all the session when doing
> DTLS-SRTP.
> 
> The signaling solution in this draft has not been improved yet, we are
> awaiting resolution of the BUNDLE discussion in MMUSIC to better
> understand what path is selected and how to interact with that solution
> and take the raised concerns into account.
> 
> We have now discussed this proposal for some time and it appears clear
> that it targets a useful combination of trade-offs. We authors would
> like to request WG adoption of this proposal.
> 
> Cheers
> 
> Magnus