Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - The rest from Magnus

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Mar 2015 13:11:59 +0000

Hi Magnus,

Thanks for your comments! I am sorry that I forgot to address them earlier. See inline.
 
------------

1. Section 2:

>"Offerer BUNDLE address: Within a given BUNDLE group, an IP address
>   and port combination used by an offerer to receive all media
>   associated with each "m=" line within the BUNDLE group."
>
> I wonder if this needs to discuss the protocol, or that is fine to assume?

I don't think that belongs here. The definition is only about the IP address and port combination.

------------

2. Section 2:

>   Initial offer: The first offer, within an SDP session, in which the
>   offerer indicates that it wants to create a given BUNDLE group.
>
> I don't think SDP session is well established term. I assume you mean the set of O/A exchanges that can occur for example within the context of SIP Dialog.

Yes.

But, BUNDLE is not SIP specific, so I don't think we can say SIP Dialog - except as an example.

------------

3. Section 4:

> I wonder if one needs to be explicit about that Declarative SDP usage of BUNDLE is not defined, but may be defined in the future?

I don't think we need to talk about the future, but I am happy to say that something is outside the scope of the document.

Do you have a text suggestion?

------------

4. section 5.1:

> Is the 5.1 heading really needed?

I can remove it. Perhaps there were more 5.x subsections in the past.

------------

5. section 5.1:

>   All media associated with a BUNDLE group share a single 5-tuple, i.e.
>   in addition to using a single address:port combination all bundled
>   media MUST be transported using the same transport-layer protocol.
>
> The definition here of "transport-layer" needs to be clarified. I assumed it meant transport protocol, e.g. UDP or TCP, not limited to a single PROTO ID.

There were talks about adding a definition for "transport-layer protocol", but perhaps we could simply say "same transport-layer protocol (e.g. UDP or TCP)"?

------------

6. Section 6.2:

> Section title: bundle-only
>
> Shouldn't this more like: "Definition of bundle-only"

Alternatively I could remove the 6.1 and 6.2 subsections, and keep all text within section 6.

------------

7. Section 7.2:

>   The "c=" line nettype value [RFC4566] associated with a bundled "m="
>   line MUST be 'IN'.
>
>   The "c=" line addrtype value [RFC4566] associated with a bundled "m="
>   line MUST be 'IP4' or 'IP6'.  The same value MUST be associated with
>   each "m=" line.
>
> I have to wonder over this limitation of the possible address spaces.
> Why is it necessary?

Perhaps IPv8 will use a completely different structure, which does not fit with the "IP address + combination"- and "5-tuple" terminology used in the document.

------------

8. Section 7.3:

>   The total proposed bandwidth for a BUNDLE group is the sum of the
>   proposed bandwidth for each bundled "m=" line.
>
> I don't think the above is appropriate for CT.
>
> In addition it is going to look a bit strange for RR and RS which after all gives the value that is to be used in the RTP session. However, I can
> understand the desire to scale RR and RS depending on which media source that are accepted or rejected in the session, thus per media source additions is 
> not totally illogical.

So, what do you suggest? :)

------------

9. Section 8.1:

>   The procedures in this section are independent of the media type or
>   transport protocol represented by a bundled "m=" line.
>
> Which "transport protocol" is implied here, what the PROTO indicates or the transport layer protocol, e.g. UDP?

The PROTO value.

So, perhaps I could say:

	"The procedures in this section are independent of the media type or
	PROTO value associated with a bundled "m=" line."

------------

10. Section 8.2.1:

>   o  Assign a unique address to each "m=" line within the offer,
>      following the procedures in [RFC3264];
>
>   o  Assign a unique address to each "m=" line within the offer,
>      following the procedures in [RFC3264];
>
> Copy paste error?

Yes. I'll remove one instance.

------------

11. Section 8.2.1:

>   o  Assign a unique address to each "m=" line within the offer,
>      following the procedures in [RFC3264];
>
> I note that setting port 0 does not result in unique addresses, thus should have an exception.

Perhaps that could be added to the "unique address" definition in Section 2.

OLD:

	"Unique address: An IP address and port combination that is assigned
   	to only one "m=" line in an offer or answer."

NEW:

	"Unique address: An IP address and port combination that is assigned
   	to only one "m=" line in an offer or answer. Note that, in case of a
                             zero port value, the same IP address and combination might be 
                             assigned to multiple "m=" lines."

------------

12. Section 8.5.1:

