Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12

From: Flemming Andreasen <[email-masked]>
Date: Thu, 09 Oct 2014 15:50:10 -0400

This is to announce a 2 week Working Group Last Call for

         draft-ietf-mmusic-sdp-bundle-negotiation-12

as Proposed Standard. Please review and provide any comments you may 
have on the document by Friday, October 24, 2014. Comments should be 
sent to the document authors and the MMUSIC WG list. If you review the 
document but do not have any comments, please send a note to that effect 
as well.

Thanks

        Flemming

Draft info:

  This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

         Title           : Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
         Authors         : Christer Holmberg
                           Harald Tveit Alvestrand
                           Cullen Jennings
	Filename        : draft-ietf-mmusic-sdp-bundle-negotiation-12.txt
	Pages           : 46
	Date            : 2014-10-09

Abstract:
    This specification defines a new SDP Grouping Framework extension,
    'BUNDLE'.  The extension can be used with the Session Description
    Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a
    single 5-tuple for sending and receiving media associated with
    multiple SDP media descriptions ("m=").  This is referred to as
    bundled media.

    Both endpoints can negotiate the use of bundle and to support that
    negotiations, this specification defines a new SDP attribute,
    'bundle-only', which can be used to request that specific media is
    only used if bundled.  This specification also updates sections 5.1,
    8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero
    port value to an "m=" line in an SDP answer, even if the "m=" line in
    the associated SDP offer contained a zero port value.

    There are multiple ways to correlate the bundled RTP packets with the
    appropriate media descriptions.  This specification defines a new RTP
    SDES item and a new RTP header extension that provides an additional
    way to do this correlation by using them to carry a value that
    associates the RTP/RTCP packets with a specific media description.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 14 Oct 2014 16:33:56 +0100

On 9 Oct 2014, at 20:50, Flemming Andreasen <[email-masked]> wrote:
> as Proposed Standard. Please review and provide any comments you may have on the document by Friday, October 24, 2014. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. 

In general this looks good, but I do have a few relatively minor comments:

- Section 1, 7th paragraph: typo “a new RTP SDES item” -> “a new RTCP SDES item”

- Section 10.1.1: the third bullet point says that a given SSRC “SHOULD NOT” transmit RTP packets using payload types that originate from different bundled “m=“ lines, and follows this with an explanatory note. Given the problems that SSRC reuse will cause, I suggest strengthening this to “MUST NOT", then adding a further note to address the case where SSRC reuse works saying “However, once an SSRC has left the RTP session by sending an RTCP BYE packet, that SSRC value can later be reused by another source, possibly on a different bundled m= line”. 

- Section 10.3.1: the last sentence is unclear what separate 5-tuple will be used if RTP/RTCP multiplexing is not enabled. This is explained in Section 10.3.2.3, and the draft would be clearer if 10.3.1 referenced this.

- Section 13.2: it may be useful to clarify that the mid value is not zero terminated.

- Section 13.3: again, clarify that the mid value is not zero terminated. It may also be useful to remind implementers that the RFC 5285 format requires padding out to the next 32-bit boundary using zero bytes if the size of the header extension isn’t a multiple of 32 bits. This padding could easily be confused with a terminating zero by a careless implementer.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 24 Oct 2014 14:50:11 +0000

One issue which I’ve brought up a number of times in BUNDLE is whether it’s valid for an RTP stream to move between bundled m-lines, or be shared between several bundled m-lines.

While (as I’ve described) there are a number of useful features that this could enable, it sounded at the last IETF meeting that people weren’t interested in the complexity it introduces.  (It’s certainly something that wouldn’t be possible with unbundled m-lines.)  As such, I think BUNDLE needs to document that this isn’t allowed.

As such, I suggest adding to the section on MID something like:

RTP streams MUST NOT be moved between media descriptions.  If a MID is communicated for an RTP stream, that stream's SSRC MUST NOT be reused for another RTP stream with a different MID value until at least twice the Maximum Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or RTCP) was sent for the old stream.

