Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Feb 2017 16:21:22 +0100

Hi Jonathan,

Thanks for the feedback. See inline for my attempt to answer them.

Den 2017-01-31 kl. 18:43, skrev Jonathan Lennox:
> In general, this looks good.
>
> I have one question, however.  What should happen if an RTP packet
> (without a MID) is received for a stream that has an existing mapping
> to an m= line, but whose PT is not valid for that m= line?
>

So, the text in JSEP-18 didn't specify this either. However, I do have 
an opinion on this.

> Should it 1. Cause the stream’s mapping to be moved to another m=
> line, if the received PT is in the payload type table for some other
> m= line? or

I would recommend against this due to that we will have to go into under 
which circumstances that one can accept this, and when not. Bo Burman 
and I had some discussion on this. We arrived at some relevant aspects 
of this. The first is that one have one to consider precedence rules 
between PTs, as well as a=ssrc and MID. In general we think mismatch 
between the information is to be considered an error. However, using PT 
and MID could cause strange error cases, where packets without MID ends 
up in on m= line with the PT and the ones with MID are dropped as 
inconsistent. I would claim that this stream is always in error.

I would also note that Bundle specification currently forbids PT based 
switching, but for a different reasons. Section 10.1 says:

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

    NOTE: The last bullet above is to avoid sending multiple media types
    from the same SSRC.  If transmission of multiple media types are done
    with time overlap, RTP and RTCP fail to function.  Even if done in
    proper sequence this causes RTP Timestamp rate switching issues
    [RFC7160].  However, once an SSRC has left the RTP session (by
    sending an RTCP BYE packet), that SSRC can be reused by another
    source (possibly associated with a different bundled "m=" line) after
    a delay of 5 RTCP reporting intervals (the delay is to ensure the
    SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]).

But, we do note that the limitation is not strictly necessary in regards 
to the motivation. The minimal limitation based on the motivation would 
be to require that a SSRC only uses PTs of the same media type and clock 
rate within a single bundle group. Using shared PTs, which the current 
limitation requires automatically meets that goal, and is easier to 
check for.

We also noted that BUNDLE should clarify how MID relates to a=ssrc 
(RFC5576). My interpretation is that a=ssrc locks a RTP stream to a 
particular m= line, and can't be moved. So any MID value other than that 
matches the m= line that has the a=ssrc value would be an error case. 
For usages that intend to have a RTP stream to bounce between m= lines 
should not use a=ssrc, only MID. I think it would be good to clarify 
this in the BUNDLE specification.

 > 2. Be an error?

This would be my preferred choice.

>
> In other words, should it be possible for PT-mapping to cause streams
> to change their mappings?

To conclude: No, as it would cause several additional complexities and 
possible branches in the algorithm. The use case for moving SSRCs 
between m= lines are supported when using MID, and the m= lines are 
correctly configured with shared PTs.

Cheers

Magnus

