Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes

"Ali C. Begen (abegen)" <abegen@cisco.com> Mon, 27 August 2012 16:04 UTC

Return-Path: <abegen@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 DA97721F8551 for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 09:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x02qBybmPRu for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 09:04:54 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8021F854E for <mmusic@ietf.org>; Mon, 27 Aug 2012 09:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3618; q=dns/txt; s=iport; t=1346083494; x=1347293094; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1ATf48tbAYeyJuXvENALOY7OV2lN3FV79qgeti5tU7Y=; b=T+c53qmCMnwb1mLB+5kHo2hhgmp4uh7rCtIfPoQ3deFT4GSiDw6qYoX4 olP/Lzc+5aDagcwvj7+zqWDz49+coYgtFO92RnYQvK8ykSnerMORe6s03 ngQWu6dNp/Lpo12x0/M8w8t4BGydWQD/37xcM6erb9/r0fl/QE3nQF5Wu A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANSZO1CtJV2b/2dsb2JhbABFgm24C4EHgiABAQEEEgFVHQQCAQgRBAEBCx0HMhQJCAEBBBMIGodrAZoroAuLCAKGL2ADpAOBZ4Jj
X-IronPort-AV: E=Sophos;i="4.80,321,1344211200"; d="scan'208";a="115691071"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 27 Aug 2012 16:04:53 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7RG4r58023010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Mon, 27 Aug 2012 16:04:53 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 11:04:53 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: Ac1z5irXaxvG+6IYTyi3BKqjoBMk/ABMAh4wAA/knVADxe27oA==
Date: Mon, 27 Aug 2012 16:04:52 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local>
In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.254.150]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006
x-tm-as-result: No--56.604400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
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, 27 Aug 2012 16:04:55 -0000

Brett suggested the following change in the SDP draft. Any objections?

-acbegen

Current text:

"The connection ("c=") and attribute ("a=") information in the
 session-level section applies to all the media of that session unless
 overridden by connection information or an attribute of the same name
 in the media description.  For instance, in the example below, each
 media behaves as if it were given a "recvonly" attribute."

Proposed text:

"The connection ("c=") and attribute ("a=") information in the
 session-level section applies to all the media of that session unless
 overridden by connection information or an attribute of the same name
 or choice in the media description.  For instance, in the example 
 below, each media behaves as if it were given a "recvonly" attribute.
 If the example had additionally contained a "sendrecv" media-level
 attribute for audio, only the video media would behave as if it were 
 given a "recvonly" attribute."

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Wednesday, August 08, 2012 7:54 AM
> To: Ali C. Begen (abegen); mmusic@ietf.org
> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
> 
> > > Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the
> > > following.
> > >
> > > "In general, session-level values are the default for all
> > > media unless overridden by an equivalent media-level value."
> > >
> > > "The connection ("c=") and attribute ("a=") information
> > > in the session-level section applies to all the media of
> > > that session unless overridden by connection information
> > > or an attribute of the same name in the media description.
> > > For instance, in the example below, each media behaves
> > > as if it were given a "recvonly" attribute."
> > >
> > > If the attributes are related but with different names
> > > (such as "inactive" and "sendrecv"), does the attribute
> > > at the media-level have precedence over the value at the
> > > session-level?  If so, I recommend that the draft be
> > > updated to clarify the topic.
> >
> > I believe so. at least that is my understanding from the
> > text. Does it really need clarification? Thoughts?
> 
> I think that it should be clarified because it is unclear if "an attribute of the same name" indicates the typical situation or only
> situation concerning application of "unless overridden by an equivalent media-level value".  For instance if I sent "a=inactive"
> at session-level and "a=sendrecv" at media-level, I'd be concerned that the receiver may interpret the SDP as being
> abnormal (such as including both values at media-level) instead of allowing "a=sendrecv" to override "a=inactive".
> 
> In case it matters from an extendibility perspective, requiring the same name might make it easier to recognize the override.
> However since section 6 already introduces complications with defaulting to "sendrecv" if a new option is defined/used and
> unknown, allowing the override even when the names are not the same doesn't make things too much worse; it actually
> allows communication of a backup attribute (such as "a=inactive") if they don't understand the preferred new attribute (such
> as "a=foo").
> 
> "If none of the attributes "sendonly", "recvonly", "inactive",
> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
> default for sessions that are not of the conference type
> "broadcast" or "H332" (see below)."
> 
> Thanks for the response,
> Brett