This makes sure that stuck packets in the network can't confuse a stream’s MID association.

If people *do* want the ability to move streams between m-lines, we will need some more complicated rules, which I could try to draft if people are interested.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Oct 2014 16:01:00 +0000

Hi Jonathan,

In the RTP Considerations section, we currently have the following text:

	"A given SSRC MUST NOT transmit RTP packets using payload types that 
	originate from different bundled "m=" lines."

That doesn't cover what you are talking about, but perhaps we could add a statement saying something like:

	"A given SSCR MUST NOT transmit RTP packets associated with different "m=" lines. When
	the RTP MID header extension is used, the SSRC MUST use the same 'mid' value in every
	RTP packet."

...or something like that.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: 24 October 2014 17:50
To: mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

One issue which I've brought up a number of times in BUNDLE is whether it's valid for an RTP stream to move between bundled m-lines, or be shared between several bundled m-lines.

While (as I've described) there are a number of useful features that this could enable, it sounded at the last IETF meeting that people weren't interested in the complexity it introduces.  (It's certainly something that wouldn't be possible with unbundled m-lines.)  As such, I think BUNDLE needs to document that this isn't allowed.

This makes sure that stuck packets in the network can't confuse a stream's MID association.

If people *do* want the ability to move streams between m-lines, we will need some more complicated rules, which I could try to draft if people are interested.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Oct 2014 16:07:36 +0000

...and, obviously the SSRC would also always use the same MID in the RTCP SDES MID item.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 24 October 2014 19:01
To: Jonathan Lennox; mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

Hi Jonathan,

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 24 Oct 2014 18:38:11 +0000

Right.

The case my “twice the MSL” text is designed to handle is the case where an SSRC leaves (sends RTCP bye), and then the sender spins up another SSRC on a different mid, and happens to pick the same SSRC value.  This shouldn’t happen very often (1 in 2^32) if SSRC randomization is implemented properly, but sometimes people use bad random number generators (or are, e.g., playing games with not renumbering at a source projecting mixer).  This isn’t an SSRC collision, technically, since for the sender the old source is gone, but if old packets with the old mid are still lingering in the network, you’ll get confused.  Thus my recommendation to make sure you wait before you reuse SSRC values.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Oct 2014 19:24:48 +0000

Hi,

So, is the text I suggested ok, or do you want to write something else?

If would be good if we could add the text to the bullet list in the RTP Considerations section. But, if you think it requires more text, we'll put it somewhere else.

Regards,

Christer

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: 24 October 2014 21:38
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

Right.

The case my "twice the MSL" text is designed to handle is the case where an SSRC leaves (sends RTCP bye), and then the sender spins up another SSRC on a different mid, and happens to pick the same SSRC value.  This shouldn't happen very often (1 in 2^32) if SSRC randomization is implemented properly, but sometimes people use bad random number generators (or are, e.g., playing games with not renumbering at a source projecting mixer).  This isn't an SSRC collision, technically, since for the sender the old source is gone, but if old packets with the old mid are still lingering in the network, you'll get confused.  Thus my recommendation to make sure you wait before you reuse SSRC values.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 24 Oct 2014 19:28:38 +0000

My worry is that your text (as modified to include RTCP), interpreted literally, would be too constraining for very-long-lived sessions, where you might have used an SSRC on one m-line three weeks ago, and now you need to remember it forever so you don’t reuse that same value on a different one.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Oct 2014 19:36:28 +0000

Hi,

What about:

"A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets associated with different "m=" lines. There needs to be a time period, long enough to make sure there are no packets associate with the previous "m=" line in the network, before the SSRC starts to transmit RTP/RTCP packets associated with a new "m=" line."

Regards,

Christer

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: 24 October 2014 22:29
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

My worry is that your text (as modified to include RTCP), interpreted literally, would be too constraining for very-long-lived sessions, where you might have used an SSRC on one m-line three weeks ago, and now you need to remember it forever so you don't reuse that same value on a different one.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 25 Oct 2014 14:56:36 +0100

Hi,

I suggest that the timeout period be 5 times the RTCP reporting interval. This is the SSRC timeout interval defined in RFC 3550 section 6.3.5, and is how long a receiver will consider an SSRC valid if that SSRC stops sending and it’s RTCP BYE is lost.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Oct 2014 14:28:35 +0000

Hi Colin,

Thanks for your input.

So, perhaps something like:

A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associated with a single "m=" line. If the SSRC wants to switch "m=" line, there MUST be a timeout interval of 5 times the RTCP reporting interval before the SSRC starts to transmit RTP/RTCP packets associated with the new "m=" line, as that will ensure that any remaining packets associated with the previous "m=" line will be considered invalid [RFC3550]."

Regards,

Christer

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 25 October 2014 16:57
To: Christer Holmberg
Cc: Jonathan Lennox; mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

Hi,

I suggest that the timeout period be 5 times the RTCP reporting interval. This is the SSRC timeout interval defined in RFC 3550 section 6.3.5, and is how long a receiver will consider an SSRC valid if that SSRC stops sending and it's RTCP BYE is lost.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 25 Oct 2014 15:36:59 +0100

Hi,

Possibly, although that suggests that an SSRC can switch m= lines, whereas what happens is that the SSRC leaves the session and re-joins as a different m= line. Perhaps:

A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associated with a single “m=" line. An SSRC can leave the session and rejoin under a different “m=“ line, however to do so it MUST send an RTCP BYE packet, then MUST wait for a timeout interval of 5 times the RTCP reporting interval, before the SSRC starts to transmit RTP/RTCP packets associated with the new “m=“ line. The RTCP BYE and timeout interval ensure that any remaining packets and state associated with the SSRC on the previous “m=“ line will be considered invalid [RFC3550].

Colin

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Oct 2014 14:56:33 +0000

Hi Colin,

Your suggested text looks good. But, doesn't RFC 3550 specify the sending of RTCP BYE for leaving a session? If so, I don't think we should use "MUST" in the BUNDLE draft. We should simply indicate that a RTCP BYE is sent.

Regards,

Christer

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 25 October 2014 17:37
To: Christer Holmberg
Cc: Jonathan Lennox; mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

Hi,

A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associated with a single "m=" line. An SSRC can leave the session and rejoin under a different "m=" line, however to do so it MUST send an RTCP BYE packet, then MUST wait for a timeout interval of 5 times the RTCP reporting interval, before the SSRC starts to transmit RTP/RTCP packets associated with the new "m=" line. The RTCP BYE and timeout interval ensure that any remaining packets and state associated with the SSRC on the previous "m=" line will be considered invalid [RFC3550].

Colin

---

From: Colin Perkins <[email-masked]>
Date: Sat, 25 Oct 2014 16:02:39 +0100

Hi,

You could say “…it has to first send an RTCP BYE following the rules in section 6.3.7 of RFC3550, then it MUST wait for a timeout…”?

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Oct 2014 17:39:30 +0000

Hi,

What about?

"A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associated with a single "m=" line. An SSRC can leave the session and re-join under a different "m=" line. If the SSRC does that, after it has sent an RTCP BYE packet [RFC3550], it MUST wait for a timeout interval of 5 times the RTCP reporting interval before it starts to transmit RTP/RTCP packets associated with the new "m=" line. The RTCP BYE packet and the timeout interval ensure that any remaining packets and state associated with the SSRC on the previous "m=" line will be considered invalid [RFC3550]."

Regards,

Christer

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 25 October 2014 18:03
To: Christer Holmberg
Cc: Jonathan Lennox; mmusic
Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not

Hi,

You could say "...it has to first send an RTCP BYE following the rules in section 6.3.7 of RFC3550, then it MUST wait for a timeout..."?

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sun, 26 Oct 2014 23:36:49 +0000

Sure, that looks okay.

-- 
Colin Perkins
http://csperkins.org/

> On 25 Oct 2014, at 18:39, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> What about?
>