>
> (Should this decision depend on what caused the stream to be mapped
> to its current m= line?)
>
>> On Jan 27, 2017, at 11:43 AM, Magnus Westerlund
>> <[email-masked]> wrote:
>>
>> MMUSIC and RTCWEB,
>>
>> Here is now a more complete text proposal that also considers the
>> RTCP. It also goes further than what Appendix B defines in one
>> aspect, namely explicitly considering third party RTCP reporting
>> and what to do with it.
>>
>> Feedback is much appreciated. I plan to put this into a PR towards
>> JSEP APPENDIX B on monday. If only to get the JSEP authors
>> attention ;-). However, the text is really intended for the next
>> version of BUNDLE.
>>
>>
>> X.  Associating RTP/RTCP With Correct SDP Media Description
>>
>> As described in [RFC3550], RTP packets are associated with RTP
>> streams [RFC7656].  Each RTP stream is identified by an SSRC
>> value, and each RTP packet carries an SSRC value that is used to
>> associate the packet with the correct RTP stream.  RTCP packets
>> also uses SSRCs to identify on which RTP streams any report or
>> feedback relate to. Thus, an RTCP packet will commonly carry
>> multiple SSRC values, and might therefore be providing feedback or
>> report on 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 part of the
>> same RTP session and 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.  However, there are cases where each "m=" line
>> has unique payload type values, and then the payload type could
>> serve as indicator to the relevant "m=" line the RTP stream is
>> associated with.
>>
>> 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
>>
>>
>>
>> Name                      Expires July 31, 2017
>> [Page 2]
>>
>> Internet-Draft              Abbreviated-Title               January
>> 2017
>>
>>
>> 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 includes the
>> identification-tag (provided by the remote peer) associated with
>> an "m=" line in the RTP Streams and in RTCP SDES packets part of a
>> BUNDLE group.
>>
>> The mapping from an SSRC to an identification-tag is carried in
>> RTCP SDES packets or in RTP header extensions (Section 14).  Since
>> a compound RTCP packet can contain multiple RTCP SDES packets, and
>> each RTCP SDES packet can contain multiple chunks, an RTCP packet
>> can contain several SSRC to identification-tag mappings.  The
>> offerer and answerer maintain tables mapping RTP streams identified
>> by SSRC to "m=" lines identified by the identification-tag.  These
>> tables are updated each time new information that affects how
>> packets should be processed and routed are received.
>>
>> To prepare for demultiplexing RTP streams to the correct "m="
>> line, the following steps MUST be followed for each BUNDLE group
>> based on the SDP signalling information.
>>
>> Construct a table mapping MID to "m=" line for each "m=" line in
>> this BUNDLE group.  Note that an "m=" line may only have one MID.
>>
>> Construct a table mapping incoming RTP streams (SSRCs) to their
>> "m=" line for each "m=" line in this BUNDLE group and for each RTP
>> stream explicitly signalled for receiving in that "m=" line.
>>
>> Construct a table mapping payload types to "m=" line for each "m="
>> line in the BUNDLE group and for each payload type configured for
>> receiving in that "m=" line.  If any payload type is configured for
>> receiving in more than one "m=" line in the BUNDLE group, do not it
>> include it in the table.
>>
>> Note that for each of these tables, there can only be one mapping
>> for any given key (MID, SSRC, or PT).  In other words, the tables
>> are not multimaps.
>>
>> As "m=" lines are added or removed from the BUNDLE groups, or
>> their configurations are changed, the tables above MUST also be
>> updated.
>>
>>
>>
>> Name                      Expires July 31, 2017
>> [Page 3]
>>
>> Internet-Draft              Abbreviated-Title               January
>> 2017
>>
>>
>> Received RTP packets that are syntactically correct are processed
>> by the RTP/RTCP protocol implementation for statistics etc.  After
>> this processing they need to be routed to the higher layer context
>> associated with the "m=" line within the BUNDLE group.  Somewhere
>> in the process where an received RTP packet is processed to be
>> delivered to the higher layer by RTP the matching step below MUST
>> be performed:
>>
>> 1.  Reception of an RTP packet for an RTP stream that has an
>> existing mapping in the RTP stream to m= line table.  Before
>> proceeding in delivering the packet to the higher layer context
>> according to the RTP stream to "m=" line mapping table the
>> following checks MUST be performed:
>>
>> A.  If the packet carries an RTP header extension with a SDES MID
>> value that is not in the table mapping MID to "m=" line, then do
>> not deliver the RTP packet to higher layers.
>>
>> B.  If the packet carries an RTP header extension with a SDES MID
>> value that is in the table mapping MID to "m=" line, and the value
>> indicates a different "m=" line than the current RTP stream to "m="
>> line mapping table, then update the RTP stream to "m=" line
>> mapping.
>>
>> 2.  Reception of an RTP packet for an RTP stream that has no
>> existing mapping to an m= line.  In this case the following actions
>> MUST be performed:
>>
>> A.  If the packet carries an RTP header extension with a SDES MID
>> value that is in the table mapping MID to "m=" line, then create an
>> entry in the RTP stream to "m=" line mapping table for this RTP
>> stream (SSRC).  Then deliver the RTP packet to the "m=" line
>> context of the created mapping and stop.
>>
>> B.  If the packet carries a Payload Type that is in the payload
>> type table, then create an entry in the RTP stream to "m=" line
>> mapping table for this RTP stream (SSRC).  Then deliver the RTP
>> packet to the "m=" line context of the created mapping and stop.
>>
>> C.  Otherwise do not deliver the RTP packet to higher layers. Note,
>> this includes unknown MID values.
>>
>> For each RTCP packet received (including each RTCP packet that is
>> part of a compound RTCP packet), the RTCP packet needs to be
>> processed by the RTP/RTCP implementation and relevant information
>> and data from the RTCP packets needs to be routed to the
>> appropriate handler for the related RTP streams.  The appropriate
>> handler is determined by using the RTP stream to "m=" line mapping
>> table.
>>
>>
>>
>> Name                      Expires July 31, 2017
>> [Page 4]
>>
>> Internet-Draft              Abbreviated-Title               January
>> 2017
>>
>>
>> On reception of any compound RTCP packet prior to dispatching the
>> received information and data, if there is an RTCP SDES packet
>> included that SHOULD be processed first.  If that SDES packet
>> contains SDES MID entries, this can results in updates and
>> additions to the RTP stream to "m=" line mapping table.  Thus each
>> of the SDES MID items are processed and the current table entries
>> are checked if the corresponding MID value matches the current RTP
>> stream to "m=" line mapping, else the entry is updated.  If there
>> is no RTP stream to "m=" line table mapping entry for the received
>> SDES item's SSRC, such an entry is created.  Note, that in the
>> process of updating the table entries, update flap suppression as
>> discussed in Section 4.2.6 of [RFC7941] should be considered.
>>
>> The various different RTCP packets as well as their various sub
>> parts, such as the various RTCP Feedback message types, relates to
>> the RTP streams in a couple of different ways.  The currently
>> known patterns are the following:
>>
>> Reports on outgoing RTP streams:  For all RTP streams that this
>> endpoint is the source of, it can expect to receive report blocks
>> of several types identified as relating to an outgoing stream. The
>> basic pattern for these blocks are that the RTCP packet header
>> identifies the source of the reports, as identified by an SSRC, and
>> containing one or more report blocks, where each report block
>> identifies the RTP stream, using the SSRC, the report relates to.
>> For this pattern the relevant report information is provided to the
>> higher layer associated with the "m=" line the RTP Stream to "m="
>> line table identifies.  The source SSRC as identifier of the
>> endpoint that the report originates are relevant for interpreting
>> the information, but not necessarily for routing.  Example of this
>> is pattern are:
>>
>> Sender Report (SR) and Receiver Report (RR)  The basic receiver
>> report blocks from RFC3550 start with the SSRC of the RTP stream
>> they report on.
>>
>> Extended Reports (XR):  RFC3611 is a framework that enables a large
>> number of different reports.  However, a large number of these
>> report formats are reporting on specific RTP streams and thus each
>> individual report of these types contains a SSRC field to identify
>> the RTP stream.
>>
>> RTCP Feedback Messages for outgoing RTP streams:  The RFC 4585
>> RTCP feedback messages allow for a number of different type of
>> feedback messages.  However, the RTCP feedback message header
>> contains the SSRC identifying the source of the feedback messages
>> as well as the actual type of the feedback.  Some of the feedback
>> messages also uses the target SSRC field in the header to identify
>> which
>>
>>
>>
>> Name                      Expires July 31, 2017
>> [Page 5]
>>
>> Internet-Draft              Abbreviated-Title               January
>> 2017
>>
>>
>> RTP stream the feedback is related to.  For these types all the FCI
>> entries, if multiple ones are forwarded to the identified handler.
>> Examples of this pattern are:
>>
>> Picture Loss Indication (PLI):  RFC 4585 (PT=PSFB, FMT=1).
>>
>> Slice Loss Indication (SLI):  RFC 4585 (PT=PSFB, FMT=2).
>>
>> Reference Picture Selection Indication (RPSI):  RFC 4585 (PT=PSFB,
>> FMT=3).
>>
>> Generic NACK:  [RFC4585] (PT=RTPFB and FMT=1).
>>
>> Other feedback messages includes the target SSRC in the Feedback
>> Control Information (FCI).  Here each FCI needs to be processed and
>> the SSRC field identified.  And the individual FCI combined with
>> the RTCP packet header context needs to be forwarded to the
>> identified handler.  Example of this pattern are:
>>
>> Full Intra Request (FIR):  [RFC5104] (PT=PSFB, FMT=4).
>>
>> Temporal-Spatial Trade-off Request (TSTR):  [RFC5104] (PT=PSFB,
>> FMT=5).
>>
>> Temporal-Spatial Trade-off Notification (TSTN):  This [RFC5104]
>> defined message (PT=PSFB, FMT=5) is actually a notifciation in
>> response to a TSTR this endpoint sent using the SSRC the FCI
>> identifies as source.
>>
>> H.271 Video Back Channel Message (VBCM):  [RFC5104] (PT=PSFB,
>> FMT=7).
>>
>> Layer Refresh Request (LRR):  [I-D.ietf-avtext-lrr] (PT=PSFB,
>> FMT=TBD).
>>
>> Descriptive or Notifications for an incoming RTP stream:  There
>> exist some RTCP packet types that provides additional information
>> or notifies about events related to the RTP stream identified.  In
>> these cases the RTP stream is identified using the SSRC field
>> value, and the information is provided to the higher layer
>> associated with the "m=" line for the incoming RTP stream as
>> identified by the current RTP stream to "m=" line table.  For this
>> type of pattern it is common that the RTCP packets and information
>> is repeated, either periodically (e.g.  SDES items), or for a
>> duration (e.g.  BYE), thus suppression of repetitions can be
>> considered.  Examples of these are:
>>
>>
>>
>>
>>
>> Name                      Expires July 31, 2017
>> [Page 6]
>>
>> Internet-Draft              Abbreviated-Title               January
>> 2017
>>
>>
>> Source Description (SDES) RTCP Packet:  The base RTP/RTCP protocol
>> [RFC3550] defines SDES RTCP packets as a way of providing per
>> source (SSRC) specific information about the source.  An SDES
>> packet contains zero or more chunks, where a chunk contains the
>> SSRC for the source being described by the one or more items
>> included in the chunk.  Forward the SDES items in each chunk to the
>> RTP stream's handler.
>>
>> Goodbye (BYE) RTCP Packet:  This RTP/RTCP protocol [RFC3550]
>> mechanism indicates that a particular RTP stream is leaving the RTP
>> session.  Thus, a most relevant event to inform the handler for
>> this RTP steam of.
>>
>> Third Party Targeted Reports or Feedback:  There exist some
>> multiparty RTP Topologies that results in that an endpoint receives
>> third party reports (SR [RFC3550], RR [RFC3550] or XR [RFC3611]) as
>> well as Feedback Messages [RFC4585] that relates to or targets an
>> SSRC that originates from another endpoint, and where the source of
>> the RTCP packet is also another endpoint. This type of packets
>> should be forwarded to the higher layer function dealing with the
>> third party reporting.  And if none exist then they can be
>> suppressed.  As the third party handler can be focused on
>> determining the conditions for the source of the reports and
>> feedback, or focused on how the RTP stream source progresses, or
>> both recommendations can't be made.
>>
>> APP Packets:  The RTCP APP Packets [RFC3550] are a mechanism that
>> enables experimentation.  The APP packet only specifies the source
>> of the packet.  Thus this information can be related to any of the
>> "m=" lines, thus deliver a copy of the packet to each "m=" line or
>> an APP specific handler.
>>
>> -- 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]
>> ----------------------------------------------------------------------
>>
>>
>>
_______________________________________________
>> mmusic mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>

