Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
"Ali C. Begen (abegen)" <abegen@cisco.com> Sun, 30 December 2012 00:45 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 50DE921F86A5 for <mmusic@ietfa.amsl.com>; Sat, 29 Dec 2012 16:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.363
X-Spam-Level:
X-Spam-Status: No, score=-9.363 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_BASE64_TEXT=1.753, 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 HyW0ykzPluyU for <mmusic@ietfa.amsl.com>; Sat, 29 Dec 2012 16:45:15 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1196321F8610 for <mmusic@ietf.org>; Sat, 29 Dec 2012 16:45:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11082; q=dns/txt; s=iport; t=1356828315; x=1358037915; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=twpNCIIkp8fxYJ1L7as60P/WcTFbCIT2TrVCMGG8uEE=; b=fZahgKyC8sSkC99IU4HO+Q1CjBsy7tJLPuDDV2rNLV/5XkL9UMqHbWli S2kI763d8mFoa/piUqqfvtJo7mgnu/w0PootM/NMfa7APs+l61i/7Uz+q ZZImsVlhB2GEZNzwKQWuVxkLhjYhQWEYxSU0V0rlpt43cS3DsjVD6LFtH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAJON31CtJXHB/2dsb2JhbAA6Cg6CXoNOtjJ0FnOCHgEBAQMBAQEBMTQGFwYBCA4DAwEBAQEEBh0FBCULFAkIAgQBEgiIBQYBC4snmm0GkFQEgRyLOwIPBYMUOGEDplSCNj6BaT0
X-IronPort-AV: E=Sophos;i="4.84,379,1355097600"; d="scan'208";a="157180964"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 30 Dec 2012 00:45:14 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBU0jEMQ008311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Dec 2012 00:45:14 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 18:45:13 -0600
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: AQHN5ibtjKlj+bwH1kq6U0T1+4e24g==
Date: Sun, 30 Dec 2012 00:45:13 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE9940CDE1948@xmb-aln-x01.cisco.com>
In-Reply-To: <50DF8C9A.5040603@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [10.86.245.254]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <87080664EB3F7A4F86FAC96A7020BD37@cisco.com>
Content-Transfer-Encoding: base64
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: Sun, 30 Dec 2012 00:45:16 -0000
-----Original Message----- From: Paul Kyzivat <pkyzivat@alum.mit.edu> Date: Saturday, December 29, 2012 7:36 PM To: "mmusic@ietf.org" <mmusic@ietf.org> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes >On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote: >> I don¹t remember us reaching a consensus regarding the text proposed by >> Brett. One thing certain is that we don't wanna break anything that >> complies with 4566 but we should also make the text as clear as >>possible. >> >> I am OK with Brett's suggestion as I don't recall an attribute like what >> Paul might have seen. But, even if such an attribute exists, the current >> text would be incorrect, too (This would indicate a problem with that >> particular attribute not 4566 or 4566bis). > >I found one: a=maxprate in RFC3890. Well, I still don't see a problem in replacing the current text with the proposed text. Do you? > > Thanks, > Paul > >> Brett's proposal does not make the text any worse. So, I am planning to >> incorporate this change. >> >> Any objections? >> >> -acbegen >> >> -----Original Message----- >> From: Paul Kyzivat <pkyzivat@alum.mit.edu> >> Date: Monday, August 27, 2012 12:03 PM >> To: "mmusic@ietf.org" <mmusic@ietf.org> >> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: >> session-level attributes >> >> >I've always thought this should be the way things work, for all >> >attributes. But somewhere I came across an attribute (sorry, don't >> >remember which one) where the attribute at session level means >>something >> >different than the attribute at media level, and so can't be treated >>as >> >a default for media level. (E.g. the session level is an aggregate >>limit >> >for something, while the media level is a limit for a single m-line.) >> > >> >Am I just dreaming this? Or can someone identify specific attributes >> >that behave this way? >> > >> >If there are existing attributes that behave this way, then we can't >> >make a blanket statement like this. There will need to be an escape >> >hatch. For example: >> > >> >"The connection ("c=") information in the >> > session-level section applies to all the media of that session unless >> > overridden by connection information >> > in the media description. For instance, in the example >> > below, TBD..." >> > >> >"The 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, or the specification of that >> > attribute calls for a different treatment. >> > 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." >> > >> >Even this could have some backward compatibility consequences. I think >> >there are some attributes that are only defined for media level. This >> >revision would mean that a session level value could override a >>default >> >for media level. Implementations that aren't prepared for that might >> >break. >> > >> > Thanks, >> > Paul >> > >> >On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: >> >> 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 >> >> >> >> _______________________________________________ >> >> mmusic mailing list >> >> mmusic@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> > >> >_______________________________________________ >> >mmusic mailing list >> >mmusic@ietf.org >> >https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session… Brett Tate
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Brett Tate
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Charles Eckel (eckelcu)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Miguel A. Garcia
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Miguel A. Garcia
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Flemming Andreasen
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Brett Tate
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Ali C. Begen (abegen)
- Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: ses… Paul Kyzivat