Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 04 January 2013 03:31 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 50C3921F8CE8 for <mmusic@ietfa.amsl.com>; Thu, 3 Jan 2013 19:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.496
X-Spam-Level: *
X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1]
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 3Hj57joxvoZY for <mmusic@ietfa.amsl.com>; Thu, 3 Jan 2013 19:31:47 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 421AE21F882E for <mmusic@ietf.org>; Thu, 3 Jan 2013 19:31:47 -0800 (PST)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id jdEP1k00217dt5G54fXmYw; Fri, 04 Jan 2013 03:31:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id jfXm1k0043ZTu2S3ZfXmDF; Fri, 04 Jan 2013 03:31:46 +0000
Message-ID: <50E64D21.2030609@alum.mit.edu>
Date: Thu, 03 Jan 2013 22:31:45 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
References: <C15918F2FCDA0243A7C919DA7C4BE9940CDE1808@xmb-aln-x01.cisco.com> <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <C15918F2FCDA0243A7C919DA7C4BE9940CDFB627@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940CDFB627@xmb-aln-x01.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357270306; bh=4yywNTlR34MNT2snKEybxOc6aa811Kgd2ButINTR92A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XffYOBfB43qY6W8NN1LhcgH7xgtsdTD9htaonvEdHxxVo4xD8/VlzcfI7iKLXfogr IInIZo3FSf8J0zFP2fNf6SBMQ9KCnt+MwVayDAXigS694/8LA2fI3lxRA01+5zJLTL 9Duynt5FT7XIl6i21j0yvXPDHr7rb6wTeKhxXd9rKfb3lYKoHnWKCwCopqGmu34aiF xMC07tMZRm78NHNhqPeXY9iKSt61l3v/eC4oScWZtsxFGQVWihvSgPtxU+L6kGlTQW syQTXQ0PHywVrFCAzVM8tWbIsAi9jrjrXSUDqIT1XbEQ2r+r5g5WLMXhL3LlOmhPpP dv/g4rYGfzHbA==
Cc: "Flemming Andreasen (fandreas)" <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
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: Fri, 04 Jan 2013 03:31:48 -0000
On 1/3/13 9:14 PM, Ali C. Begen (abegen) wrote: > Are you saying we don't change the text or remove it altogether? Major change. OLD: 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. An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 NEW: 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, each audio media behaves as if it were given a "c=IN IP4 192.0.2.3". An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 192.0.2.3 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 c=IN IP4 233.252.0.1/127 a=rtpmap:99 h263-1998/90000 This drops all discussion of attributes and just describes the behavior for c-lines. >> And at the same time we should polish up the definitions of the attributes defined in this document so that they are very clear how session and media level interact. > > Could you provide an example of what you have in mind? I'll try. (But please review this carefully!) In section 6: OLD: a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset. 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). a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset. NEW: a=recvonly, a=sendrecv, a=sendonly, a=inactive At most one of recvonly/sendrecv/sendonly/inactive MAY appear at session level, and at most one MAY appear in each media section. If any one of these appears in a media section then it applies for that media section. If none appear in a media section then the one from session level, if any, applies to that media section. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present at either session level or media level, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below). For instance, in the example below, each media behaves as if it were given a "recvonly" attribute. An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=recvonly a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset. a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset. Also in section 6: OLD: a=sdplang:<language tag> This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media. Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. NEW: a=sdplang:<language tag> This can be a session-level attribute or a media-level attribute. Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media, overriding any sdplang attributes specified at session-level. OLD: a=lang:<language tag> This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the default language for the session being described. As a media- level attribute, it specifies the language for that media, overriding any session-level language specified. Multiple lang attributes can be provided either at session or media level if the session or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important. NEW: a=lang:<language tag> This can be a session-level attribute or a media-level attribute. Multiple lang attributes can be provided either at session or media level if the session or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important. As a session-level attribute, it specifies the default language for the session being described. As a media-level attribute, it specifies the language for that media, overriding any session-level languages specified. That's all. Thanks, Paul
- [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