-- 

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 19:43:33 +0000

Hi,

>> to an m= line, but whose PT is not valid for that m= line?

I don't think that case is specific to BUNDLE, is it? It could happen even without multiplexing.

I agree with Magnus that it should be treated as an error.

(There could even be cases where the PT isn't valid for ANY m- line).

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 1 Feb 2017 20:02:25 +0000

> On Feb 1, 2017, at 10:21 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Jonathan,
> 
> So, the text in JSEP-18 didn't specify this either. However, I do have an opinion on this.
> 
> I would recommend against this due to that we will have to go into under which circumstances that one can accept this, and when not. Bo Burman and I had some discussion on this. We arrived at some relevant aspects of this. The first is that one have one to consider precedence rules between PTs, as well as a=ssrc and MID. In general we think mismatch between the information is to be considered an error. However, using PT and MID could cause strange error cases, where packets without MID ends up in on m= line with the PT and the ones with MID are dropped as inconsistent. I would claim that this stream is always in error.
> 
> I would also note that Bundle specification currently forbids PT based switching, but for a different reasons. Section 10.1 says:
> 
> But, we do note that the limitation is not strictly necessary in regards to the motivation. The minimal limitation based on the motivation would be to require that a SSRC only uses PTs of the same media type and clock rate within a single bundle group. Using shared PTs, which the current limitation requires automatically meets that goal, and is easier to check for.

Okay, that’s reasonable, I think.

> We also noted that BUNDLE should clarify how MID relates to a=ssrc (RFC5576). My interpretation is that a=ssrc locks a RTP stream to a particular m= line, and can't be moved. So any MID value other than that matches the m= line that has the a=ssrc value would be an error case. For usages that intend to have a RTP stream to bounce between m= lines should not use a=ssrc, only MID. I think it would be good to clarify this in the BUNDLE specification.

That seems reasonable, but it’s not what your proposed algorithm does, as far as I can tell.  Receiving a MID for a different m= line moves the source, regardless of how the source initially ended up associated. 

> To conclude: No, as it would cause several additional complexities and possible branches in the algorithm. The use case for moving SSRCs between m= lines are supported when using MID, and the m= lines are correctly configured with shared PTs.
> 
> Cheers
> 
> Magnus
> 
>>

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 1 Feb 2017 20:03:21 +0000

Well, yes, clearly if the source is sent with a PT that isn’t in any m-line in the bundle, or with a PT that’s non-unique and isn’t in the m-line it’s currently associated with, it’s an error.

The question was whether we wanted to treat the unique PT case specially, but I can appreciate Magnus’s argument that we shouldn’t.

I’d like to hear comment from the folks who’ve been arguing in favor of PT-based mapping, though.  (I get the feeling that Magnus is agreeing to it only grudgingly.)

> On Feb 1, 2017, at 2:43 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 20:16:48 +0000

Hi,

...

>I’d like to hear comment from the folks who’ve been arguing in favor of PT-based >mapping, though.  (I get the feeling that Magnus is agreeing to it only grudgingly.)

My understanding of Magnus' text is that, at any given time, there will only be ONE mapping mechanism. So, if e.g, MID is used for mapping, and the RTP packet is mapped to an m- line for which the PT value hasn't been defined, it should be treated as an error.

I don't think one should "switch" to another mapping mechanism and see whether an m- line for that PT is found.

Regards,

Christer

>>> (without a MID) is received for a stream that has an existing 
>>> mapping to an m= line, but whose PT is not valid for that m= line?
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Feb 2017 12:41:55 -0800

*Any* RTP packet routed to an m-line needs to have a PT field that is valid for that m-line. This is true whether the routing was done via MID match, SSRC match or PT match. 

Also, Magnus mentioned a case where a BYE is received for an SSRC then subsequently the SSRC is reused, potentially with a new MID and/or PT.

Does the proposed text handle this? I do not think so. SSRC entries that are "latched" need to be removed when a BYE is received.

> On Feb 1, 2017, at 11:43 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Feb 2017 10:25:46 +0100

>> particular m= line, and can't be moved. So any MID value other than
>> that matches the m= line that has the a=ssrc value would be an
>> error case. For usages that intend to have a RTP stream to bounce
>> between m= lines should not use a=ssrc, only MID. I think it would
>> be good to clarify this in the BUNDLE specification.
>
> That seems reasonable, but it’s not what your proposed algorithm
> does, as far as I can tell.  Receiving a MID for a different m= line
> moves the source, regardless of how the source initially ended up
> associated.
>

No, this was something that was realized in the discussion that I had 
with Bo after your question. And, I think a possible way to realize this 
is to add to the entries in the table RTP stream to "m=" line a property 
"set by a=ssrc" that makes the entry immutable, with the exception for 
SDP signalling updates. That way one can also handle if RTCP BYE should 
after a timeout remove the entry from this table, which is what Bernard 
asked about.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Feb 2017 10:29:26 +0100

Den 2017-02-01 kl. 21:41, skrev Bernard Aboba:
> *Any* RTP packet routed to an m-line needs to have a PT field that is
> valid for that m-line. This is true whether the routing was done via
> MID match, SSRC match or PT match.

Agreed.

>
> Also, Magnus mentioned a case where a BYE is received for an SSRC
> then subsequently the SSRC is reused, potentially with a new MID
> and/or PT.
>
> Does the proposed text handle this? I do not think so. SSRC entries
> that are "latched" need to be removed when a BYE is received.
>

Yes, that is not covered here. I think this could be clarified. There 
needs to exist a timeout before the entry is actually removed, to avoid 
rebinding in case of packet re-order. Thus the regular SSRC timeout 
should be sufficient for this, i.e. 5*Td (using timeout mins). However, 
I think also this case needs to consider a=ssrc. If a=ssrc is set, then 
the RTP stream to m= line mapping is maintained, until signalling change.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Thu, 2 Feb 2017 12:49:12 +0000

Hi Magnus,
Is there a need to specify the mapping for the simulcast case where the rid identify the mapping in the m-line?
Roni

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: יום ו 27 ינואר 2017 18:43
> To: mmusic (E-mail); [email-masked]; draft-ietf-mmusic-sdp-bundle-
> [email-masked]; [email-masked]
> Subject: [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP
> With Correct SDP Media Description
> 
> MMUSIC and RTCWEB,
> 
> Here is now a more complete text proposal that also considers the RTCP.
> It also goes further than what Appendix B defines in one aspect, namely
> explicitly considering third party RTCP reporting and what to do with it.
> 
> Feedback is much appreciated. I plan to put this into a PR towards JSEP
> APPENDIX B on monday. If only to get the JSEP authors attention ;-).
> However, the text is really intended for the next version of BUNDLE.
> 
> 
>     streams [RFC7656].  Each RTP stream is identified by an SSRC value,
>     and each RTP packet carries an SSRC value that is used to associate
>     the packet with the correct RTP stream.  RTCP packets also uses SSRCs
>     to identify on which RTP streams any report or feedback relate to.
>     Thus, an RTCP packet will commonly carry multiple SSRC values, and
>     might therefore be providing feedback or report on 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.
> 
>     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.  However, there are cases where each "m=" line has unique
>     payload type values, and then the payload type could serve as
>     indicator to the relevant "m=" line the RTP stream is associated
>     with.
> 
>     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
> 
> 
> 
> Name                      Expires July 31, 2017                 [Page 2]
> 

> Internet-Draft              Abbreviated-Title               January 2017
> 
> 
>     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 includes the
>     identification-tag (provided by the remote peer) associated with an
>     "m=" line in the RTP Streams and in RTCP SDES packets part of a
>     BUNDLE group.
> 
>     The mapping from an SSRC to an identification-tag is carried in RTCP
>     SDES packets or in RTP header extensions (Section 14).  Since a
>     compound RTCP packet can contain multiple RTCP SDES packets, and each
>     RTCP SDES packet can contain multiple chunks, an RTCP packet can
>     contain several SSRC to identification-tag mappings.  The offerer and
>     answerer maintain tables mapping RTP streams identified by SSRC to
>     "m=" lines identified by the identification-tag.  These tables are
>     updated each time new information that affects how packets should be
>     processed and routed are received.
> 
>     To prepare for demultiplexing RTP streams to the correct "m=" line,
>     the following steps MUST be followed for each BUNDLE group based on
>     the SDP signalling information.
> 
>        receiving in that "m=" line.  If any payload type is configured
>        for receiving in more than one "m=" line in the BUNDLE group, do
>        not it include it in the table.
> 
>     Note that for each of these tables, there can only be one mapping for
>     any given key (MID, SSRC, or PT).  In other words, the tables are not
>     multimaps.
> 
>     As "m=" lines are added or removed from the BUNDLE groups, or their
>     configurations are changed, the tables above MUST also be updated.
> 
> 
> 
> Name                      Expires July 31, 2017                 [Page 3]
> 

> Internet-Draft              Abbreviated-Title               January 2017
> 
> 
>     Received RTP packets that are syntactically correct are processed by
>     the RTP/RTCP protocol implementation for statistics etc.  After this
>     processing they need to be routed to the higher layer context
>     associated with the "m=" line within the BUNDLE group.  Somewhere in
>     the process where an received RTP packet is processed to be delivered
>     to the higher layer by RTP the matching step below MUST be performed:
> 
>     1.  Reception of an RTP packet for an RTP stream that has an existing
>         mapping in the RTP stream to m= line table.  Before proceeding in
>         delivering the packet to the higher layer context according to
>         the RTP stream to "m=" line mapping table the following checks
>         MUST be performed:
> 
>             value that is not in the table mapping MID to "m=" line, then
>             do not deliver the RTP packet to higher layers.
> 
>             value that is in the table mapping MID to "m=" line, and the
>             value indicates a different "m=" line than the current RTP
>             stream to "m=" line mapping table, then update the RTP stream
>             to "m=" line mapping.
> 
>     2.  Reception of an RTP packet for an RTP stream that has no existing
>         mapping to an m= line.  In this case the following actions MUST
>         be performed:
> 
>             value that is in the table mapping MID to "m=" line, then
>             create an entry in the RTP stream to "m=" line mapping table
>             for this RTP stream (SSRC).  Then deliver the RTP packet to
>             the "m=" line context of the created mapping and stop.
> 
>             type table, then create an entry in the RTP stream to "m="
>             line mapping table for this RTP stream (SSRC).  Then deliver
>             the RTP packet to the "m=" line context of the created
>             mapping and stop.
> 
>         C.  Otherwise do not deliver the RTP packet to higher layers.
>             Note, this includes unknown MID values.
> 
>     processed by the RTP/RTCP implementation and relevant information and
>     data from the RTCP packets needs to be routed to the appropriate
>     handler for the related RTP streams.  The appropriate handler is
>     determined by using the RTP stream to "m=" line mapping table.
> 
> 
> 
> Name                      Expires July 31, 2017                 [Page 4]
> 

> Internet-Draft              Abbreviated-Title               January 2017
> 
> 
>     contains SDES MID entries, this can results in updates and additions
>     to the RTP stream to "m=" line mapping table.  Thus each of the SDES
>     MID items are processed and the current table entries are checked if
>     the corresponding MID value matches the current RTP stream to "m="
>     line mapping, else the entry is updated.  If there is no RTP stream
>     to "m=" line table mapping entry for the received SDES item's SSRC,
>     such an entry is created.  Note, that in the process of updating the
>     table entries, update flap suppression as discussed in Section 4.2.6
>     of [RFC7941] should be considered.
> 
>     the RTP streams in a couple of different ways.  The currently known
>     patterns are the following:
> 
>        of several types identified as relating to an outgoing stream.
>        The basic pattern for these blocks are that the RTCP packet header
>        identifies the source of the reports, as identified by an SSRC,
>        and containing one or more report blocks, where each report block
>        For this pattern the relevant report information is provided to
>        the higher layer associated with the "m=" line the RTP Stream to
>        "m=" line table identifies.  The source SSRC as identifier of the
>           report blocks from RFC3550 start with the SSRC of the RTP
>           stream they report on.
> 
>        Extended Reports (XR):  RFC3611 is a framework that enables a
>           large number of different reports.  However, a large number of
>           these report formats are reporting on specific RTP streams and
>           thus each individual report of these types contains a SSRC
>           field to identify the RTP stream.
> 
>     RTCP Feedback Messages for outgoing RTP streams:  The RFC 4585 RTCP
>        feedback messages allow for a number of different type of feedback
>        messages.  However, the RTCP feedback message header contains the
>        SSRC identifying the source of the feedback messages as well as
>        the actual type of the feedback.  Some of the feedback messages
>        also uses the target SSRC field in the header to identify which
> 
> 
> 
> Name                      Expires July 31, 2017                 [Page 5]
> 

> Internet-Draft              Abbreviated-Title               January 2017
> 
> 
>        RTP stream the feedback is related to.  For these types all the
>        FCI entries, if multiple ones are forwarded to the identified
>        handler.  Examples of this pattern are:
> 
>        Control Information (FCI).  Here each FCI needs to be processed
>        and the SSRC field identified.  And the individual FCI combined
>        with the RTCP packet header context needs to be forwarded to the
>     Descriptive or Notifications for an incoming RTP stream:  There exist
>        some RTCP packet types that provides additional information or
>        notifies about events related to the RTP stream identified.  In
> Name                      Expires July 31, 2017                 [Page 6]
> 

> Internet-Draft              Abbreviated-Title               January 2017
> 
> 
>           included in the chunk.  Forward the SDES items in each chunk to
>           the RTP stream's handler.
> 
>           mechanism indicates that a particular RTP stream is leaving the
>           RTP session.  Thus, a most relevant event to inform the handler
>           for this RTP steam of.
> 
>        multiparty RTP Topologies that results in that an endpoint
>        receives third party reports (SR [RFC3550], RR [RFC3550] or XR
>        [RFC3611]) as well as Feedback Messages [RFC4585] that relates to
>        or targets an SSRC that originates from another endpoint, and
>        where the source of the RTCP packet is also another endpoint.
>        This type of packets should be forwarded to the higher layer
>        function dealing with the third party reporting.  And if none
>        exist then they can be suppressed.  As the third party handler can
>        be focused on determining the conditions for the source of the
>        reports and feedback, or focused on how the RTP stream source
>        progresses, or both recommendations can't be made.
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 Feb 2017 15:19:55 -0700

> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox <[email-masked]> wrote:
> 
> I have one question, however.  What should happen if an RTP packet (without a MID) is received for a stream that has an existing mapping to an m= line, but whose PT is not valid for that m= line?
> 
> Should it
> 1. Cause the stream’s mapping to be moved to another m= line, if the received PT is in the payload type table for some other m= line?
> or 
> 2. Be an error?

Imagine a case where we have two sends call A and B and they each use one PT that is unique and go to different m lines on receiver C via a SFU.  Initially C get a packet from B with a given SSRC and the PT and creates a mapping for it. But imagine that A and B had an SSRC collision which they sort that out and A ends up having the SSRC that B initially used. If you don't have the PT override the SSRC, the packets are going to go to the wrong m-line because the PT points at the m-line A is using but the old SSRC incorrectly points at the m-line B is using. 

To put this a different way, if the packet has a mid, I think it is very clear the mid has to override the PT. Same for the PT. The mid is effectively just an extended PT. 

I'm not thinking to much about the case where SSRC is signalled in SDP but ignoring that case for a second, I think the really easy thing to specify, implement, and understand works is simply a priority order where roughly 

1) if you have mid, use that and latch the SSRC
2) if you have a unique pt, use that and latch the SSRC 
3) if you have a latched SSRC use that 

