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