Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-05.txt

From: Christian Groves <[email-masked]>
Date: Fri, 05 Dec 2014 12:31:53 +1100

Hello Suhas,

A few comments:

1) With regards to 5.55 ITU-T-Rec.Q1970 I think mux category "Not 
Recommended" or "Special" would probably be more appropriate. a=ipbcp is 
used to signal the version and type of a SDP based IPBCP message. It's 
used in a BICC (ITU-T Q.1901) environment limited to a single media 
payload. The use of IPBCP messages for multiplexed transport would 
require updates to several Q.19xx series Recommendations.

Also the heading title should be changed to align with the other ITU-T 
related heading, i.e. from "ITU-T-Rec.Q1970" to "ITU-T Q.1970".

2) 5.48 ATM SDP - I still not quite sure about the criteria for 
assigning the mux category. The text indicates that "For all adaptation 
types (AAL1, AAL2 and AAL5), bearer connections may be bundled into a 
single media group" however the BUNDLE draft is only for nettypes IN and 
addresstypes "IP4" or "IP6". So I wouldn't assign mux category "NORMAL" 
because some extra work would be needed to define how BUNDLE would be 
used for the ATM SDP parameters.  If multiplexing was applied then would 
the attributes related to the underlying ATM bearer need to be identical 
i.e. attributes from 5.6.1/RFC3108? Given the age and that these are not 
IP related, i'd be inclined to mark them all as NOT RECOMMENDED.

3) 5.56 H.248.15 - FYI there's some work underway in the ITU-T SG16 on 
the support of multiplexing based on BUNDLE in H.248.STGROUP 
(http://wftp3.itu.int/av-arch/avc-site/2013-2016/1411_Seo/TD-14.zip).

Regards, Christian

On 27/11/2014 1:02 AM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>
>          Title           : A Framework for SDP Attributes when Multiplexing
>          Author          : Suhas Nandakumar
> 	Filename        : draft-ietf-mmusic-sdp-mux-attributes-05.txt
> 	Pages           : 88
> 	Date            : 2014-11-26
>
> Abstract:
>     The Session Description Protocol (SDP) provides mechanisms to
>     describe attributes of multimedia sessions and of individual media
>     streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
>     multimedia session.  In the RTCWEB WG, there is a need to use a
>     single 5-tuple for sending and receiving media associated with
>     multiple media descriptions ("m=" lines).  Such a requirement has
>     raised concerns over the semantic implications of the SDP attributes
>     associated with the RTP Media Streams multiplexed over a single
>     underlying transport layer flow.
>
>     The scope of this specification is to provide a framework for
>     analyzing the multiplexing characteristics of SDP attributes.  This
>     specification also categorizes the existing SDP attributes based on
>     the framework described herein.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-05
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 8 Dec 2014 17:53:52 +0530

Hello Christian

  Please see inline for the responses.

   Also,  a question to chairs,  should I produce a newer version of the
document to reflect the changes below or wait till we end the last call.

Please advice.

Thanks
Suhas

On Fri, Dec 5, 2014 at 7:01 AM, Christian Groves <
[email-masked]> wrote:

> used to signal the version and type of a SDP based IPBCP message. It's used
> in a BICC (ITU-T Q.1901) environment limited to a single media payload. The
> use of IPBCP messages for multiplexed transport would require updates to
> several Q.19xx series Recommendations.
>

[Suhas]  I am not an expert in this area and from limited reading of the
the ITU Spec it felt like ipbcp is used just to signify IPBCP version
number (as pointed by you) and thus felt as far as multiplexing is
concerned , the category NORMAL for this attributes makes sense. Given the
single media payload restriction above, It seems SPECIAL category is more
appropriate and provides the implementors an option to consult the spec
before making multiplexing decisions.

I can update the draft to reflect the same.

> related heading, i.e. from "ITU-T-Rec.Q1970" to "ITU-T Q.1970".

[Suhas] Thanks, will update in the next version.

>
> 2) 5.48 ATM SDP - I still not quite sure about the criteria for assigning
> the mux category. The text indicates that "For all adaptation types (AAL1,
> AAL2 and AAL5), bearer connections may be bundled into a single media
> group" however the BUNDLE draft is only for nettypes IN and addresstypes
> "IP4" or "IP6". So I wouldn't assign mux category "NORMAL" because some
> extra work would be needed to define how BUNDLE would be used for the ATM
> SDP parameters.  If multiplexing was applied then would the attributes
> related to the underlying ATM bearer need to be identical i.e. attributes
> from 5.6.1/RFC3108? Given the age and that these are not IP related, i'd be
> inclined to mark them all as NOT RECOMMENDED.
>

[Suhas] The notes associated with the section 5.48 in this draft was added
to mention that RFC3018 doesn't address cases where ATM serves as a
low-level transport pipe for IP packets which in turn might carry
multiplexed media streams.  I am open to move it to NOT RECOMMENDED given
your analysis.

>
> 3) 5.56 H.248.15 - FYI there's some work underway in the ITU-T SG16 on the
> support of multiplexing based on BUNDLE in H.248.STGROUP (
> http://wftp3.itu.int/av-arch/avc-site/2013-2016/1411_Seo/TD-14.zip).
>
> Regards, Christian
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 08 Dec 2014 20:09:55 -0500

On 12/8/14, 7:23 AM, Suhas Nandakumar wrote:
>    Also,  a question to chairs,  should I produce a newer version of 
> the document to reflect the changes below or wait till we end the last 
> call.
>
Unless anybody in the WG disagrees with the proposed changes you might 
as well incorporate them at this point.

Thanks

-- Flemming

> Please advice.
>
> Thanks
> Suhas
>
> On Fri, Dec 5, 2014 at 7:01 AM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello Suhas,
>
>     A few comments:
>
>     Recommended" or "Special" would probably be more appropriate.
>     a=ipbcp is used to signal the version and type of a SDP based
>     IPBCP message. It's used in a BICC (ITU-T Q.1901) environment
>     limited to a single media payload. The use of IPBCP messages for
>     multiplexed transport would require updates to several Q.19xx
>     series Recommendations.
>
> [Suhas]  I am not an expert in this area and from limited reading of 
> the the ITU Spec it felt like ipbcp is used just to signify IPBCP 
> version number (as pointed by you) and thus felt as far as 
> multiplexing is concerned , the category NORMAL for this attributes 
> makes sense. Given the single media payload restriction above, It 
> seems SPECIAL category is more appropriate and provides the 
> implementors an option to consult the spec before making multiplexing 
> decisions.
>
>     Also the heading title should be changed to align with the other
>     ITU-T related heading, i.e. from "ITU-T-Rec.Q1970" to "ITU-T Q.1970".
>
>     assigning the mux category. The text indicates that "For all
>     adaptation types (AAL1, AAL2 and AAL5), bearer connections may be
>     bundled into a single media group" however the BUNDLE draft is
>     only for nettypes IN and addresstypes "IP4" or "IP6". So I
>     wouldn't assign mux category "NORMAL" because some extra work
>     would be needed to define how BUNDLE would be used for the ATM SDP
>     parameters.  If multiplexing was applied then would the attributes
>     related to the underlying ATM bearer need to be identical i.e.
>     attributes from 5.6.1/RFC3108? Given the age and that these are
>     not IP related, i'd be inclined to mark them all as NOT RECOMMENDED.
>
>
> [Suhas] The notes associated with the section 5.48 in this draft was 
> added to mention that RFC3018 doesn't address cases where ATM serves 
> as a low-level transport pipe for IP packets which in turn might carry 
> multiplexed media streams.  I am open to move it to NOT RECOMMENDED 
> given your analysis.
>
>
>     3) 5.56 H.248.15 - FYI there's some work underway in the ITU-T
>     SG16 on the support of multiplexing based on BUNDLE in
>     H.248.STGROUP
>     On 27/11/2014 1:02 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>
>           This draft is a work item of the Multiparty Multimedia
>         Session Control Working Group of the IETF.
>
>                 Filename        :
>         draft-ietf-mmusic-sdp-mux-attributes-05.txt
>                 Pages           : 88
>                 Date            : 2014-11-26
>
>         Abstract:
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>