If you had signaled SSRC, guess I would insert that as step 1.5 of use that

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 2 Feb 2017 22:19:52 +0000

So I much prefer the current text and think there are a bunch of problems with this text. If we actually had emails explaining what problems in the current text this was trying to fix, with individual PRs for those, this would be much easier to resolve each of them and get them fixed.

1) we have been trying to avoid the use of "RTP session" as it has been very unclear to implementors what it is. I think this would be better if we could rephrase to not use that

2) both the proposed and current text seem lacking in dealing with multiple bundle groups 

3) Stats are typically maintained by things after the packet is routed - not before. 

4) Need to explain how the SDES in compound RTCP causes updates 

5) given this removes the outgoing SSRC table, not clear how it routes RTCP reports. I think this needs to be clarified. 

6) I don't think most implementers are going to have a clue what to do for the "Third Party Targeted Reports or Feedback" section

I will try and take your PR and break it up into some bit size pieces so we can try and see if we can get the easy ones out of the way and focus on the parts that are key changes. 

> On Jan 30, 2017, at 6:18 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> I have now generated a pull request for this text, with some very minor changes.
> 
> https://github.com/rtcweb-wg/jsep/pull/538
> 
> Cheers
> 
> Magnus
> 
> Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund:
>> MMUSIC and RTCWEB,
>>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 2 Feb 2017 23:25:14 +0100