>   In addition, the offerer MUST select an offerer BUNDLE-tag
>   [Section 8.2.2], even if the offerer does not suggest a new offerer
>   BUNDLE address.
>
> I don't understand what the above means. As long as one has a bundle group the MIDs of the m= blocks needs to 
>be included. If all use the shared address, then it doesn't matter which is first. If they are not, then the order matters. However, 
>without terminating the bundle group you can't avoid selecting a new offerer BUNDLE address.

You are right that it doesn't matter, but SOME mid value has to be first in the attribute list.

------------

13. Section 8.5.2:

>   o  Assign the address (shared address) to each "m=" line within the
>      BUNDLE group; or
>
>   o  Assign the address (unique address) to one bundled "m=" line.
>
> This appears to have implications. The later choice forces another round with a BAS offer. Anything else that it implies?

None that I can think of. As the note says, it does give the offerer a possibility to offer multiple new addresses.

------------

14. Section 8.5.3:

>   When an offerer generates an offer, in which it wants to add a
>   bundled "m=" line to a BUNDLE group, the offerer MUST:
>
>   o  Assign a unique address to the "m=" line;
>
>   o  Assign the previously selected offerer BUNDLE address to the "m="
>      line; or
>
>   o  If the offerer assigns a new suggested offerer BUNDLE address to
>      each bundled "m=" line [Section 8.5.2], also assign that address
>      to the added "m=" line.
>
> I think there has been restructuring in this bullet list that moved, I assume there should be an or between all of these bullets.

There is an implicit "or" between all bullets. I do the same way in other places, e.g. in sections 8.2.1 and 8.3.2, where "and" is only explicitly stated after the second last bullet.

------------

15. Section 8.5.3:

>   o  If the offerer assigns a new suggested offerer BUNDLE address to
>      each bundled "m=" line [Section 8.5.2], also assign that address
>      to the added "m=" line.
>
> I assume there is a missing "shared" in the first line of the bullet, otherwise the same address would not be added to the new m=.

The text does say that the address is added to each bundled "m=" line.

But, I guess I could say: "a new (shared address) suggested offerer..."

------------

16. Section 10.1.1:

>   o  An SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp-
>      hdrext:sdes:mid' URI value, MUST, in every offer and answer, be
>      associated with each bundled "m=" line representing RTP-based
>      media.
>
> Considering that this concerns an RTP session, I think a more appropriate way of writing this would be:
>
>   o  MUST enable the RTP MID  header extension by associating with
>      each bundled "m=" line representing RTP-based media an SDP 'extmap'
>      attribute [RFC5285], with a 'urn:ietf:params:rtp-
>      hdrext:sdes:mid' URI value, in every offer and answer.

Works for me.

------------

17. Section 10.2:

>   An offerer and answerer can in an offer and answer inform each other
>   which SSRC values they will use inside sent RTP/RTCP packets, by
>   associating an SDP 'ssrc' attribute [RFC5576] with each bundled "m="
>   line which contains a payload type value that is also used inside
>   another bundled "m=" line.
>
> I note that the SSRCs associated with an m= line may be multiple. The obvious example is SSRC multiplexed RTP retransmission.

Are you suggesting to say "associating one or more SDP 'ssrc' attributes..."?

------------

18. Section 10.3.2.3 and 12.2

> Section 10.3.2.3 says:
>
> The answerer
>   MUST, based on the port number of the selected offerer BUNDLE
>   address, use the next higher (odd) destination port number [RFC3550]
>   for sending RTCP packets associated with each bundled RTP-based "m="
>   line towards the offerer.
>
> Section 12.2 and 12.3
>
>   Unless there is an explicit indication otherwise, reports are sent to
>   the port number one higher than the number indicated.
>
> I note that RFC 3264 is actually not ensuring consistency with the base rules for RTCP port assignment. If the m= line port is odd, the two text here would result in different port numbers.
>
> However, with the likely changes in 10.3.2.3 I guess we need to stay with the rules according to RFC 3264 for implicit RTCP port.

Based on the e-mail discussions, I removed "(odd)" from BUNDLE-17.

------------

19. Section 13.3:

>   The identification-tag is not zero terminated.  Note, however, that
>   RTP header extensions that are not a multiple of 32 bits in length
>   MUST be padded to the next 32-bit boundary using zero bytes; these
>   padding bytes are not included in the header length field [RFC3550].
>
> Actually the relevant reference regarding padding of header extension that uses RFC 5285 is RFC 5285 as the padding is applied after having added all the header extensions, not on per header extension basis.

So, do you suggest to change the reference from 3550 to 5285?

------------

20. Section 13.3:

> I think there should be some considerations for the mid tags.
> Considering that they are included in the RTP header extension as well in the RTCP SDES packets, their size suddenly matters much 
> more than before. I think we really should recommend single or at least no more than 3 character tags to ensure that they take 
> minimal room in the header. In fact a short header extension with a string consuming no more than 3 octets will result in only 
> two 32-bit words being added to the RTP header.

Please suggest some text :)

------------

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Mar 2015 11:50:51 +0100

WG,

This email contains a couple of text suggestions, as well as proposal
that would really benefit from feedback, see issue 8.

On 2015-03-04 14:11, Christer Holmberg wrote:
>> "Offerer BUNDLE address: Within a given BUNDLE group, an IP
>> address and port combination used by an offerer to receive all
>> media associated with each "m=" line within the BUNDLE group."
>> 

Ok, I wont push this, but in reality the bundle address is scoped by the
protocol being used.

> 
> ------------
> 
> 2. Section 2:
> 
>> Initial offer: The first offer, within an SDP session, in which
>> the offerer indicates that it wants to create a given BUNDLE
>> group.
>> 
>> I don't think SDP session is well established term. I assume you
>> mean the set of O/A exchanges that can occur for example within the
>> context of SIP Dialog.
> 
> Yes.
> 

The SIP Dialog is clearly an example, just to be certain that I had
correctly understood what was meant. The easy fix, is to exemplify the
word with SIP Dialog.

> 
> ------------
> 
> 3. Section 4:
> 
>> I wonder if one needs to be explicit about that Declarative SDP
>> usage of BUNDLE is not defined, but may be defined in the future?
> 
> I don't think we need to talk about the future, but I am happy to say
> that something is outside the scope of the document.
> 

I really think we should be clear that the current document do not
define Declarative usage. I expect that soon someone will like to use
BUNDLE in a declarative environment and they will have some questions to
answer, thus one can't assume this simply will work.

OLD:
4.  Applicability Statement

   The mechanism in this specification only applies to the Session
   Description Protocol (SDP) [RFC4566], when used together with the SDP
   offer/answer mechanism [RFC3264].

NEW:

4.  Applicability Statement

   The mechanism in this specification only applies to the Session
   Description Protocol (SDP) [RFC4566], when used together with the SDP
   offer/answer mechanism [RFC3264]. Declarative usage of SDP was
   decided out of scope for this document, and such usage is thus
   undefined.

>> All media associated with a BUNDLE group share a single 5-tuple,
>> i.e. in addition to using a single address:port combination all
>> bundled media MUST be transported using the same transport-layer
>> protocol.
>> 
>> The definition here of "transport-layer" needs to be clarified. I
>> assumed it meant transport protocol, e.g. UDP or TCP, not limited
>> to a single PROTO ID.
> 
> There were talks about adding a definition for "transport-layer
> protocol", but perhaps we could simply say "same transport-layer
> protocol (e.g. UDP or TCP)"?

Yes, I think that works.

The later is likely more appropriate considering that the text in 6.1
fits nicely as introduction to a common section.

> 
> ------------
> 
> 7. Section 7.2:
> 
>> The "c=" line nettype value [RFC4566] associated with a bundled
>> "m=" line MUST be 'IN'.
>> 
>> The "c=" line addrtype value [RFC4566] associated with a bundled
>> "m=" line MUST be 'IP4' or 'IP6'.  The same value MUST be
>> associated with each "m=" line.
>> 
>> I have to wonder over this limitation of the possible address
>> spaces. Why is it necessary?
> 
> Perhaps IPv8 will use a completely different structure, which does
> not fit with the "IP address + combination"- and "5-tuple"
> terminology used in the document.

Ok, I am fine with leaving it in place. A new IP version would anyway
require us to review a lot of things before being able to start using
it. The potential issue with writing as in the draft is that if IP8
would actually be straightforward and work, you still will have to
revise this specification.

>> In addition it is going to look a bit strange for RR and RS which
>> after all gives the value that is to be used in the RTP session.
>> However, I can understand the desire to scale RR and RS depending
>> on which media source that are accepted or rejected in the session,
>> thus per media source additions is not totally illogical.
> 

This is a bit tricky, but if one looks as the definition of CT I would
say that b=CT: in an media line should be the bundle total as offered or
answered.

What becomes uncertain for me is if CT at all is appropriate to use on
media level, or if it really should only occur on SDP session level.
But, I can see that CT on session level gives total over all in the SDP,
while CT on a media line would be across the full scope of m= lines that
a bundle covers.

