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

From: Flemming Andreasen <[email-masked]>
Date: Thu, 03 Jan 2013 18:01:51 -0500

We clearly need an escape hatch as there are several examples of 
attributes with a given name that may occur multiple times to provide 
different values by use of additional qualifiers inside the attribute, 
and some of those attributes may appear at both the session and media 
level (capability negotiation for example uses this approach, as does 
"rtpmap", "fmtp", etc. inside a media description). In fact, I'd argue 
it's more than an escape hatch and probably more of a "default rule" in 
the absence of anything else specified for the attribute.

In terms of the "choice" wording below, I think it's underspecified what 
that means, and I'm also not sure we really need a general rule here. Do 
we have other examples than the direction attributes currently ? If not 
(or we can't think of those), I'd rather just call those out explicitly.

Thanks

-- Flemming (as Individual)

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).
>
> 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 <[email-masked]>
> Date: Monday, August 27, 2012 12:03 PM
> To: "[email-masked]" <[email-masked]>
> 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:[email-masked]]
>>>> Sent: Wednesday, August 08, 2012 7:54 AM
>>>> To: Ali C. Begen (abegen); [email-masked]
>>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jan 2013 21:09:26 -0500

Once upon a time I thought that rule actually existed and worked, and 
that all attributes ought to have the "session is default for media 
level" property.

But then it became apparent that there were cases that didn't fit that rule.

When writing my last reply to this thread, and examining things more 
closely, it became apparent to me that this defaulting behavior doesn't 
work in many/most cases. The interesting cases that work something like 
that need to be described individually to cover the special cases that 
seem to apply almost all the time.

So I agree we are probably better off just not asserting it.

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.

	Thanks,
	Paul

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 4 Jan 2013 02:14:02 +0000

Hi Paul,

On Jan 3, 2013, at 9:09 PM, Paul Kyzivat <[email-masked]> wrote:

> Once upon a time I thought that rule actually existed and worked, and that all attributes ought to have the "session is default for media level" property.
> 
> When writing my last reply to this thread, and examining things more closely, it became apparent to me that this defaulting behavior doesn't work in many/most cases. The interesting cases that work something like that need to be described individually to cover the special cases that seem to apply almost all the time.
> 
Are you saying we don't change the text or remove it altogether?

> 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?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jan 2013 22:31:45 -0500

> 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=[email-masked] (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=[email-masked] (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.

> 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=[email-masked] (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