2017-02-02 23:19 GMT+01:00 Cullen Jennings <[email-masked]>:
> But imagine that A and B had an SSRC collision

Very likely :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Feb 2017 19:43:09 -0800

Assuming the collision is detected and B sends a BYE then once the SSRC latch is removed then A's packets will match on PT, a new SSRC latch is put in place and everything works.

> On Feb 2, 2017, at 2:19 PM, Cullen Jennings <[email-masked]> wrote:
> 
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 3 Feb 2017 09:46:52 +0100

> Imagine a case where we have two sends call A and B and they each use one PT that is unique and go to different m lines on receiver C via a SFU.  Initially C get a packet from B with a given SSRC a…

Sorry if I am late to the party and I say something stupid, but 
shouldn't the SFU terminate RTP/RTCP streams and rewrite PT, packet 
numbers *AND* SSRC? so the SFU SHALL ensure in this case that there is 
no SSRC collision on C.

Best regards
Sergio

---

From: Kevin Dempsey <[email-masked]>
Date: Fri, 3 Feb 2017 10:42:19 +0000

I always thought of the MID as a port extension, since without bundle the
port would identify the m= line. It that case would the priority be:
1) MID
2) latched SSRC
3) signalled SSRC
4) unique PT

On 3 February 2017 at 08:46, Sergio Garcia Murillo <
[email-masked]> wrote:

>> Imagine a case where we have two sends call A and B and they each use one
>> PT that is unique and go to different m lines on receiver C via a SFU.
>> Initially C get a packet from B with a given SSRC and the PT and creates a
>> mapping for it. But imagine that A and B had an SSRC collision which they
>> sort that out and A ends up having the SSRC that B initially used. If you
>> don't have the PT override the SSRC, the packets are going to go to the
>> wrong m-line because the PT points at the m-line A is using but the old
>> SSRC incorrectly points at the m-line B is using.
>>
>>
> Sorry if I am late to the party and I say something stupid, but shouldn't
> the SFU terminate RTP/RTCP streams and rewrite PT, packet numbers *AND*
> SSRC? so the SFU SHALL ensure in this case that there is no SSRC collision
> on C.
>
> Best regards
> Sergio
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Feb 2017 10:42:30 +0000

Hi,

>2) both the proposed and current text seem lacking in dealing with

No matter what text we move forward with, I think it shall be explicitly
said that the procedures are per IP address:port. So, if you have multiple
bundle groups, you will apply the procedures to each group, independent of
each other.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Feb 2017 11:25:00 +0000

Hi,

Wherever the streams origin, all streams associated with a bundle group
(received by C) by definition belong to the same RTP session (no matter
whatever we want to use that wording or not), so SSRC collision cannot
occur (if it does, it¹s an error).

