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

From: [email-masked]
Date: Mon, 04 Jan 2016 16:33:35 -0800

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-11.txt
	Pages           : 96
	Date            : 2016-01-04

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.  Typically media associated with individual media
   descriptions ("m=" lines) represent RTP sessions and are thus carried
   over individual underlying transport layer flows.  For scenarios
   where SDP is used to negotiate the usage of single 5-tuple for
   sending and receiving media associated with multiple media
   descriptions, it is required to understand the semantic implications
   of the SDP attributes associated with the RTP Media Streams
   multiplexed over a single underlying transport layer flow.

   The purpose 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:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-11

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/

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 4 Jan 2016 16:39:41 -0800

Hello All

  This version incorporates comments from Bo Burman (Thanks Bo for the
review)

  However, there was one comment that isn't addressed and would love to
hear Chairs/WG inputs on the same

  "The current table ends with “calgextmap”, but the IANA table continues
with “phone-context”, “clir”, “Q763-nature”, “Q763-plan”, “Q763-INN”,
“require”, “record”, and “recordpref”, some of which refer quite old RFCs.
Why are those not included in the table?"

  [Suhas] : These attributes appeared in IANA after we froze assigning
categories. Thus as of now, if the MUX draft gets published, these
attributes gets the mux category of TBD.

Please let me know your thoughts

Cheers
Suhas

On Mon, Jan 4, 2016 at 4:33 PM, <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 6 Jan 2016 09:56:18 +1100

Hello Suhas,

My recollection is that RFC2848 which defines the attributes doesn't 
actually result in an RTP media flow. PINT uses SIP/SDP to trigger a 
gateway to do something on the GSTN side. Basically its use with 
multiplexing should be "Not Recommended". As the draft text already says 
that for "TBD" implementations should treat it as "not recommended", its 
probably OK to label the attributes as TBD.

Regards, Christian

On 5/01/2016 11:39 AM, Suhas Nandakumar wrote:
>   However, there was one comment that isn't addressed and would love 
> to hear Chairs/WG inputs on the same
>
> "The current table ends with “calgextmap”, but the IANA table 
> continues with “phone-context”, “clir”, “Q763-nature”, “Q763-plan”, 
> “Q763-INN”, “require”, “record”, and “recordpref”, some of which refer 
> quite old RFCs. Why are those not included in the table?"
>
> On Mon, Jan 4, 2016 at 4:33 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 5 Jan 2016 15:40:10 -0800

Thanks Christian for checking on this.

Also regarding the updates to the document, I was thinking of not adding
these attributes to the draft. Since the IANA section says, for all the
attributes in the IANA registry that doesn't has the category assigned by
the MUX draft, IANA should assign the category as TBD.

please let me know if this works as well

Cheers
Suhas

On Tue, Jan 5, 2016 at 2:56 PM, Christian Groves <
[email-masked]> wrote:

>> On Mon, Jan 4, 2016 at 4:33 PM, <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>

---

From: Bo Burman <[email-masked]>
Date: Thu, 14 Jan 2016 16:05:01 +0000

Unless there are objections or further comments from the group, I conclude that no document changes are required on this topic.

/Bo
MMUSIC co-chair

From: mmusic [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: den 6 januari 2016 00:40
To: Christian Groves
Cc: mmusic WG
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt

Also regarding the updates to the document, I was thinking of not adding these attributes to the draft. Since the IANA section says, for all the attributes in the IANA registry that doesn't has the category assigned by the MUX draft, IANA should assign the category as TBD.

Cheers
Suhas

On Tue, Jan 5, 2016 at 2:56 PM, Christian Groves <[email-masked]<mailto:[email-masked]>> wrote:
Hello Suhas,

My recollection is that RFC2848 which defines the attributes doesn't actually result in an RTP media flow. PINT uses SIP/SDP to trigger a gateway to do something on the GSTN side. Basically its use with multiplexing should be "Not Recommended". As the draft text already says that for "TBD" implementations should treat it as "not recommended", its probably OK to label the attributes as TBD.

Regards, Christian

  This version incorporates comments from Bo Burman (Thanks Bo for the review)

  However, there was one comment that isn't addressed and would love to hear Chairs/WG inputs on the same

"The current table ends with “calgextmap”, but the IANA table continues with “phone-context”, “clir”, “Q763-nature”, “Q763-plan”, “Q763-INN”, “require”, “record”, and “recordpref”, some of which refer quite old RFCs. Why are those not included in the table?"

[Suhas] : These attributes appeared in IANA after we froze assigning categories. Thus as of now, if the MUX draft gets published, these attributes gets the mux category of TBD.
Please let me know your thoughts

Cheers
Suhas
On Mon, Jan 4, 2016 at 4:33 PM, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[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-11.txt
            Pages           : 96
            Date            : 2016-01-04

    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.  Typically media associated with individual
    media
       descriptions ("m=" lines) represent RTP sessions and are thus
    carried
       over individual underlying transport layer flows.  For scenarios
       where SDP is used to negotiate the usage of single 5-tuple for
       sending and receiving media associated with multiple media
       descriptions, it is required to understand the semantic
    implications
       of the SDP attributes associated with the RTP Media Streams
       multiplexed over a single underlying transport layer flow.

    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<http://tools.ietf.org> <http://tools.ietf.org>.

    _______________________________________________
    mmusic mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic