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

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 11:42:45 +0000

Hi,

Based on comments, I¹ve modified the text. It now talks about associating
RTP STREAMS with m- lines.

------

10.2.  Associating RTP/RTCP Streams With Correct SDP Media Description

   As described in [RFC3550], RTP/RTCP packets are associated with RTP
   streams.  Each RTP stream is identified by an SSRC value, and each
   RTP/RTCP packet carries an SSRC value that is used to associate the
   packet with the correct RTP stream (an RTCP packet can carry multiple
   SSRC values, and might therefore be associated with multiple RTP
   streams).

   In order to be able to process received RTP/RTCP packets correctly it
   must be possible to associate an RTP stream with the correct "m="
   line, as the "m=" line and SDP attributes associated with the "m="
   line contain information needed to process the packets.

   As all RTP streams associated with a BUNDLE group are using the same
   address:port combination for sending and receiving RTP/RTCP packets,
   the local address:port combination cannot be used to associate an RTP
   stream with the correct "m=" line.  In addition, multiple RTP streams
   might be associated with the same "m=" line.

   Also, as described in [Section 10.1.1], the same payload type value
   might be used by multiple RTP streams, in which case the payload type
   value cannot be used to associate an RTP stream with the correct "m="
   line.

   An offerer and answerer can inform each other which SSRC values they
   will use for an RTP stream by using the SDP 'ssrc' attribute
   [RFC5576].  However, an offerer will not know which SSRC values the
   answerer will use until the offerer has received the answer providing
   that information.  Due to this, before the offerer has received the
   answer, the offerer will not be able to associate an RTP stream with
   the correct "m=" line using the SSRC value associated with the RTP
   stream.  In addition, the offerer and answerer may start using new
   SSRC values mid-session, without informing each other using the SDP
   'ssrc' attribute.

   In order for an offerer and answerer to always be able to associate
   an RTP stream with the correct "m=" line, the offerer and answerer
   using the BUNDLE extension MUST support the mechanism defined in
   Section 14, where the offerer and answerer insert the identification-
   tag (provided by the remote peer) associated with an "m=" line in RTP
   and RTCP packets associated with a BUNDLE group.

   Once an offerer or answerer recieve an RTP/RTCP packet carrying an
   identification-tag and an SSRC value (an RTCP packet might carry
   multiple identification-tags and SSRC values), it creates a mapping
   between the SSRC value and the identification-tag, in order to
   associate the RTP stream with the "m=" line associated with the
   identification-tag.  Note that the mapping might change mid-session
   if, for a given SSRC value, a different identification-tag is
   provided in an RTP/RTCP packet.

   If an offerer and answerer is not able to associate an RTP stream
   with an "m=" line (using the mechanisms described in this section, or
   using other appropriate mechanism), it SHOULD drop the RTP/RTCP
   packets associated with the RTP stream, once non-stream specific
   processing (e.g., related to congestion control) of the packets have
   occurred.  Note that RTCP packets might be associated with multiple
   RTP streams.

------

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 13:02:13 +0000

Same in GitHub:

https://github.com/cdh4u/draft-sdp-bundle/pull/13

Regards,

Christer

On 20/10/16 14:42, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

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