As Sergio said, the SFU needs to handle it.

Šuntil we publish draft-bundle-with-multiple-rtp-streams, at least.

Regards,

Christer

On 03/02/17 10:46, "rtcweb on behalf of Sergio Garcia Murillo"
<[email-masked] on behalf of [email-masked]>
wrote:

>> Imagine a case where we have two sends call A and B and they each use
>>one PT that is unique and go to different m lines on receiver C via a
>>SFU.  Initially C get a packet from B with a given SSRC and the PT and
>>creates a mapping for it. But imagine that A and B had an SSRC collision
>>which they sort that out and A ends up having the SSRC that B initially
>>used. If you don't have the PT override the SSRC, the packets are going
>>to go to the wrong m-line because the PT points at the m-line A is using
>>but the old SSRC incorrectly points at the m-line B is using.
>>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Feb 2017 15:20:54 +0100

Hi,

Thanks for the feedback. Sorry for my delay in responding, a cold have
kept from work.

Den 2017-02-02 kl. 23:19, skrev Cullen Jennings (fluffy):
>
> So I much prefer the current text and think there are a bunch of
> problems with this text. If we actually had emails explaining what
> problems in the current text this was trying to fix, with individual
> PRs for those, this would be much easier to resolve each of them and
> get them fixed.
>
> 1) we have been trying to avoid the use of "RTP session" as it has
> been very unclear to implementors what it is. I think this would be
> better if we could rephrase to not use that

Okay, but the RTP session is very easy to make clear in the context in
of BUNDLE, where this text is intended to be. I can improve that.

> 2) both the proposed and current text seem lacking in dealing with