But, having thought abit more about RR and RS I think summing them
appear appropriate.

I hope that more people will provide input into this.

> 
> ------------
> 
> 9. Section 8.1:
> 
>> The procedures in this section are independent of the media type
>> or transport protocol represented by a bundled "m=" line.
>> 
>> Which "transport protocol" is implied here, what the PROTO
>> indicates or the transport layer protocol, e.g. UDP?
> 
> The PROTO value.
> 
> So, perhaps I could say:
> 

I think that is a bit unclear, I think it should be writen like this:

"The procedures in this section are independent of the media type or
  m= line transport protocol <proto> value associated with a
 bundled media description."

No, I think you have to explicit that it is either a unique address or
the rejected/only if bundled address information. Thus, I think the
bullet can read:

o  Assign a unique address to each "m=" line within the offer,
   following the procedures in [RFC3264], unless the media line is a
   'bundle-only' "m=" line (see below);

> ------------
> 
> 12. Section 8.5.1:
> 
>> In addition, the offerer MUST select an offerer BUNDLE-tag [Section
>> 8.2.2], even if the offerer does not suggest a new offerer BUNDLE
>> address.
>> 
>> I don't understand what the above means. As long as one has a
>> bundle group the MIDs of the m= blocks needs to be included. If all
>> use the shared address, then it doesn't matter which is first. If
>> they are not, then the order matters. However, without terminating
>> the bundle group you can't avoid selecting a new offerer BUNDLE
>> address.
> 

Yes, but can we write this in a way that is less confusing.

OLD:

NEW:

   The BUNDLE-tag used MUST remain the same in the offer unless any of
   the above exceptions occur, in which case the Offerer selects a new
   BUNDLE-tag indicating the chosen BUNDLE address [Section 8.2.2].

What could be further clarified is that for the cases where the BUNDLE
address is not changed, but the m= line that the BUNDLE-tag pointed to
no longer is part of the bundle, then one picks any of the other
existing tags for m= lines that carries the bundle address.

> 
> ------------
> 
> 13. Section 8.5.2:
> 
>> o  Assign the address (shared address) to each "m=" line within
>> the BUNDLE group; or
>> 
>> This appears to have implications. The later choice forces another
>> round with a BAS offer. Anything else that it implies?
> 
> None that I can think of. As the note says, it does give the offerer
> a possibility to offer multiple new addresses.

Okay, am I correct to assume that people will understand that the letar
implies the need for a BAS?

>> o  Assign the previously selected offerer BUNDLE address to the
>> "m=" line; or
>> 
>> o  If the offerer assigns a new suggested offerer BUNDLE address
>> to each bundled "m=" line [Section 8.5.2], also assign that
>> address to the added "m=" line.
>> 
>> I think there has been restructuring in this bullet list that
>> moved, I assume there should be an or between all of these
>> bullets.
> 
> There is an implicit "or" between all bullets. I do the same way in
> other places, e.g. in sections 8.2.1 and 8.3.2, where "and" is only
> explicitly stated after the second last bullet.

I find this confusing because it not consistent, some bullet lists has
the "or" or "and" on the first line, some on the second. If they are no
different, then please use the or/and consistently in the lists.

> 
> ------------
> 
> 15. Section 8.5.3:
> 
>> o  If the offerer assigns a new suggested offerer BUNDLE address
>> to each bundled "m=" line [Section 8.5.2], also assign that
>> address to the added "m=" line.
>> 
>> I assume there is a missing "shared" in the first line of the
>> bullet, otherwise the same address would not be added to the new
>> m=.
> 

I think that is appropriate to make clear that this really is shared
case, compared to the first case of unique address and the second of
adding it to an existing bundle address.

> 
> ------------
> 
> 16. Section 10.1.1:
> 
>> o  An SDP 'extmap' attribute [RFC5285], with a
>> 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, MUST, in every
>> offer and answer, be associated with each bundled "m=" line
>> representing RTP-based media.
>> 
>> Considering that this concerns an RTP session, I think a more
>> appropriate way of writing this would be:
>> 
>> each bundled "m=" line representing RTP-based media an SDP
>> 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- 
>> An offerer and answerer can in an offer and answer inform each
>> other which SSRC values they will use inside sent RTP/RTCP packets,
>> by associating an SDP 'ssrc' attribute [RFC5576] with each bundled
>> "m=" line which contains a payload type value that is also used
>> inside another bundled "m=" line.
>> 
>> I note that the SSRCs associated with an m= line may be multiple.
>> The obvious example is SSRC multiplexed RTP retransmission.
> 

