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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Feb 2015 16:41:43 +0100

Hi,

I have finally managed to review what has happened in BUNDLE during my
absent. This email contains the rest of the issues that are not
considered big enough to get its own email.

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?

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.

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?

4. section 5.1:

Is the 5.1 heading really needed?

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.

6. Section 6.2:

Section title: bundle-only

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

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?

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.

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?

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?

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.

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.

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?

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.

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

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.

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.

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.

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.

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.

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