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