Yes.

>> The answerer MUST, based on the port number of the selected offerer
>> BUNDLE address, use the next higher (odd) destination port number
>> [RFC3550] for sending RTCP packets associated with each bundled
>> RTP-based "m=" line towards the offerer.
>> 
>> Section 12.2 and 12.3
>> 
>> Unless there is an explicit indication otherwise, reports are sent
>> to the port number one higher than the number indicated.
>> 
>> I note that RFC 3264 is actually not ensuring consistency with the
>> base rules for RTCP port assignment. If the m= line port is odd,
>> the two text here would result in different port numbers.
>> 
>> However, with the likely changes in 10.3.2.3 I guess we need to
>> stay with the rules according to RFC 3264 for implicit RTCP port.
> 

Good
> 
> ------------
> 
> 19. Section 13.3:
> 
>> The identification-tag is not zero terminated.  Note, however,
>> that RTP header extensions that are not a multiple of 32 bits in
>> length MUST be padded to the next 32-bit boundary using zero bytes;
>> these padding bytes are not included in the header length field
>> [RFC3550].
>> 
>> Actually the relevant reference regarding padding of header
>> extension that uses RFC 5285 is RFC 5285 as the padding is applied
>> after having added all the header extensions, not on per header
>> extension basis.
> 

Not only that. I think the following part is factual wrong:
"Note, however, that RTP header extensions that are not a multiple of 32
bits in length MUST be padded to the next 32-bit boundary using zero
bytes ..."

I think this paragraph should be changed to something more along the
lines of:

   The identification-tag is not zero terminated.  Note, that set of
header extensions included in the packet needs to be padded to the next
32-bit boundary using zero bytes [RFC5285].

>> Considering that they are included in the RTP header extension as
>> well in the RTCP SDES packets, their size suddenly matters much 
>> more than before. I think we really should recommend single or at
>> least no more than 3 character tags to ensure that they take 
>> minimal room in the header. In fact a short header extension with a
>> string consuming no more than 3 octets will result in only two
>> 32-bit words being added to the RTP header.
> 

As the identification-tag is included in either an RTCP SDES item or an
RTP header extension, or both, there should be some consideration about
the packet expansion caused by the identification-tag. To avoid Maximum
Transmission Unit (MTU) issues for the RTP packets, the header
extension's size needs to be taken into account when the encoding media.

It is recommended that the identification-tag is kept short. Due to the
properties of the RTP header extension mechanism, when using the
one-byte header, a tag that is 1-3 bytes will result in that a minimal
number of 32-bit words are used for the RTP header extension, in case no
other header extensions are included at the same time. Note, do take
into account that some single characters when UTF-8 encoded will result
in multiple octets.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
FÃ¤rÃ¶gatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Mar 2015 22:38:52 +0000

Hi,

------------
 
3. Section 4:
 
>>> I wonder if one needs to be explicit about that Declarative SDP usage 
>>> of BUNDLE is not defined, but may be defined in the future?
>> 
> I really think we should be clear that the current document do not define 
> Declarative usage. I expect that soon someone will like to use BUNDLE in a 
> declarative environment and they will have some questions to answer, thus 
> one can't assume this simply will work.
>
> OLD:

I can add the text, but I'd suggest to say "Declarative usage of SDP is out of scope of this document, and is thus undefined." It is quite clear that we have decided such approach, so I don't think we need to say it :)

------------
 
7. Section 7.2:
 
>> Perhaps IPv8 will use a completely different structure, which does not 
>> fit with the "IP address + combination"- and "5-tuple"
> Ok, I am fine with leaving it in place. A new IP version would anyway require 
> us to review a lot of things before being able to start using it. The potential 
> issue with writing as in the draft is that if IP8 would actually be straightforward 
> and work, you still will have to revise this specification.

Unless Al Gore suddenly decides to re-invent the Internet, I think it will take some time until we'll have to do such revision :)
 
------------
 
8. Section 7.3:
 
>>> However, I can understand the desire to scale RR and RS depending on 
>>> which media source that are accepted or rejected in the session, thus 
>>> per media source additions is not totally illogical.
>> 
> This is a bit tricky, but if one looks as the definition of CT I would say 
> that b=CT: in an media line should be the bundle total as offered or answered.
>
> What becomes uncertain for me is if CT at all is appropriate to use on media 
> level, or if it really should only occur on SDP session level.
> But, I can see that CT on session level gives total over all in the SDP, while 
> CT on a media line would be across the full scope of m= lines that a bundle covers.
>
> But, having thought abit more about RR and RS I think summing them appear appropriate.
>

