Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling
Flemming Andreasen <fandreas@cisco.com> Wed, 30 August 2017 20:45 UTC
Return-Path: <fandreas@cisco.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 3E5511252BA for <mmusic@ietfa.amsl.com>; Wed, 30 Aug 2017 13:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 G6pjQ0Tt5YXG for <mmusic@ietfa.amsl.com>; Wed, 30 Aug 2017 13:45:30 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B4D132027 for <mmusic@ietf.org>; Wed, 30 Aug 2017 13:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26133; q=dns/txt; s=iport; t=1504125929; x=1505335529; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ac3t0hR0TtobIh0DZtMiiT8rP8cm+g03eylij4z/Epw=; b=POTeH5aOXFbWxe+mUbWAxDqzbTx8Qm1LqF8V5fBOHj9sy7srxtCFFZQG HyHaE55zenruwEcIShxpL1KSHBonii1SdWL+xA0Bpi6rWIVcKx4pBgHMH VPbozO50ugJaavr5/bk8f/MFhcm0aNtpXwjPVak32sbkHTeMt5RryW1Th 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAAAKI6dZ/5RdJa1UChkBAQEBAQEBAQEBAQcBAQEBAYNaZIEVjhWQHoFPIneVMA6CAQMhC4RMTwKEJz8YAQIBAQEBAQEBayiFGAEBAQEDAQEYDQsBBS8HCwwECxEEAQEBFRIHJx8JCAYBDAYCAQEQihANEK8VOotEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKoICgU6BYysLgj01hDAaE1eFNQEEmBeIVYdZgRKBfkmJGoIShWeDWYFNhUyJd4xMHziBDVMkFUmFGByCAyQ2iwwBAQE
X-IronPort-AV: E=Sophos;i="5.41,450,1498521600"; d="scan'208";a="479062327"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 20:45:27 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7UKjR6S004428; Wed, 30 Aug 2017 20:45:27 GMT
To: Christer Holmberg <christer.holmberg@ericsson.com>, Colin Perkins <csp@csperkins.org>
Cc: "mmusic (E-mail)" <mmusic@ietf.org>
References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> <CD0864D0-22F6-492D-BEE2-20BC25F6435C@csperkins.org> <D5C9C96B.2065C%christer.holmberg@ericsson.com>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <e26e012d-2019-ded1-2c04-9bc729050cc4@cisco.com>
Date: Wed, 30 Aug 2017 16:45:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <D5C9C96B.2065C%christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/F9_tKTpIqGaXkJEDC4Ml4hvACXA>
Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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, 30 Aug 2017 20:45:34 -0000
As you said Christer, nobody has objected or provided an alternative suggestion, so please proceed with the suggested text. Thanks -- Flemming (as MMUSIC co-chair) On 8/28/17 6:17 AM, Christer Holmberg wrote: > Hi, > > Nobody has objected to Colin¹s text, so my suggested is to now merge the > PR. > > Regards, > > Christer > > > > On 18/07/17 16:42, "Colin Perkins" <csp@csperkins.org> wrote: > >> Hi Christer, >> >> As discussed - pull request submitted. >> Colin >> >> >> >>> On 9 Apr 2017, at 08:54, Christer Holmberg >>> <christer.holmberg@ericsson.com> wrote: >>> >>> Hi Colin, >>> >>> Thanks for your input! >>> >>> Would it be possible for you to create a pull request with your >>> suggested changes? >>> >>> BUNDLE can be found at: https://github.com/cdh4u/draft-sdp-bundle >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perkins >>> Sent: 07 April 2017 20:06 >>> To: mmusic (E-mail) <mmusic@ietf.org> >>> Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling >>> >>> I have some comments on BUNDLE -37 - apologies that I wasn¹t able to >>> participate fully in the mailing list discussion before the meeting. >>> >>> The current text is generally reasonably clear, and is certainly >>> precisely written, but I do think it has some problems. Most of these >>> relate to the issue of whether RTP packets or RTP streams are being >>> processed. I think it¹s important that this draft is written in terms of >>> how to associate RTP streams with m= lines, rather than how to route and >>> demultiplex RTP packets, since RTP packet routing and demultiplexing is >>> already specified by the various RTP specifications. In particular, >>> there are some places where the draft as written conflates the two >>> layers in ways that conflict with the RTP and RTCP specifications, that >>> I¹ve tried to correct by more cleanly separating the layers. >>> >>> I¹ve tried to write my suggestions in a prescriptive manner, keeping to >>> the style of the existing text where possible. Hopefully the result is >>> clear and understandable. >>> >>> Comments line below: >>> >>>> 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description >>>> >>>> NOTE: The text in this section is copied from Appendix B of JSEP. >>>> The community has not yet agreed on the text. >>>> >>>> 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 includes an SSRC field that is used to associate >>>> the packet with the correct RTP stream. RTCP packets also use SSRCs >>>> to identify which RTP streams the packet relates to. However, a RTCP >>>> packet can contain multiple SSRC fields, in the course of providing >>>> feedback or reports on different RTP streams, and therefore can be >>>> associated with multiple such 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=" >>>> >>>> >>>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 20] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> 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 use 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. >>>> >>>> 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 associated with an "m=" line (provided by the remote peer) into >>>> RTP and RTCP packets associated with a BUNDLE group. >>>> >>>> When using this mechanism, the mapping from an SSRC to an >>>> identification-tag is carried in RTP header extensions or RTCP SDES >>>> packets, as specified in section 14. Since a compound RTCP packet >>>> can contain multiple RTCP SDES packets, and each RTCP SDES packet can >>>> contain multiple chunks, a single RTCP packet can contain several >>>> SSRC to identification-tag mappings. The offerer and answerer >>>> maintain tables used for routing that are updated each time an RTP/ >>>> RTCP packet contains new information that affects how packets should >>>> be routed. >>> The text above looks good. In particular, it correctly focusses on >>> associating RTP streams with m= lines, which is the correct level of >>> abstraction. >>> >>>> However, some implementations of may not include this identification- >>>> tag in their RTP and RTCP traffic when using the BUNDLE mechanism, >>>> and instead use a payload type based mechanism for demuxing. In this >>> The term ³demuxing² is unclear. For precision, I suggest changing ³use >>> a payload type based mechanisms for demuxing² to ³use a payload type >>> based mechanism to associate RTP streams with SDP m= lines². >>> >>>> situation, each "m=" line MUST use unique payload type values, in >>>> order for the payload type to be a reliable indicator of the relevant >>>> "m=" line for the RTP stream. Note that when using payload type >>>> based demuxing, >>> Similarly, for precision, I suggest changing ³when using payload type >>> based demuxing² to ³when using the payload type to associate RTP streams >>> with m= lines². >>> >>>> an SSRC will be mapped to an ³m=³ line >>> Suggest changing to ³an RTP stream, identified by SSRC, will be >>> mappedŠ² to be clear what¹s being done. >>> >>>> by the first >>>> packet with that SSRC, and the mapping will not be changed even if >>> Suggest changing to ³when the first RTP packet of that RTP stream is >>> received, andŠ² to be clear, since there could be RTCP packets with the >>> same SSRC. >>> >>>> the same SSRC is received with a different payload type. In other >>> Suggest changing to ³the payload type used by that RTP stream changes. >>> In other² to be precise. >>> >>>> words, the SSRC cannot to "move" to a different "m=" line simply by >>>> changing the payload type. >>>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 21] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> Applications can implement RTP stacks in many different ways. The >>>> algorithm below details one way that demultiplexing can be >>>> accomplished, but is not meant to be prescriptive about exactly how >>> To be clear about what is being demultiplexed, I suggest changing ³one >>> way that demultiplexing can be accomplished² to ³one way that RTP >>> streams can be associated with m= lines². >>> >>>> an RTP stack needs to be implemented. Applications MAY use any >>>> algorithm that achieves equivalent results to those described in the >>>> algorithm below. >>>> >>>> To prepare for demultiplexing RTP/RTCP packets to the correct "m=" >>>> line, the following steps MUST be followed for each BUNDLE group. >>> I suggest changing ³Šprepare for demultiplexing RTP/RTCP packets to the >>> correctŠ² to ³Šprepare to associate RTP streams with the correctŠ². RTP >>> and RTCP packets are not demultiplexed to m= lines, they¹re >>> demultiplexed into RTP streams, and then those RTP streams are >>> associated with m= lines. The distinction is important, in order to >>> implement RTCP correctly. >>> >>>> 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 SSRC to "m=" line for each "m=" >>>> line in this BUNDLE group and for each SSRC configured for >>>> receiving in that ³m=" line. >>> The SSRC is a property of an RTP stream, so I suggest changing ³mapping >>> incoming SSRC to² to ³mapping SSRCs of incoming RTP streams to². >>> >>>> Construct a table mapping outgoing SSRC to "m=line" for each "m=" >>>> line in this BUNDLE group and for each SSRC configured for sending >>>> in that ³m=" line. >>> Similarly, change ³mapping outgoing SSRC² to ³mapping the SSRC of each >>> outgoing RTP stream² >>> >>>> Construct a table mapping payload type 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, as it cannot be used to uniquely >>>> identify a "m=" line. >>>> >>>> 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. >>>> >>>> For each RTP packet received, the following steps MUST be followed to >>>> route the packet to the correct "m=" section within a BUNDLE group. >>> The goal is not to route RTP packets to m= lines, but rather to >>> associate the corresponding RTP streams with m= lines. This keeps the >>> distinction between RTP and RTCP processing that has to happen >>> irrespective of the m= line, and the application level processing that >>> depends on the choice of m= line. I suggest changing this sentence to: >>> ³When an RTP packet is received, it MUST be delivered to the RTP stream >>> corresponding to its SSRC. That RTP stream MUST then be associated with >>> the correct m= line within a BUNDLE group, according to the following >>> steps.² >>> >>>> Note that the phrase 'deliver a packet to the "m=" line' means to >>>> further process the packet as would normally happen with RTP/RTCP, if >>>> it were received on a transport associated with that "m=" line >>>> outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd), >>>> including dropping an RTP packet if the packet's PT does not match >>>> any PT in the ³m=" line. >>> Dropping RTP packets with unknown payload type breaks RTCP. The RTP >>> packet must be processed by the RTP layer as normal, updating the >>> statistics that are maintained by RTCP. The payload is then discarded, >>> because there¹s no decoder associated with the payload type. I suggest >>> removing this part of the paragraph entirely. >>> >>>> If the packet has a MID, and that MID is not in the table mapping >>>> MID to ³m=" line, drop the packet and stop. >>> Dropping the RTP packet will break the RTCP reports. The RTP packet has >>> to be processed as normal, but the corresponding RTP stream is not >>> decoded if it¹s not associated with an ³m=³ line (i.e., you drop the >>> payload, not the RTP packet). I suggest replacing the above with >>> something like: >>> >>> If the MID associated with the RTP stream is not in the table mapping >>> MID to ³m=³ line, then the RTP stream is not decoded and the payload >>> data is discarded. >>> >>>> If the packet has a MID, and the packet's extended sequence number >>>> is greater than that of the last MID update, as discussed in >>>> [RFC7941], Section 4.2.6, update the incoming SSRC mapping table >>>> to include an entry that maps the packet's SSRC to the "m=" line >>>> for that MID. >>> There are two things that need to be done here: update the MID >>> associated with the RTP stream to match that in the newly received RTP >>> packet, and update the mapping table. I suggest changing ³update the >>> incoming SSRC mapping table to include an entry that maps the packet¹s >>> SSRC to the ³m=³ line for that MID² to ³update the MID associated with >>> the RTP stream to match the MID carried in the RTP packet, then update >>> the mapping tables to include an entry that maps the SSRC of that RTP >>> stream to the ³m=³ line for that MID². >>> >>>> If the packet's SSRC is in the incoming SSRC mapping table, check >>>> that the packet's PT matches a PT included on the associated "m=" >>>> line. If so, route the packet to that associated "m=" line and >>>> stop; otherwise drop the packet and stop. >>> Dropping the packet breaks RTCP. The RTP packet is processed as normal, >>> but the corresponding RTP stream is not decoded if it¹s not associated >>> with an ³m=³ line. I suggest replacing the above with: >>> >>> If the SSRC of the RTP stream is in the incoming SSRC mapping table, >>> check that the payload type used by the RTP stream matches a payload >>> type included on the matching ³m=³ line. If so, associate the RTP >>> stream with that ³m=³ line. Otherwise, the RTP stream is not decoded >>> and the payload data is discarded. >>> >>>> If the packet's payload type is in the payload type table, update >>>> the the incoming SSRC mapping table to include an entry that maps >>>> the packet's SSRC to the "m=" line for that payload type. In >>>> addition, route the packet to the associated ³m=" line and stop. >>> RTP packets correspond to RTP streams, and those RTP streams are >>> associated with m= lines. Suggest changing to: >>> >>> If the payload type used by the RTP stream is in the payload type >>> table, update the incoming SSRC mapping table to include an entry >>> that maps the RTP stream¹s SSRC to the ³m=³ line for that payload >>> type. Associate the RTP stream with the corresponding ³m=³ line. >>> >>>> Otherwise, drop the packet. >>> The packet cannot be discarded without breaking RTCP. I suggest >>> replacing the above with: >>> >>> Otherwise, mark the RTP stream as not for decoding and discard the >>> payload. >>> >>>> For each RTCP packet received (including each RTCP packet that is >>>> part of a compound RTCP packet), the packet MUST be routed to the >>>> ³m=³ line for the RTP streams it contains information about. This >>>> routing is type-dependent, as each kind of RTCP packet has its own >>>> mechanism for associating it with the relevant RTP streams. >>> The first sentence might be clearer written ³For each RTCP packet >>> received (including each RTCP packet that is part of a compound RTCP >>> packet), the packet is processed as usual by the RTP layer, then is >>> passed to the ³m=³ lines corresponding to the RTP streams it contains >>> information about for further processing.² >>> >>>> Packets for which no appropriate "m=" line can be identified (i.e., >>>> for unknown RTP streams) are not relevant in the context of this >>>> algorithm and MAY be dropped. This situation may occur with certain >>>> multiparty RTP topologies. >>> These packets can¹t be dropped. They setup state at the RTP layer that >>> might become relevant when further RTP/RTCP packets are received (RTCP >>> packets can round-robin SDES items, such as the MID, in some cases, so >>> these can potentially be important). I suggest changing this to: >>> >>> RTCP packets for which no appropriate ³m=³ line can be identified >>> MUST be processed as usual by the RTP layer, updating the metadata >>> associated with the corresponding RTP streams, but are not passed >>> to any ³m=³ line. This situation can occur with certain multiparty >>> RTP topologies, or when RTCP packets are sent containing a subset >>> of the SDES information. >>> >>>> Rules for handling the various types of RTCP packets are explained >>>> below. >>> Perhaps change to ³Rules for additional processing of the variousŠ², to >>> make it clear that this doesn¹t replace the usual RTCP processing. >>> >>>> If the packet is of type SDES, for each chunk in the packet whose >>> "If the RTCP packet isŠ² >>> >>>> SSRC is found in the incoming SSRC table, deliver a copy of the >>>> packet to the "m=" line associated with that SSRC. In addition, >>> ³a copy of the SDES packet² presumably, since otherwise it¹s ambiguous >>> if the entire compound RTCP packet is delivered or just the SDES packet. >>> >>>> for any SDES MID items contained in these chunks, if the MID is >>>> found in the table mapping MID to "m=" line, update the incoming >>>> SSRC table to include an entry that maps the chunk¹s SSRC to the >>> ³Šmaps the RTP stream associated with the chunk¹s SSRC toŠ² >>> >>>> "m=" line associated with that MID, unless the packet is older >>>> than the packet that most recently updated the mapping for this >>>> SSRC, as discussed in [RFC7941], Section 4.2.6. >>>> >>>> Note that if an SDES packet is received as part of a compound RTCP >>>> packet, the SSRC to "m=" line mapping may not exist until the SDES >>>> packet is handled (e.g., in the case where RTCP for a source is >>>> received before any RTP packets). Therefore, when processing a >>>> compound packet, any contained SDES packet MUST be handled first. >>> It might be worth referencing RFC 3550 section 6.1, which says: >>> >>> Each individual RTCP packet in the compound packet may be processed >>> independently with no requirements upon the order or combination of >>> packets. >>> >>> as justification for this. >>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 23] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> If the packet is of type BYE, it indicates that the RTP streams >>> ³If the RTCP packet isŠ² >>> >>>> referenced in the packet are ending. Therefore, for each SSRC >>>> indicated in the packet that is found in the incoming SSRC table, >>> ³Šin the BYE packetŠ² >>> >>>> first deliver a copy of the packet to the ³m=" line associated >>> ³Ša copy of the BYE packetŠ² >>> >>>> with that SSRC, but then remove the entry for that SSRC from the >>>> incoming SSRC table after an appropriate delay to account for >>>> "straggler packets", as specified in [RFC3550], Section 6.2.1. >>>> >>>> If the packet is of type SR or RR, for each report block in the >>> ³If the RTCP packet isŠ² >>> >>>> report whose "SSRC of source" is found in the outgoing SSRC table, >>>> deliver a copy of the RTCP packet to the ³m=" line associated with >>> ³the RTCP packet² or ³the SR or RR packet²? To avoid confusion when >>> compound RTCP packets are used, I suggest the latter phrasing here, and >>> in the later sections. >>> >>>> that SSRC. In addition, if the packet is of type SR, and the >>>> sender SSRC for the packet is found in the incoming SSRC table, >>>> deliver a copy of the packet to the ³m=" line associated with that >>> ³a copy of the SR packet²? >>> >>>> SSRC. >>>> >>>> If the implementation supports RTCP XR and the packet is of type >>>> XR, as defined in [RFC3611], for each report block in the report >>>> whose "SSRC of source" is is found in the outgoing SSRC table, >>>> deliver a copy of the RTCP packet to the ³m=" line associated with >>> ³the RTCP packet² or ³the XR packet²? >>> >>>> that SSRC. In addition, if the sender SSRC for the packet is >>>> found in the incoming SSRC table, deliver a copy of the packet to >>> ³the packet² -> ³the RTCP packet² or ³the XR packet²? >>> >>>> the "m=" line associated with that SSRC. >>>> >>>> If the packet is a feedback message of type RTPFB or PSFB, as >>> ³If the RTCP packet isŠ² >>> >>>> defined in [RFC4585], it will contain a media source SSRC, and >>>> this SSRC is used for routing certain subtypes of feedback >>>> messages. However, several subtypes of PSFB messages include >>>> target SSRC(s) in a section called Feedback Control Information >>>> (FCI). For these messages, the target SSRC(s) are used for >>>> routing. >>>> >>>> If the packet is a feedback message that does not include target >>> ³If the RTCP packet isŠ² >>> >>>> SSRCs in its FCI section, and the media source SSRC is found in >>>> the outgoing SSRC table, deliver the packet to the ³m=" line >>> Which packet? >>> >>>> associated with that SSRC. RTPFB and PSFB types that are handled >>>> in this way include: >>>> >>>> Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). >>>> >>>> Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). >>>> >>>> Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). >>>> >>>> Reference Picture Selection Indication (RPSI): [RFC4585] >>>> (PT=PSFB, FMT=3). >>>> >>>> >>>> >>>> >>>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 24] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> If the packet is a feedback message that does include target >>> ³If the RTCP packet isŠ² >>> >>>> SSRC(s) in its FCI section, it can either be a request or a >>>> notification. Requests reference a RTP stream that is being sent >>>> by the message recipient, whereas notifications are responses to >>>> an earlier request, and therefore reference a RTP stream that is >>>> being received by the message recipient. >>>> >>>> If the packet is a feedback request that includes target SSRC(s), >>> ³If the RTCP packet isŠ² >>> >>>> for each target SSRC that is found in the outgoing SSRC table, >>>> deliver a copy of the RTCP packet to the "m=" line associated with >>>> that SSRC. PSFB types that are handled in this way include: >>>> >>>> Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). >>>> >>>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, >>>> FMT=5). >>>> >>>> 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). >>>> >>>> If the packet is a feedback notification that include target >>>> SSRC(s), for each target SSRC that is found in the incoming SSRC >>>> table, deliver a copy of the RTCP packet to the "m=" line >>>> associated with that SSRC. PSFB types that are handled in this >>> ³deliver a copy of the RTCP packet to the ³m=³ line associated with the >>> RTP stream with matching SSRC² >>> >>>> way include: >>>> >>>> Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] >>>> (PT=PSFB, FMT=6). This message is a notification in response >>>> to a prior TSTR. >>>> >>>> If the packet is of type APP, the only routing information >>>> included is the source of the packet, and therefore the packet >>>> could be related to any existing "m=" line. Accordingly, deliver >>>> a copy of the packet to each ³m=" line. >>> Are APP packets exposed in the WebRTC APIs? Given that we have the data >>> channel, it¹s not clear that we want to support arbitrary application >>> information passing via RTCP. It might be better to say that APP packets >>> are processed in an application specific manner, and if the application >>> doesn¹t understand them, they¹re not passed to any m= line? >>> >>> Finally, I note that this section of the draft doesn¹t mention the CSRC >>> list anywhere, but should probably do so. As written, RTP packets with a >>> CSRC list will be delivered to the RTP stream matching their SSRC in the >>> usual way, then passed up to the m= line associated with that RTP >>> stream. That may well be sufficient, but if so it¹s likely useful to say >>> that, to make the intent clear. >>> >>> Colin >>> >>> >>> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . >
- Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling Christer Holmberg
- [MMUSIC] Comments on BUNDLE -37 - RTP handling Colin Perkins
- Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling Colin Perkins
- Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling Christer Holmberg
- Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling Magnus Westerlund
- Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling Christer Holmberg
- Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling Flemming Andreasen