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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 01 February 2017 15:22 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45797129E56; Wed, 1 Feb 2017 07:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwccZIVqtHBP; Wed, 1 Feb 2017 07:22:23 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD47129E5A; Wed, 1 Feb 2017 07:22:21 -0800 (PST)
X-AuditID: c1b4fb30-13a0498000007085-d7-5891fd2b9ee6
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id A7.36.28805.B2DF1985; Wed, 1 Feb 2017 16:22:19 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Wed, 1 Feb 2017 16:21:22 +0100
To: Jonathan Lennox <jonathan@vidyo.com>
References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <D2A63CD5-61AB-47DD-B946-6A17A94F76E7@vidyo.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <e679714c-1f09-1d01-2440-b61c7e850370@ericsson.com>
Date: Wed, 01 Feb 2017 16:21:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <D2A63CD5-61AB-47DD-B946-6A17A94F76E7@vidyo.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7k67234kRBpOfC1pMn/WOzWJ+xzo2 i/2LzzNbTF3+mMVi7b92dgdWjyVLfjJ5fLn8mc2j7dkd9gDmKC6blNSczLLUIn27BK6Myxsn sBT8nc1Y8ebyHMYGxodVXYycHBICJhJvfvazdzFycQgJrGOUODdxLhOEs4xRYtvnDawgVcIC RRIHXrYxg9giAhoSF599YAOxhYDiDdvbGUEamAWamSTu7J7CDpJgE7CQuPmjEayIV8Be4t2C H2A2i4CKxLWmZrAaUYEYiZd7VrFA1AhKnJz5BMzmFLCVOLLoF1ANB9BQe4kHW8tAwswC8hLN W2czQ+zVlmho6mCdwCgwC0n3LISOWUg6FjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQI DOCDW34b7GB8+dzxEKMAB6MSD++GexMihFgTy4orcw8xSnAwK4nwHvo9MUKINyWxsiq1KD++ qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGxjVhj2+ueFzqHvNAMlM2c+5y +89Hev/cadgSFJQ0x5vr8wbb8Du+0i+DjPQv2EyKCrmx7Exk3+v5WzJlHDnyrVlDBN/dLlZq 1agodkiZxXaj5pl06IzaUC9GtQ+B7xVnlGzXutC3QXjH1lV127ILZcQUHrTHP9tYflnDzCKq 3vrVRr9pj2tslFiKMxINtZiLihMBlKWEdFwCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/hQmWdFyKQbbuNRV5DK6n0tWqNuM>
Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" <draft-ietf-rtcweb-jsep@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>, "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" <draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org>
Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 15:22:26 -0000

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
>> <magnus.westerlund@ericsson.com> 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: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>>
>>
_______________________________________________
>> mmusic mailing list mmusic@ietf.org
>> 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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------