Okay, that can be fixed by clarifying that each bundle group results in
its own RTP session, thus the procedures in this is per bundle group.

> 3) Stats are typically maintained by things after the packet is

So this comes a question of ones view of RTP stack and the question of
layering. And this is exactly why I think the current text is
problematic. It takes one very particular view, why I attempted to be
much more neutral on which order things happens. There are a number of
functions that are in the RTP protocol layer, not in the higher layers.
There are however some things, like XR VoIP metrcis that are metrics in
the higher layers. So, yes this is not clear cut. I think ones view of
this depends on if one have a very integrated RTP implementation, then
what you say makes sense, but if one has a very layered and modularized
design, then my viewpoint makes more sense.

  From my perspective the most important thing here is that this text if
it contains any RFC 2119 words can't prevent some possible
implementation choices of the RTP stack.

> 4) Need to explain how the SDES in compound RTCP causes updates

I can attempt to clarify this. However, there is a potential issue here
in that some implementations may not be able to force the receiver to
process the content of the SDES RTCP packet prior to some or even all
the other RTCP packets in a compound packet.

What in the current text:

Is insufficient in that regards. Is it only the placement prior to the
individual RTCP packet types that is the issue? Should with the
exception of the first sentence be moved under the SDES text?

> 5) given this removes the outgoing SSRC table, not clear how it
> routes RTCP reports. I think this needs to be clarified.
>

Okay, I think I understand that. I have an implicit assumption that the
implementation knows how its local (outgoing) RTP Streams are related to
the media sources and thus the related RTPsender. I can update the text
to address this.

> 6) I don't think most implementers are going to have a clue what to
> do for the "Third Party Targeted Reports or Feedback" section
>

I can understand that, but I think it is important to call out that this
bucket do exist, and if you don't know what to do I think it is fine to
ignore these.

> I will try and take your PR and break it up into some bit size pieces
> so we can try and see if we can get the easy ones out of the way and
> focus on the parts that are key changes.
>

Ok, I have seen that you generated a lot of individual issues, I will 
attempt to look through them and comment if there are things that was 
unintentional or where I have additional aspects to add.

I intend to update my PR based on the feedback I received.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Feb 2017 15:20:58 +0100

Hi,

Please see below for my feedback on this.

Den 2017-02-02 kl. 23:19, skrev Cullen Jennings:
>> line, if the received PT is in the payload type table for some
>> other m= line? or 2. Be an error?
>
>
> SFU.  Initially C get a packet from B with a given SSRC and the PT
> and creates a mapping for it. But imagine that A and B had an SSRC
> collision which they sort that out and A ends up having the SSRC that
> B initially used. If you don't have the PT override the SSRC, the
> packets are going to go to the wrong m-line because the PT points at
> the m-line A is using but the old SSRC incorrectly points at the
> m-line B is using.
>
> To put this a different way, if the packet has a mid, I think it is
> very clear the mid has to override the PT. Same for the PT. The mid
> is effectively just an extended PT.
>
> I'm not thinking to much about the case where SSRC is signalled in
> SDP but ignoring that case for a second, I think the really easy
> thing to specify, implement, and understand works is simply a
> priority order where roughly
>

The issue as I see it is when and how you update the RTP stream to m= 
line mapping table. I think we have to be clear and separate the actions 
for how the RTP stream to m= line table is built and how it is updated.

Signalling:

Build mid to m= line table
If a=ssrc is used, enter SSRC in RTP stream to m= line table. Add flag 
(signalled) to entry.

On Reception of RTP stream not in RTP stream to m= line table:

1) if you have mid, use that and add to RTP stream table.
2) if you have a unique pt, use that and add to RTP stream table

If the RTP stream is in the RTP stream to m= line table. On RTP packet 
reception check if update is needed:

1) New MID, then update RTP stream entry, unless signalled
2) If PT indicates different m= line, update entry unless signalled or 
set by MID.

The point of looking on the problem from this direction is that we 
actually need to care about what set the entry originally and if it has 
precedence.

Yes, the question of how one removes or updates stale entries are 
important. But this brings out the question for the above. Is an entry 
set by MID to be overwritten by a PT change? Yes, it will be possible to 
construct edge cases where one or the other approach will be 
sub-optimal. However, I think biasing the usage for working correctly 
with MID and having sub-optimal behaviors in other cases that can be 
avoided by for example the SFU not making bad choices, like not 
suppressing SSRC collisions between the different SSRC spaces.

So entry updates are happening for the following reasons.

New SDP: Remove all signalled entries not explicitly included in new 
signalling message. Explicitly listed entries are updated to indicate 
the correct m= line.

RTCP BYE: Remove SSRC from table (using timeout procedure to avoid RTP 
packet reordering from reinstating entry), unless signalled?

SSRC timeout. If the SSRC times out on RTP/RTCP level, then the entry is 
also removed, unless signaled.

Cheers

Magnus Westerlund

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 15 Feb 2017 13:09:56 +0000

To try and help get you text merged in, I separated your text up into a bunch of PRs so that the diffs were all clear and each PR tried to deal with one issue. There are all in github now and commenting on theses would probably be the easies way to get to some combined text. 

> On Feb 14, 2017, at 7:20 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> Ok, I have seen that you generated a lot of individual issues, I will attempt to look through them and comment if there are things that was unintentional or where I have additional aspects to add.
>