Re: [MMUSIC] Review Request- draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5939 Related)
Flemming Andreasen <fandreas@cisco.com> Mon, 15 July 2013 05:29 UTC
Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34E221F9C4F for <mmusic@ietfa.amsl.com>; Sun, 14 Jul 2013 22:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.654
X-Spam-Level:
X-Spam-Status: No, score=-9.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXCob0OhY+Fe for <mmusic@ietfa.amsl.com>; Sun, 14 Jul 2013 22:29:07 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 16B3121F9ABB for <mmusic@ietf.org>; Sun, 14 Jul 2013 22:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7066; q=dns/txt; s=iport; t=1373866147; x=1375075747; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2Y6g+Nbf4v84/jAbiY+xLZ/mtBP+5A7NHoICVge4HE0=; b=W7cv0Qz5Xlmw9R0Q54IgU7AfBIdruOk/kIgegHWinwSUXxWeldPwP94i DXLp/oNbE8pRtoJxwYXt3LAc1+dOQu+4PG0szCIrmT0VhE4oTqVJ/A4AT BZv1Na3ZjRWjIETiT0zlr28Wsim981RFVW4lWBypu1s2d74MuaLL+HRe6 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtAjAGmI41GtJXHB/2dsb2JhbABaJoJgNIkypGoClACBDhZ0giMBAQEBA3gBEAsYCRYPCQMCAQIBRQYNAQcBAYgMDLUtj2QHg3gDl1yBKZAkgVmBVSA
X-IronPort-AV: E=Sophos; i="4.89,667,1367971200"; d="scan'208,217"; a="234801388"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 05:29:02 +0000
Received: from Flemmings-MacBook-Pro.local (rtp-vpn4-549.cisco.com [10.82.210.37]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6F5Swb3016247; Mon, 15 Jul 2013 05:29:00 GMT
Message-ID: <51E34C6A.5020704@cisco.com>
Date: Sun, 14 Jul 2013 21:12:10 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Suhas Nandakumar <suhasietf@gmail.com>
References: <CAMRcRGTGDbHhXmJKYVph-xBE8AOViwXaaAhfmEFiyX91XwFiKA@mail.gmail.com>
In-Reply-To: <CAMRcRGTGDbHhXmJKYVph-xBE8AOViwXaaAhfmEFiyX91XwFiKA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020306050508010102050601"
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Review Request- draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5939 Related)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 05:29:11 -0000
Section 5.28 defines the following attributes with the category shown in brackets: a=pcfg (SPECIAL) a=acfg (SPECIAL) a=csup (SPECIAL) a=creq (SPECIAL) a=acap (SPECIAL) a=tcap (IDENTICAL) I think the definition of "SPECIAL" needs to be changed and maybe we need two versions of it: A "SPECIAL" for existing attributes, in which case the mux-attributes draft will have to define the handling that is needed, and a "SPECIAL NEW", which would essentially impose a new requirement on all new SDP attribute definitions to have one of the mux-attribute categories assigned to them, and if it's "SPECIAL NEW", then define the handling with muxing. Moving on to the categories suggested above: On the "tcap" one, it's debatable whether they need to be "IDENTICAL" since they are purely capabilities and as such not being used at this point in time; the "pcfg" atttribute is what would instantiate their use. Also, repeating the comment from the RFC 3407 attributes, we have an example of an attribute where there can be multiple different values (on purpose) and they are all equally valid. In this case, the negotiation process would end up picking one of them, and what you probably want for mux-attributes is the negotiation process to pick the same one for all the multiplexed m-lines; this seems well suited for a "SPECIAL" description (there are probably several other nuances to be covered). Similar considerations apply for "acap". For the "csup" and "creq" ones, I don't think there is anything "SPECIAL". They each list one or more option tags supported or required for capability negotiation to be used, and I believe they can just continue to do so when doing multi-plexing. In other words, I think "NORMAL" would be right for these. For "acfg" and "pcfg" I agree that further description on how they would be used with multiplexing would be needed (need to drive consistent negotiation across the multi-plexed m-lines). Thanks -- Flemming On 4/26/13 5:31 PM, Suhas Nandakumar wrote: > Hello Flemming > This is a request for reviewing the following sections > 5.28 > > of the draft > draft-nandakumar-mmusic-sdp-mux-attributes-02 > > It will be greatly appreciated if you could inform on your willingness > for reviewing the aforementioned sessions. > > It would be great to have your review feedback/comments/input before > June 9th 2013. > > The document is available here: > http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 > > > Thanks in Advance > > Regards > Suhas Nandakumar
- [MMUSIC] Review Request- draft-nandakumar-mmusic-… Suhas Nandakumar
- Re: [MMUSIC] Review Request- draft-nandakumar-mmu… Flemming Andreasen