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

[Magnus Westerlund <[e-mail]>]

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.

> 
> 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.

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]
----------------------------------------------------------------------