This is one of those things we're I'll just sit back and let people tell me what to write :)

------------
 
9. Section 8.1:
 
>>> Which "transport protocol" is implied here, what the PROTO indicates 
>>> or the transport layer protocol, e.g. UDP?
>> 
>> The PROTO value.
>> 
>> So, perhaps I could say:
>> 
>  m= line transport protocol <proto> value associated with a  bundled media description."

I think I use "m= line proto value" terminology elsewhere, so I'd like to keep that in order to be aligned.
 
------------
 
11. Section 8.2.1:
 
>> zero port value, the same IP address and combination might be assigned 
>> to multiple "m=" lines."
> 
>
> No, I think you have to explicit that it is either a unique address or the 
> rejected/only if bundled address information. Thus, I think the bullet can read:
>

Ok. I assume one must not assign a zero port value to a non-bundle-only m- line, so...

------------
 
12. Section 8.5.1:
 
>>> I don't understand what the above means. As long as one has a bundle 
>>> group the MIDs of the m= blocks needs to be included. If all use the 
>>> shared address, then it doesn't matter which is first. If they are 
>>> not, then the order matters. However, without terminating the bundle 
>>> group you can't avoid selecting a new offerer BUNDLE address.
>> 
> What could be further clarified is that for the cases where the BUNDLE address 
> is not changed, but the m= line that the BUNDLE-tag pointed to no longer is part 
> of the bundle, then one picks any of the other existing tags for m= lines that carries the bundle address.

I'll think of some text.

------------
 
13. Section 8.5.2:
 
>> None that I can think of. As the note says, it does give the offerer a 
>> possibility to offer multiple new addresses.
>
> Okay, am I correct to assume that people will understand that the letar implies the need for a BAS?

I could add a note, saying that there might be a need to send a BAS. 

------------
 
14. Section 8.5.3:
 
>>> each bundled "m=" line [Section 8.5.2], also assign that address to 
>>> the added "m=" line.
>>> 
>>> I think there has been restructuring in this bullet list that moved, 
>>> I assume there should be an or between all of these bullets.
>> 
> I find this confusing because it not consistent, some bullet lists has the "or" or "and" on the first line, some on the second. > If they are no different, then please use the or/and consistently in the lists.

The "and"/"or" is supposed to be on the *second last* bullet (which may be first, second etc line, depending on how many bullets there are).

------------
 
15. Section 8.5.3:
 
>>> each bundled "m=" line [Section 8.5.2], also assign that address to 
>>> the added "m=" line.
>>> 
>>> I assume there is a missing "shared" in the first line of the bullet, 
>>> otherwise the same address would not be added to the new m=.
>> 
> I think that is appropriate to make clear that this really is shared case, 
> compared to the first case of unique address and the second of adding it to an existing bundle address.

So, you are ok with my suggested change?
 
------------

>> Are you suggesting to say "associating one or more SDP 'ssrc'

Ok, I'll fix that.

------------
 
19. Section 13.3:
 
>>> Actually the relevant reference regarding padding of header extension 
>>> that uses RFC 5285 is RFC 5285 as the padding is applied after having 
>>> added all the header extensions, not on per header extension basis.
>> 
> "Note, however, that RTP header extensions that are not a multiple 
> of 32 bits in length MUST be padded to the next 32-bit boundary using zero bytes ..."
>
> I think this paragraph should be changed to something more along the lines of:
>
> The identification-tag is not zero terminated.  Note, that set of header extensions 
> included in the packet needs to be padded to the next 32-bit boundary using zero bytes [RFC5285].

Ok.

------------
 
20. Section 13.3:
 
>>> well in the RTCP SDES packets, their size suddenly matters much more 
>>> than before. I think we really should recommend single or at least no 
>>> more than 3 character tags to ensure that they take minimal room in 
>>> the header. In fact a short header extension with a string consuming 
>>> no more than 3 octets will result in only two 32-bit words being 
>>> added to the RTP header.
>> 
> As the identification-tag is included in either an RTCP SDES item or an RTP 
> header extension, or both, there should be some consideration about the 
> packet expansion caused by the identification-tag. To avoid Maximum 
> Transmission Unit (MTU) issues for the RTP packets, the header extension's 
> size needs to be taken into account when the encoding media.
>
> It is recommended that the identification-tag is kept short. Due to the properties 
> of the RTP header extension mechanism, when using the one-byte header, a tag 
> that is 1-3 bytes will result in that a minimal number of 32-bit words are used for 
> the RTP header extension, in case no other header extensions are included at the 
> same time. Note, do take into account that some single characters when UTF-8 
> encoded will result in multiple octets.

