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

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

Hi Magnus,

Please see inline.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, November 14, 2012 7:27 AM
> To: Charles Eckel (eckelcu)
> Cc: IETF AVTCore WG
> Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-
> westerlund-avtcore-transport-multiplexing-04.txt
> 
> Hi,
> 
> Thanks for the comments.
> 
> On 2012-11-03 18:41, Charles Eckel (eckelcu) wrote:
> > 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].
> 
> Yes, that is clearer.
> 
> >
> 
> > 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.
> >
> 
> I will need to think about this. It might be that some restructuring are
> needed in general to consider both when a single transport is motivated
> and what the motivation is for having multiple RTP sessions over one
> transport flow. Thus maybe further tweaking of the introduction section
> and the structure.
> 
> > 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.
> 
> Then I don't think the message comes across that this session tries to
> describe. To deploy a mix of legacy multiple RTP sessions clients and
> single RTP session with multiple media types clients are not possible in
> a joint multi-party conference unless one have a full RTP level
> translation capable middlebox.

I see now. I was not coming to that understanding with the existing wording in the draft. Incorporating the text you provided above would help. 
 
> >
> > 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.
> 
> I wonder if what you are getting confused over is the statement that
> multiple m= lines where each m= lines contains the same SID would form a
> joint RTP session. That was a notion that is included, but based on the
> BUNDLE discussions I think should be avoided as the majority of the
> difficult issues with BUNDLE is due to having multiple m= lines be part
> of describing one RTP session.

Actually, I think it is okay and useful to describe the way 'session-mux-id' works in the presence of both BUNDLE and SHIM, as an offer may well include both methods. Alternatively, you could make the two mutually exclusive. That removes some complexity, but I think it is a complexity we need to address if both approaches continue to progress. 
My remaining comment is that the following sentence does not parse:

   However, if that is separate RTP sessions or BUNDLE is
   determined on what was present in the offer and answer.

Reworking that would be helpful, as this contributed to my initial confusion.

Cheers,
Charles

> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------