Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - RTP demux

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Sep 2016 21:10:16 +0000

Hi,

## RTP Demux 

>Need more explicit text how how to demux RTP based on MID and how SSRC latching >works. The definition of MID in RTP does not really make sense without this. 

Section 10.2 describes the usage of MID in RTP. Feel free to suggest additional text, if you think it's needed.

Not sure I understand why we would describe SSRC latching.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Sep 2016 16:45:33 -0700

> Not sure I understand why we would describe SSRC latching.

A description of how to associate inbound media with a m-line seems
entirely appropriate. That necessarily includes latching on ssrc. See Peter
's recent pull request on jsep.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Sep 2016 21:28:26 -0400

As it stands now, particularly with respect to Section 10.2, the handling of RTP packets is under-specified. SSRC latching solves part of the problem, since it handles situations where a MID was present in initial packets in the RTP stream, but no longer are. 

However there are other cases that need to be handled:

Non-unique PTs:
     1. Do SSRCs latch? If so, does this happen only when no SSRCs are specified for codecs? What if there are SSRCs for RTX/FEC?
     2. Does order matter?

> On 19 Sep 2016 7:10 AM, "Christer Holmberg" <[email-masked]> wrote:
> A description of how to associate inbound media with a m-line seems entirely appropriate. That necessarily includes latching on ssrc. See Peter 's recent pull request on jsep.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Sep 2016 18:53:34 -0700

On 18 September 2016 at 18:28, Bernard Aboba <[email-masked]> wrote:
> Non-unique PTs:
>      1. Do SSRCs latch? If so, does this happen only when no SSRCs are
> specified for codecs? What if there are SSRCs for RTX/FEC?
>      2. Does order matter?

Yes, I agree that these are issues.  I think that - at least on
balance - the suggestions that Peter makes here are OK:
https://github.com/rtcweb-wg/jsep/pull/320

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Sep 2016 07:53:52 +0000

Hi,

Ok, I think I get it: there is no guarantee that all SSRCs will be listed
in the SDP. So, therefore, when RTP with MID is received, the receiver
should latch the SSRC to the m- line associated with the MID, so that the
receiver knows how to associated RTP packets without MID to the correct m-
line?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Sep 2016 19:25:53 +1000

> receiver knows how to associated RTP packets without MID to the correct m-

Right.  Note that even if the SSRC is listed, then there is a chance
that it needs to change.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Sep 2016 15:54:05 +0200

Hi,

So from your perspective it can be seen as latching. From my perspective 
the SDES MID value is an property bound to an SSRC. This value persist 
until changed like other SDES items that has been set, either through 
RTCP or the RTP header extension. Thus, until an SSRC's MID value is 
updated its RTP data should be demuxed according to that value.

I also note that there can be multiple SSRCs bound to the same m= line 
using the same MID value, as we have cases for multiple RTP streams for 
FEC and RTP Retransmission for example.

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