Looks like a winner. I'll add it :)

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 Mar 2015 09:30:22 +0100

Hi,

Please see inline.

WG, there is need for input on Issue 8 at least.

On 2015-03-05 23:38, Christer Holmberg wrote:
> I can add the text, but I'd suggest to say "Declarative usage of SDP
is out of scope of this document, and is thus undefined." It is quite
clear that we have decided such approach, so I don't think we need to
say it :)

Sure.

> Unless Al Gore suddenly decides to re-invent the Internet, I think
> it will take some time until we'll have to do such revision :)
>  

Sure, do what ever you want. I have preference for something that don't
guarantee use to have to write spec text in the future.

So people should comment now, or this ends up on the agenda in Dallas I
assume to ensure that we actually have some sensible text here.

> I think I use "m= line proto value" terminology elsewhere, so I'd
> like to keep that in order to be aligned.

Yes, but in your proposal you skipped the "m=" indication, which I do
matters for clarity.

At least in the initial offer. In the following ones this is another
matter.

Thanks

That would be great.

> The "and"/"or" is supposed to be on the *second last* bullet (which
may be first, second etc line, depending on how many bullets there are).

Ok, please check consistency then.

Yes.

Thanks

Magnus Westerlund

Färögatan 6                 | Mobile +46 73 0949079

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Mar 2015 10:58:18 +0000

Hi,

------------
  
8. Section 7.3:
  
>>> This is a bit tricky, but if one looks as the definition of CT I 
>>> would say that b=CT: in an media line should be the bundle total as offered or answered.
>>>
>>> What becomes uncertain for me is if CT at all is appropriate to use 
>>> on media level, or if it really should only occur on SDP session level.
>>> But, I can see that CT on session level gives total over all in the 
>>> SDP, while CT on a media line would be across the full scope of m= lines that a bundle covers.
>>>
> So people should comment now, or this ends up on the agenda in Dallas I assume to ensure that we actually have some sensible text here.

I have a feeling that would be you, Jonathan L, Colin P and Roni E arguing with each other at the microphone, while others are reading their e-mails :)

I do, however, agree that unless we can solve this on the list, some f2f time could be needed for this, so I hope those interested could e.g. meet at a bar and discuss this, and hopefully be able to present some outcome at the MMUSIC session.

 Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 6 Mar 2015 11:23:09 +0000

Changing the subject and trimming

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Freitag, 6. März 2015 09:30
> To: Christer Holmberg
> Cc: mmusic (E-mail)
> Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16
> - The rest from Magnus
> 
> Hi,
> 
> Please see inline.
> 
<snip/>

Maybe the handling of the bandwidth modifiers isn't an issue for draft-bundle since draft-ietf-mmusic-sdp-mux-attributes covers that already with finer granularity.
A reference would be sufficient, avoids duplicate text and would be easiest for Christer.
Of course the issue doesn't disappear and needs to be handled in draft-mux-attributes. 

> media

I agree that this is not clear from the definition of CT in RFC4566.
However, with the traditional understanding that each m-line is a separate RTP session 
and how "conference" is defined in 4566
my interpretation of the following snippet from 4566 is, that CT is only meant for session-level.
" ... When
      using the CT modifier with RTP, if several RTP sessions are part
      of the conference, the conference total refers to total bandwidth
      of all RTP sessions. ..."
b=AS would then only be on media-level. 

> while
If my interpretation from above makes sense, then we shouldn't do this.
Instead b=AS should be summed up for all m-lines in the BUNDLE.
This would also be inline with what is currently in draft-mux-attributes.

> assume to ensure that we actually have some sensible text here.

Regards
Thomas 

... not Roni E., Jonathan L. or Colin P.

<snip/>

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 6 Mar 2015 11:47:44 +0000

> At least in the initial offer. In the following ones this is another
Of course the text above is on how to create a BUNDLE group, but the text shouldn't be overly restrictive.
I don't see a need to _generally_ disallow port=0 for non-bundle-only m-lines. 
Of course, port=0 doesn't makes sense for an m-line in the bundle group, but if 
the m-line is not bundled, why it couldn't be offered with port=0 even in the initial offer? 
This is allowed by RFC3264.

Regards
Thomas

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 Mar 2015 13:15:20 +0100

> This is allowed by RFC3264.

