Subject: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Oct 2015 13:53:37 +0000

Hi,

Section 7 of the RID draft says:

"Note that 'rid's are only required to be unique within a media
   section ("m-line"); they do not necessarily need to be unique within
   an entire RTP session.  In traditional usage, each media section is
   sent on its own unique 5-tuple, which provides an unambiguous scope.
   Similarly, when using BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
   streams uniquely to a single media description."

However, when BUNDLE is used, the MID value (RTP MID header extension) is not guaranteed to be present in every RTP packet. Section 14.1. of BUNDLE says:

"The RTP MID header extension SHOULD be included in some RTP packets
   at the start of the session and whenever the SSRC changes.  It might
   also be useful to include the header extension in RTP packets that
   comprise random access points in the media (e.g., with video
   I-frames)."

So, if the MID value is NOT included, and RTP packets associated with multiple m- lines use the same RIP value and the same PT value, will it be possible to associate the RTP packets to a single media description?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 09:39:59 -0500

As long as the recipient has seen both the MID for an SSRC and the RID 
for an SSRC, then it can perform the proper correlation.

If they haven't seen the MID yet, then they can't use the stream because 
they don't know what m-section it goes with.

/a

On 10/22/15 08:53, Christer Holmberg wrote:
> “Note that 'rid's are only required to be unique within a media
>
>    [I-D.ietf-mmusic-sdp-bundle-negotiation], *MID values associate RTP*
>
> *   streams uniquely to a single media description.*”
>
> However, when BUNDLE is used, the MID value (RTP MID header extension) 
> is not guaranteed to be present in every RTP packet. Section 14.1. of 
> BUNDLE says:
>
> “The RTP MID header extension SHOULD be included in some RTP packets
>
>    I-frames).”
> So, if the MID value is NOT included, and RTP packets associated with 
> multiple m- lines use the same RIP value and the same PT value, will 
> it be possible to associate the RTP packets to a single media description?
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 22 Oct 2015 14:42:42 +0000

MID and RID are both RTCP SDES items that echo SDP identifiers in RTP/RTCP using the generic sdes-hdrext mechanism. Once the identifier value is associated to an RTP stream (identified by its SSRC) via RTCP packets with MID/RID SDES items or RTP packets with MID/RID header extensions, the association can remain in effect without echoing the header extension in every RTP packet.

We should probably add some text to warn implementers not to rely on receiving MID and RID in every RTP packet, and use the last valid association to that SSRC when absent.

Mo

On Oct 22, 2015, at 9:53 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Oct 2015 19:00:14 +0000

Hi,

> As long as the recipient has seen both the MID for an SSRC and the RID for an SSRC, then it can perform the proper correlation.

That’s what I assumed, and it’s the same way BUNDLE works (where you send the RTP MID until you assume the other endpoint has seen the SSRC).

It would probably be a good idea to modify the text in the draft to reflect that.

BTW, is there a reason why the RID value can’t be unique for the whole SDP? Is there a risk we’d run out of values? What is the value range that “fits” into the RID RTP header extension?

Regards,

Christer

   streams uniquely to a single media description.”

Regards,

Christer

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Oct 2015 19:01:42 +0000

Hi,

>MID and RID are both RTCP SDES items that echo SDP identifiers in RTP/RTCP using the generic sdes->hdrext mechanism. Once the identifier value is associated to an RTP stream (identified by its SSRC) via >RTCP packets with MID/RID SDES items or RTP packets with MID/RID header extensions, the >association can remain in effect without echoing the header extension in every RTP packet.
>
>We should probably add some text to warn implementers not to rely on receiving MID and RID in >every RTP packet, and use the last valid association to that SSRC when absent.

Or, you could simply refer to BUNDLE, because this is only going to be an issue when BUNDLE is used.

Regards,

Christer

Mo

Regards,

Christer

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 22 Oct 2015 19:09:55 +0000

Referring to BUNDLE works for warning implementers against relying on MID in every RTP packet. But the same warning is needed for RID regardless of whether BUNDLE is used or not.

Cheers,
Mo

On 10/22/15, 3:01 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Mo

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Oct 2015 19:11:09 +0000

True.

From: Mo Zanaty (mzanaty) [mailto:[email-masked]]
Sent: 22 October 2015 22:10
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line

Cheers,
Mo

Hi,

Regards,

Christer

Mo

Regards,

Christer

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 22 Oct 2015 19:13:30 +0000

RID (like MID and all SDES items) is limited to 255 octets. No risk of exhaustion, so offerers are free to make them unique across the whole SDP if they want.

Cheers,
Mo

On 10/22/15, 3:00 PM, mmusic on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,

> As long as the recipient has seen both the MID for an SSRC and the RID for an SSRC, then it can perform the proper correlation.

That's what I assumed, and it's the same way BUNDLE works (where you send the RTP MID until you assume the other endpoint has seen the SSRC).

BTW, is there a reason why the RID value can't be unique for the whole SDP? Is there a risk we'd run out of values? What is the value range that "fits" into the RID RTP header extension?

Regards,

Christer

Regards,

Christer

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Oct 2015 19:18:00 +0000

Hi,

>RID (like MID and all SDES items) is limited to 255 octets. No risk of exhaustion, so offerers are free to make them >unique across the whole SDP if they want.

If there is no risk of exhaustion, is there a reason not to MANDATE them to be unique?

Regards,

Christer

Hi,

Regards,

Christer

Regards,

Christer

mmusic mailing list

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 14:21:57 -0500

On 10/22/15 2:18 PM, Christer Holmberg wrote:
>
> Hi,
>
> >RID (like MID and all SDES items) is limited to 255 octets. No risk of 
> exhaustion, so offerers are free to make them >unique across the whole 
> SDP if they want.
>

Well, it's an unnecessary restriction, and we'd like people to keep them 
short. While they won't be in every packet, they'll likely be in the 
*same* packets as other correlating identifiers like MID (e.g., at 
stream startup).

On the balance, it's not much of a trade-off. The size of these things 
can still be pretty small if they're unique, but being unique buys you 
(almost?) nothing.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 22 Oct 2015 15:41:29 -0700

And it's nice to have the same RIDs across multiple m-lines.  For example,
if each m-line represents a participant in a video  conference (say,
participants A, B, and C), and each has three RIDs (say, S, M, L) then you
can just have RID S, M, L on each m-line rather than having to have A-S,
A-M, A-L, B-S, B-M, B-L, C-S, C-M, C-L.

Of course, you can still do that if you want, but it may be inconvenient to
have to do it.

On Thu, Oct 22, 2015 at 12:21 PM, Adam Roach <[email-masked]> wrote:

> short. While they won't be in every packet, they'll likely be in the *same*
> packets as other correlating identifiers like MID (e.g., at stream startup).
>
> On the balance, it's not much of a trade-off. The size of these things can
> still be pretty small if they're unique, but being unique buys you
> (almost?) nothing.
>
> /a
>