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

[Brett Tate <[e-mail]>]

> >>> 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=[e-mail] (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
> >
> 
> Is not the last/second "recvonly" redundant?


Yes; although is simplifies the example.  The following example/description adjustment reflects a potential change to the session level attribute.

Within the following SDP example, the "inactive" attribute applies to audio media and the "recvonly" attribute applies to video media.

       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=[e-mail] (Jane Doe)
       c=IN IP4 233.252.0.1/127
       t=2873397496 2873404696
       a=inactive
       m=audio 49170 RTP/AVP 0
       m=video 51372 RTP/AVP 99
       a=rtpmap:99 h263-1998/90000
       a=recvonly