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

From: Brett Tate <[email-masked]>
Date: Mon, 6 Aug 2012 08:14:26 -0700

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.

Thanks,
Brett

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information.  If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, or by sending an email to [email-masked], and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 8 Aug 2012 03:32:56 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: Monday, August 06, 2012 11:14 AM
> To: [email-masked]
> Subject: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
> 
> 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?

-acbegen

> Thanks,
> Brett
> 
> 
> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged
> information.  If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc.
> immediately by replying to this message, or by sending an email to [email-masked], and destroy all copies of this
> message, along with any attachment, prior to reading, distributing or copying it.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Brett Tate <[email-masked]>
Date: Wed, 8 Aug 2012 04:53:41 -0700

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 10 Aug 2012 16:27:16 +0000

Yes, I agree that is the intent of the existing wording. Adding an example for the specific example you provided would help make this even more clear.

Cheers,
Charles

> Sent: Monday, August 06, 2012 8:14 AM
> To: [email-masked]
> 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.
> 
> Thanks,
> Brett
> 
> 
> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information.  If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, or by
> sending an email to [email-masked], and destroy all copies of this

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 27 Aug 2012 16:04:52 +0000

Brett suggested the following change in the SDP draft. Any objections?

-acbegen

Current text:

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."

> 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
> 
> 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").
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Aug 2012 13:03:57 -0400

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 28 Aug 2012 10:40:57 +0200

Hi Paul,

perhaps you are thinking of the Bandwidth modifier for SDP, RFC 3890. 
Section 6.2.2. says:

    A new session and media level bandwidth modifier is defined:

       b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.

    The Transport Independent Application Specific Maximum (TIAS)
    bandwidth modifier has an integer bit-rate value in bits per second.
    A fractional bandwidth value SHALL always be rounded up to the next
    integer.  The bandwidth value is the maximum needed by the
    application (SDP session level) or media stream (SDP media level)
    without counting IP or other transport layers like TCP or UDP.

    At the SDP session level, the TIAS value is the maximal amount of
    bandwidth needed when all declared media streams are used.  This MAY
    be less than the sum of all the individual media streams values.
    This is due to the possibility that not all streams have their
    maximum at the same point in time.  This can normally only be
    verified for stored media streams.

Is this the example you were looking for?

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 28 Aug 2012 10:43:11 +0200

Resent. I wanted to include Ali in the discussion, but I failed at first 
time.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Aug 2012 09:12:52 -0400

While bandwidth has that property, it's not an *attribute*.
I was thinking that there is at least one attribute like that.
But I don't recall a specific one. :-(
It would be good if I'm wrong.

	Thanks,
	Paul