It was not my intention to restrict that. However, it is not an unique
address, thus it needs to be dealt with an exception in this text. So
then the exception formulation needs to be updated to either be
unspecific on why port is zero, or name the exceptions we know can occur.

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Mar 2015 12:17:37 +0000

Hi Thomas,

...

>Of course, port=0 doesn't makes sense for an m-line in the bundle group, but if the m-line is not bundled, why it couldn't be offered with port=0 even in the initial offer? 

The procedures in the spec only apply to BUNDLE groups. It is perfectly ok (at least as far as BUNDLE is concerned) to assign a zero port value to a non-bundled m- line in the initial Offer.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 6 Mar 2015 13:16:28 +0000

Magnus, 

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Freitag, 6. März 2015 13:15
> To: Stach, Thomas; Christer Holmberg
> Cc: mmusic (E-mail)
> Subject: Re: [MMUSIC] BUNDLE Issue#11 - was - RE: [MMUSIC] Comments on draft-
> ietf-mmusic-sdp-bundle-negotiation-16 - The rest from Magnus
> 
> the
> >>>> rejected/only if bundled address information. Thus, I think the bullet
> can
> >> read:
> >>>>
> It was not my intention to restrict that. 
Good, thanks.
> However, it is not an unique
Agreed.

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 6 Mar 2015 13:16:50 +0000

Christer,

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Freitag, 6. März 2015 13:18
> To: Stach, Thomas; Magnus Westerlund
> Cc: mmusic (E-mail)
> Subject: RE: [MMUSIC] BUNDLE Issue#11 - was - RE: [MMUSIC] Comments on draft-
> >Of course, port=0 doesn't makes sense for an m-line in the bundle group, but
> if the m-line is not bundled, why it couldn't be offered with port=0 even in
> the initial offer?
> The procedures in the spec only apply to BUNDLE groups. It is perfectly ok (at
> least as far as BUNDLE is concerned) to assign a zero port value to a non-
> bundled m- line in the initial Offer.
That was also my understanding. 
I just wanted to be sure that I didn't misinterpret your "port must not be 0" statement

Regards
Thomas

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Mar 2015 09:21:55 -0500

> At least in the initial offer. In the following ones this is another

If you assign a zero port value to a non-bundle-only m- line then you 
must not include it in the bundle.

	Thanks,
	Paul

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 21 Mar 2015 21:30:48 -0500

On Fri, Mar 6, 2015 at 5:23 AM, Stach, Thomas <[email-masked]>
wrote:

> > Subject: Re: [MMUSIC] Comments on
> draft-ietf-mmusic-sdp-bundle-negotiation-16
> > - The rest from Magnus
> >
> > Hi,
> >
> > Please see inline.
> >
> Maybe the handling of the bandwidth modifiers isn't an issue for
> draft-bundle since draft-ietf-mmusic-sdp-mux-attributes covers that already
> with finer granularity.
[Suhas] .. Most of category assignments to the Mux draft with respect to
Bandwidth was suggested by Magnus. If we all think the assignment makes
sense, adding a reference to Mux draft in BUNDLE draft is fine with me as
well.

> would say
> SDP,
> > >> CT on a media line would be across the full scope of m= lines that a
> bundle
> > covers.
> appear
> > appropriate.
> > > This is one of those things we're I'll just sit back and let people
> tell me
> > what to write :)
> > >
> >
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Mar 2015 14:14:07 +0000

Hi,

>> draft-bundle since draft-ietf-mmusic-sdp-mux-attributes covers that 
>> already with finer granularity. A reference would be sufficient, avoids 
>> duplicate text and would be easiest for Christer.
> [Suhas] .. Most of category assignments to the Mux draft with respect to Bandwidth was 
> suggested by Magnus. If we all think the assignment makes sense, adding a reference 
> to Mux draft in BUNDLE draft is fine with me as well.
 
draft-ietf-mmusic-sdp-mux-attributes only covers SDP attributes. The bandwidth is indicated using the SDP b= parameter.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 23 Mar 2015 10:21:11 -0500

Hello Christer

  I was referring to the sections
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-08#section-6.1

Here it covers b= for AS, CT, RR and RS.

Please let me know if this covers the cases you are looking for.

Thanks
Suhas

On Mon, Mar 23, 2015 at 9:14 AM, Christer Holmberg <
[email-masked]> wrote:

> Bandwidth was
> draft-ietf-mmusic-sdp-mux-attributes only covers SDP attributes. The
> bandwidth is indicated using the SDP b= parameter.
>
> Regards,
>
> Christer
>
>