From nobody Wed Feb 1 07:22:27 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@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 References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> From: Magnus Westerlund Message-ID: Date: Wed, 1 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: 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: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> 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 ---------------------------------------------------------------------- From nobody Wed Feb 1 11:43:56 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0560129E92; Wed, 1 Feb 2017 11:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 II9_teIoQtVJ; Wed, 1 Feb 2017 11:43:53 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 C2E58129E8C; Wed, 1 Feb 2017 11:43:52 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-9c-58923a766afd Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 63.C9.16488.67A32985; Wed, 1 Feb 2017 20:43:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 20:43:33 +0100 From: Christer Holmberg To: Magnus Westerlund , Jonathan Lennox Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSeLyCjrr91gBvrE2+PKFOpdD0GaFS0M+AgAFqpACAAFjGoA== Date: Wed, 1 Feb 2017 19:43:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvjW651aQIg39/+Cymz3rHZjG/Yx2b xf7F55ktpi5/zGKx9l87uwOrx5IlP5k8vlz+zObR9uwOewBzFJdNSmpOZllqkb5dAlfGp84/ bAXPmSs+r7jL1MD4namLkZNDQsBE4uq5pYxdjFwcQgLrGSW2z38AlhASWMQo8W9NUBcjBweb gIVE9z9tkLCIQJxE07Y97CD1zALNTBJ3dk9hB0kICxRJTN23nwmiqFhi3cuZLBC2k0Tr9BNg NSwCKhK/Px1nBLF5BXwlvjxYwgqxeAWjxNp1H8EaOAUcJD48/cQKYjMKiEl8P7UGbCizgLjE rSfzoa4WkFiy5zwzhC0q8fLxP1YIW0micckTVoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJ jKKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjKiDW35b7WA8 +NzxEKMAB6MSD6+BwaQIIdbEsuLK3EOMEhzMSiK8DJZAId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhiDNVbcDzvSW8GV/V9d2HvRWs37pR1VYif8bjFt uKX01VYlbdEReV2Nl0HFW2Ue/0xJWHi8yVrkP8sPnlsHO2ZtNCyvcDu0QXi5bN/D9tMi0nKb pudvM/rz7pnsYauci0GZvDcnXp8vuvqF55qECAM96Rt3hC+xT4k5zLTaRaBO2jr+ZFDYzl9K LMUZiYZazEXFiQBxE7G3pAIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:43:55 -0000 Hi, >> I have one question, however. What should happen if an RTP packet=20 >> (without a MID) is received for a stream that has an existing mapping=20 >> to an m=3D line, but whose PT is not valid for that m=3D 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 nobody Wed Feb 1 12:02:36 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC7012956E; Wed, 1 Feb 2017 12:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 QHdDVnqPlxiy; Wed, 1 Feb 2017 12:02:30 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 1105D129573; Wed, 1 Feb 2017 12:02:30 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v11JxbJh009199; Wed, 1 Feb 2017 15:02:27 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 288n9qanf3-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Feb 2017 15:02:27 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 1 Feb 2017 14:02:26 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTP9MAgAFqoQCAAE6GgA== Date: Wed, 1 Feb 2017 20:02:25 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-01_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702010197 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:02:32 -0000 > On Feb 1, 2017, at 10:21 AM, Magnus Westerlund wrote: >=20 > Hi Jonathan, >=20 > Thanks for the feedback. See inline for my attempt to answer them. >=20 > Den 2017-01-31 kl. 18:43, skrev Jonathan Lennox: >> In general, this looks good. >>=20 >> 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=3D line, but whose PT is not valid for that m=3D line? >>=20 >=20 > So, the text in JSEP-18 didn't specify this either. However, I do have an= opinion on this. >=20 >> Should it 1. Cause the stream=92s mapping to be moved to another m=3D >> line, if the received PT is in the payload type table for some other >> m=3D line? or >=20 > 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=3Dssrc and MID. In general we think mismatch between the informa= tion is to be considered an error. However, using PT and MID could cause st= range error cases, where packets without MID ends up in on m=3D line with t= he PT and the ones with MID are dropped as inconsistent. I would claim that= this stream is always in error. >=20 > I would also note that Bundle specification currently forbids PT based sw= itching, but for a different reasons. Section 10.1 says: >=20 > o A given SSRC MUST NOT transmit RTP packets using payload types > that originate from different bundled "m=3D" lines. >=20 > 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=3D" 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]). >=20 > 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 limitatio= n requires automatically meets that goal, and is easier to check for. Okay, that=92s reasonable, I think. > We also noted that BUNDLE should clarify how MID relates to a=3Dssrc (RFC= 5576). My interpretation is that a=3Dssrc locks a RTP stream to a particula= r m=3D line, and can't be moved. So any MID value other than that matches t= he m=3D line that has the a=3Dssrc value would be an error case. For usages= that intend to have a RTP stream to bounce between m=3D lines should not u= se a=3Dssrc, only MID. I think it would be good to clarify this in the BUND= LE specification. That seems reasonable, but it=92s not what your proposed algorithm does, as= far as I can tell. Receiving a MID for a different m=3D line moves the so= urce, regardless of how the source initially ended up associated.=20 > > 2. Be an error? >=20 > This would be my preferred choice. >=20 >>=20 >> In other words, should it be possible for PT-mapping to cause streams >> to change their mappings? >=20 > To conclude: No, as it would cause several additional complexities and po= ssible branches in the algorithm. The use case for moving SSRCs between m= =3D lines are supported when using MID, and the m=3D lines are correctly co= nfigured with shared PTs. >=20 > Cheers >=20 > Magnus >=20 >>=20 >> (Should this decision depend on what caused the stream to be mapped >> to its current m=3D line?) >>=20 >>> On Jan 27, 2017, at 11:43 AM, Magnus Westerlund >>> wrote: >>>=20 >>> MMUSIC and RTCWEB, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> X. Associating RTP/RTCP With Correct SDP Media Description >>>=20 >>> 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. >>>=20 >>> 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=3D" line, as the "m=3D" line and SDP attributes associated with the >>> "m=3D" line contain information needed to process the packets. >>>=20 >>> 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=3D" line. In addition, multiple RTP streams might be >>> associated with the same "m=3D" line. >>>=20 >>> 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=3D" line. However, there are cases where each "m=3D" line >>> has unique payload type values, and then the payload type could >>> serve as indicator to the relevant "m=3D" line the RTP stream is >>> associated with. >>>=20 >>> 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 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 2] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> 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=3D" 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. >>>=20 >>> In order for an offerer and answerer to always be able to >>> associate an RTP stream with the correct "m=3D" 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=3D" line in the RTP Streams and in RTCP SDES packets part of a >>> BUNDLE group. >>>=20 >>> 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=3D" 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. >>>=20 >>> To prepare for demultiplexing RTP streams to the correct "m=3D" >>> line, the following steps MUST be followed for each BUNDLE group >>> based on the SDP signalling information. >>>=20 >>> Construct a table mapping MID to "m=3D" line for each "m=3D" line in >>> this BUNDLE group. Note that an "m=3D" line may only have one MID. >>>=20 >>> Construct a table mapping incoming RTP streams (SSRCs) to their >>> "m=3D" line for each "m=3D" line in this BUNDLE group and for each RTP >>> stream explicitly signalled for receiving in that "m=3D" line. >>>=20 >>> Construct a table mapping payload types to "m=3D" line for each "m=3D" >>> line in the BUNDLE group and for each payload type configured for >>> receiving in that "m=3D" line. If any payload type is configured for >>> receiving in more than one "m=3D" line in the BUNDLE group, do not it >>> include it in the table. >>>=20 >>> 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. >>>=20 >>> As "m=3D" lines are added or removed from the BUNDLE groups, or >>> their configurations are changed, the tables above MUST also be >>> updated. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 3] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> 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=3D" 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: >>>=20 >>> 1. Reception of an RTP packet for an RTP stream that has an >>> existing mapping in the RTP stream to m=3D line table. Before >>> proceeding in delivering the packet to the higher layer context >>> according to the RTP stream to "m=3D" line mapping table the >>> following checks MUST be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is not in the table mapping MID to "m=3D" line, then do >>> not deliver the RTP packet to higher layers. >>>=20 >>> B. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, and the value >>> indicates a different "m=3D" line than the current RTP stream to "m=3D" >>> line mapping table, then update the RTP stream to "m=3D" line >>> mapping. >>>=20 >>> 2. Reception of an RTP packet for an RTP stream that has no >>> existing mapping to an m=3D line. In this case the following actions >>> MUST be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, then create an >>> entry in the RTP stream to "m=3D" line mapping table for this RTP >>> stream (SSRC). Then deliver the RTP packet to the "m=3D" line >>> context of the created mapping and stop. >>>=20 >>> 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=3D" line >>> mapping table for this RTP stream (SSRC). Then deliver the RTP >>> packet to the "m=3D" line context of the created mapping and stop. >>>=20 >>> C. Otherwise do not deliver the RTP packet to higher layers. Note, >>> this includes unknown MID values. >>>=20 >>> 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=3D" line mapping >>> table. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 4] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> 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=3D" 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=3D" line mapping, else the entry is updated. If there >>> is no RTP stream to "m=3D" 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. >>>=20 >>> 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: >>>=20 >>> 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=3D" line the RTP Stream to "m=3D" >>> 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: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 5] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> 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: >>>=20 >>> Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >>>=20 >>> Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >>>=20 >>> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSFB, >>> FMT=3D3). >>>=20 >>> Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >>>=20 >>> 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: >>>=20 >>> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>>=20 >>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, >>> FMT=3D5). >>>=20 >>> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >>> defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation in >>> response to a TSTR this endpoint sent using the SSRC the FCI >>> identifies as source. >>>=20 >>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, >>> FMT=3D7). >>>=20 >>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, >>> FMT=3DTBD). >>>=20 >>> 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=3D" line for the incoming RTP stream as >>> identified by the current RTP stream to "m=3D" 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: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 >>> [Page 6] >>>=20 >>> Internet-Draft Abbreviated-Title January >>> 2017 >>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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=3D" lines, thus deliver a copy of the packet to each "m=3D" line or >>> an APP specific handler. >>>=20 >>> -- Cheers >>>=20 >>> Magnus Westerlund >>>=20 >>> ---------------------------------------------------------------------- >>>=20 >>>=20 > Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>>=20 >>>=20 > Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 >>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 > _______________________________________________ >>> mmusic mailing list mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Wed Feb 1 12:03:34 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1595129573; Wed, 1 Feb 2017 12:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sIf4dIlUawrk; Wed, 1 Feb 2017 12:03:27 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 0C2CE12956E; Wed, 1 Feb 2017 12:03:26 -0800 (PST) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v11Jx6P5003183; Wed, 1 Feb 2017 15:03:22 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 288px82xw1-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Feb 2017 15:03:22 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 1 Feb 2017 14:03:21 -0600 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTP9MAgAFqoQCAAElBgIAABYiA Date: Wed, 1 Feb 2017 20:03:21 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <821011E1FB73EE43B58A4FC338808759@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-01_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702010197 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:03:28 -0000 V2VsbCwgeWVzLCBjbGVhcmx5IGlmIHRoZSBzb3VyY2UgaXMgc2VudCB3aXRoIGEgUFQgdGhhdCBp c27igJl0IGluIGFueSBtLWxpbmUgaW4gdGhlIGJ1bmRsZSwgb3Igd2l0aCBhIFBUIHRoYXTigJlz IG5vbi11bmlxdWUgYW5kIGlzbuKAmXQgaW4gdGhlIG0tbGluZSBpdOKAmXMgY3VycmVudGx5IGFz c29jaWF0ZWQgd2l0aCwgaXTigJlzIGFuIGVycm9yLg0KDQpUaGUgcXVlc3Rpb24gd2FzIHdoZXRo ZXIgd2Ugd2FudGVkIHRvIHRyZWF0IHRoZSB1bmlxdWUgUFQgY2FzZSBzcGVjaWFsbHksIGJ1dCBJ IGNhbiBhcHByZWNpYXRlIE1hZ251c+KAmXMgYXJndW1lbnQgdGhhdCB3ZSBzaG91bGRu4oCZdC4N Cg0KSeKAmWQgbGlrZSB0byBoZWFyIGNvbW1lbnQgZnJvbSB0aGUgZm9sa3Mgd2hv4oCZdmUgYmVl biBhcmd1aW5nIGluIGZhdm9yIG9mIFBULWJhc2VkIG1hcHBpbmcsIHRob3VnaC4gIChJIGdldCB0 aGUgZmVlbGluZyB0aGF0IE1hZ251cyBpcyBhZ3JlZWluZyB0byBpdCBvbmx5IGdydWRnaW5nbHku KQ0KDQo+IE9uIEZlYiAxLCAyMDE3LCBhdCAyOjQzIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4+PiBJ IGhhdmUgb25lIHF1ZXN0aW9uLCBob3dldmVyLiAgV2hhdCBzaG91bGQgaGFwcGVuIGlmIGFuIFJU UCBwYWNrZXQgDQo+Pj4gKHdpdGhvdXQgYSBNSUQpIGlzIHJlY2VpdmVkIGZvciBhIHN0cmVhbSB0 aGF0IGhhcyBhbiBleGlzdGluZyBtYXBwaW5nIA0KPj4+IHRvIGFuIG09IGxpbmUsIGJ1dCB3aG9z ZSBQVCBpcyBub3QgdmFsaWQgZm9yIHRoYXQgbT0gbGluZT8NCj4gDQo+IEkgZG9uJ3QgdGhpbmsg dGhhdCBjYXNlIGlzIHNwZWNpZmljIHRvIEJVTkRMRSwgaXMgaXQ/IEl0IGNvdWxkIGhhcHBlbiBl dmVuIHdpdGhvdXQgbXVsdGlwbGV4aW5nLg0KPiANCj4gSSBhZ3JlZSB3aXRoIE1hZ251cyB0aGF0 IGl0IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFuIGVycm9yLg0KPiANCj4gKFRoZXJlIGNvdWxkIGV2 ZW4gYmUgY2FzZXMgd2hlcmUgdGhlIFBUIGlzbid0IHZhbGlkIGZvciBBTlkgbS0gbGluZSkuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCg0K From nobody Wed Feb 1 12:16:59 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC7129566; Wed, 1 Feb 2017 12:16:53 -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 7qqz0OpBA9d4; Wed, 1 Feb 2017 12:16:52 -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 D7AFD12956E; Wed, 1 Feb 2017 12:16:51 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-f2-589242327e5e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id ED.BD.28805.13242985; Wed, 1 Feb 2017 21:16:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 21:16:49 +0100 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSeLyCjrr91gBvrE2+PKFOpdD0GaFS0M+AgAFqpACAAFjGoP//9gOAgAAT3cA= Date: Wed, 1 Feb 2017 20:16:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8E8E@ESESSMB209.ericsson.se> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7pa6R06QIg7+feS2mz3rHZjG/Yx2b xf7F55ktpi5/zGKx9l87uwOrx5IlP5k8vlz+zObR9uwOewBzFJdNSmpOZllqkb5dAlfG571v 2Ase8VRsmP6NuYFxB08XIyeHhICJxO3uTqYuRi4OIYF1jBIXrj1jhHAWMUpcXXITKMPBwSZg IdH9TxukQURAQ+Lisw9sIDXMAjuZJN5OnM8KkhAWKJKYum8/E0RRscS6lzNZIGw/iY5X98Fs FgEViaUXloLV8wr4Stx+e5IFYtl8Jol5+xcygiQ4BWwlFryfCGYzCohJfD+1Bmwos4C4xK0n 85kgzhaQWLLnPDOELSrx8vE/VghbSaJxyRNWkKOZBTQl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gm MIrOQjJ1FkLHLCQds5B0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGE8Ht/w22MH4 8rnjIUYBDkYlHl4Dg0kRQqyJZcWVuYcYJTiYlUR4GSyBQrwpiZVVqUX58UWlOanFhxilOViU xHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTCKmit2sAskfKqp6PpyWb0x5fTeeJnVAXtuz7ba p6jAPCVx3zrhst0LX2xgu7Jd/cfP/19jFRru7goqWc7Uu8dmts950bDcX/XO94062A/azBe4 elSxw7aMb5rh3YCkM9LP1+kcD/bLCVzacDfced6+1xyBlfcCnO51bChntv5z5veFC1MnXduv xFKckWioxVxUnAgA1DZ5BaMCAAA= Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:16:53 -0000 SGksDQoNCi4uLg0KDQo+SeKAmWQgbGlrZSB0byBoZWFyIGNvbW1lbnQgZnJvbSB0aGUgZm9sa3Mg d2hv4oCZdmUgYmVlbiBhcmd1aW5nIGluIGZhdm9yIG9mIFBULWJhc2VkID5tYXBwaW5nLCB0aG91 Z2guICAoSSBnZXQgdGhlIGZlZWxpbmcgdGhhdCBNYWdudXMgaXMgYWdyZWVpbmcgdG8gaXQgb25s eSBncnVkZ2luZ2x5LikNCg0KTXkgdW5kZXJzdGFuZGluZyBvZiBNYWdudXMnIHRleHQgaXMgdGhh dCwgYXQgYW55IGdpdmVuIHRpbWUsIHRoZXJlIHdpbGwgb25seSBiZSBPTkUgbWFwcGluZyBtZWNo YW5pc20uIFNvLCBpZiBlLmcsIE1JRCBpcyB1c2VkIGZvciBtYXBwaW5nLCBhbmQgdGhlIFJUUCBw YWNrZXQgaXMgbWFwcGVkIHRvIGFuIG0tIGxpbmUgZm9yIHdoaWNoIHRoZSBQVCB2YWx1ZSBoYXNu J3QgYmVlbiBkZWZpbmVkLCBpdCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhbiBlcnJvci4NCg0KSSBk b24ndCB0aGluayBvbmUgc2hvdWxkICJzd2l0Y2giIHRvIGFub3RoZXIgbWFwcGluZyBtZWNoYW5p c20gYW5kIHNlZSB3aGV0aGVyIGFuIG0tIGxpbmUgZm9yIHRoYXQgUFQgaXMgZm91bmQuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQo+IE9uIEZlYiAxLCAyMDE3LCBhdCAyOjQzIFBNLCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToN Cj4gDQo+IEhpLA0KPiANCj4+PiBJIGhhdmUgb25lIHF1ZXN0aW9uLCBob3dldmVyLiAgV2hhdCBz aG91bGQgaGFwcGVuIGlmIGFuIFJUUCBwYWNrZXQgDQo+Pj4gKHdpdGhvdXQgYSBNSUQpIGlzIHJl Y2VpdmVkIGZvciBhIHN0cmVhbSB0aGF0IGhhcyBhbiBleGlzdGluZyANCj4+PiBtYXBwaW5nIHRv IGFuIG09IGxpbmUsIGJ1dCB3aG9zZSBQVCBpcyBub3QgdmFsaWQgZm9yIHRoYXQgbT0gbGluZT8N Cj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhhdCBjYXNlIGlzIHNwZWNpZmljIHRvIEJVTkRMRSwgaXMg aXQ/IEl0IGNvdWxkIGhhcHBlbiBldmVuIHdpdGhvdXQgbXVsdGlwbGV4aW5nLg0KPiANCj4gSSBh Z3JlZSB3aXRoIE1hZ251cyB0aGF0IGl0IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFuIGVycm9yLg0K PiANCj4gKFRoZXJlIGNvdWxkIGV2ZW4gYmUgY2FzZXMgd2hlcmUgdGhlIFBUIGlzbid0IHZhbGlk IGZvciBBTlkgbS0gbGluZSkuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCg0K From nobody Wed Feb 1 12:42:45 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A901299ED; Wed, 1 Feb 2017 12:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RT_x7jpCiU-B; Wed, 1 Feb 2017 12:42:22 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0ECD129431; Wed, 1 Feb 2017 12:42:22 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 204so112036418pge.0; Wed, 01 Feb 2017 12:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7cS+1GDgMHYsT7OBaQLNm8prQhFfWbbbG95E8JQr+c=; b=U8zWFtjPoMjq1lhnzylD2tntTNqcEx4X6MZo19F/6tPOXLO6mNfbN2HSAOeZLXIcsL xsNL133fGNmd6FihKliZNdV5imVpoTV4YUp1Wr+ArcAlL13UrXnDITBgBJpdbF3y4dtA zeqEjnEBjywTUJYSV0Yn0r3QjfAn7YUDvz6643RjjV0HPEG4pladZeJVq1v2lRew7hYU KghbjVpOzA78t7LJ0Ot+UAqi8/LFkYFX5wjZJruciFJU8huGegUzl/UFf2X7KxPNqI+J yhMlTPJqmGDgr05ORyBUDpydeQPr6KhKrZ0mU4pKd0G5OGW0EiisDFVcvncBKBjrNkU2 t9jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7cS+1GDgMHYsT7OBaQLNm8prQhFfWbbbG95E8JQr+c=; b=bHFN7wXVwsNkoxvZUXOPgU/JZi45Vepwltr/odFRdFOdQ12yIVuwEI9v/0NzIXZujX hV9iAwRutX7er7vmnGIWbNUO1fyPQLFPrKc0+GZ9xpNDExrY5YK04qUurIvAyOcwvmgY qZwoJOjQ//Iq+84vx4E9NcWCmX0yYX54KfAnVbu/feOVoGwFBnVCn/uOPibwptVop4mQ 2B04vVzzkuzrq3ByrQ9dgl6/sx+E/vrCLnoHjxaZCuwhVfmPtbAC6B3swI2ASWVhqbd/ GYjgf5uM6niScAzw/8sW1ls8jy46xRPq36p1SgsItMkFCTPQEzmaqlnUfmkaxvmgEOz9 1Frw== X-Gm-Message-State: AIkVDXJVopAt/X4k6OKYAkzyoR8FysD1NZ7ERI0m9DQtXuoN6Q5f5jP6eGFR0kxfAZTsbA== X-Received: by 10.99.213.81 with SMTP id v17mr6111745pgi.130.1485981741913; Wed, 01 Feb 2017 12:42:21 -0800 (PST) Received: from [192.168.0.166] (71-212-77-30.tukw.qwest.net. [71.212.77.30]) by smtp.gmail.com with ESMTPSA id c11sm51933302pfk.14.2017.02.01.12.42.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 12:42:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14D27) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> Date: Wed, 1 Feb 2017 12:41:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> To: Christer Holmberg Archived-At: Cc: mmusic , Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:42:39 -0000 *Any* RTP packet routed to an m-line needs to have a PT field that is valid f= or that m-line. This is true whether the routing was done via MID match, SSR= C match or PT match.=20 Also, Magnus mentioned a case where a BYE is received for an SSRC then subse= quently 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 wrote: >=20 > Hi, >=20 >>> I have one question, however. What should happen if an RTP packet=20 >>> (without a MID) is received for a stream that has an existing mapping=20= >>> to an m=3D line, but whose PT is not valid for that m=3D line? >=20 > I don't think that case is specific to BUNDLE, is it? It could happen even= without multiplexing. >=20 > I agree with Magnus that it should be treated as an error. >=20 > (There could even be cases where the PT isn't valid for ANY m- line). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Feb 2 01:25:55 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519801293E8; Thu, 2 Feb 2017 01:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 gQpBd6Mylrrf; Thu, 2 Feb 2017 01:25:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7C7351289B0; Thu, 2 Feb 2017 01:25:51 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-45-5892fb1db71e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 79.B2.14025.D1BF2985; Thu, 2 Feb 2017 10:25:49 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.319.2; Thu, 2 Feb 2017 10:25:48 +0100 To: Jonathan Lennox References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> From: Magnus Westerlund Message-ID: Date: Thu, 2 Feb 2017 10:25:46 +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: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7pa7s70kRBi9aVS2mz3rHZjG/Yx2b xf7F55ktpi5/zGKx9l87uwOrx5IlP5k8vlz+zObR9uwOewBzFJdNSmpOZllqkb5dAldG98KD LAWT+So6n+xmbmBcw93FyMkhIWAi8eX6ObYuRi4OIYF1jBKrP61ihXCWMUqs2X+UBaRKWKBI 4sDLNmYQW0RAQ+Lisw9QHbcZJc63LGQHcZgFmpkk7uyewg5SxSZgIXHzRyMbiM0rYC9xtO0D K4jNIqAi8W5PGxOILSoQI/FyzyoWiBpBiZMzn4DZnAK2El/+rADq5QAaai/xYGsZSJhZQF6i eetssCOEBLQlGpo6WCcwCsxC0j0LoWMWko4FjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2 MQID+OCW36o7GC+/cTzEKMDBqMTDa2AwKUKINbGsuDL3EKMEB7OSCG/wN6AQb0piZVVqUX58 UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjK5aR+e8ONO160aZ2eIros8v OBdfmxi4W91o9ru1/rcZ1Zt0HK97b7V13TaTY3e/uctrG+FwUy5BvTuHb/D6/WWoXzzxm/TH xcZVtj8UDRuVN71vOJZy57nyHrkPNeyx+qa9m0RMvJlZGw4I80g+Pmml+tf88+nbTfOebDJY l/z14vtXKhWvJymxFGckGmoxFxUnAgCpdWq1XAIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 09:25:53 -0000 Den 2017-02-01 kl. 21:02, skrev Jonathan Lennox: > >> On Feb 1, 2017, at 10:21 AM, Magnus Westerlund >> wrote: >> 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. > 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- From nobody Thu Feb 2 01:29:38 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815A1293E8; Thu, 2 Feb 2017 01:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 LJDB4HqdV21J; Thu, 2 Feb 2017 01:29:31 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 B21231289B0; Thu, 2 Feb 2017 01:29:30 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-8b-5892fbf8e967 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 34.73.14025.8FBF2985; Thu, 2 Feb 2017 10:29:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Thu, 2 Feb 2017 10:29:26 +0100 To: Bernard Aboba , Christer Holmberg References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BFD8C88@ESESSMB209.ericsson.se> From: Magnus Westerlund Message-ID: <80fb40bf-4625-39c7-4806-9442c71937e8@ericsson.com> Date: Thu, 2 Feb 2017 10:29:26 +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: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM2J7oO7P35MiDB5s57TYsO8/s8X0We/Y LOZ3rGOz2L/4PLPF1OWPWSzW/mtnd2Dz2DnrLrvHkiU/mTy+XP7M5tH27A57AEsUl01Kak5m WWqRvl0CV8bzNwtZCw5yV9x9n9PAOJuzi5GTQ0LAROL8zvWMILaQwDpGibbv/l2MXED2MkaJ De8WM4MkhAWqJTbM/skEYosIJEqsmP6BGaJhPpNE3y8fkAZmgZVMEm/2PmQBSbAJWEjc/NHI BmLzCthLbNl2hh3EZhFQkdj4cTvYIFGBGImXe1axQNQISpyc+QTM5hSwlVi5fjLQRRxAQ+0l HmwtAwkzC8hLNG+dDbVXW6KhqYN1AqPALCTdsxA6ZiHpWMDIvIpRtDi1OCk33chYL7UoM7m4 OD9PLy+1ZBMjMJwPbvmtuoPx8hvHQ4wCHIxKPLwGBpMihFgTy4orcw8xSnAwK4nwcgKjQYg3 JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbG4iyv2qx4lraF 7G62IjaLi7y/lxglxG2ICUlbe+btdSGLx9sXLJ9/fsPGUyYb8j9pOda3G2XN1W/aqKTw+cdN i6z+4IkeWmeUk8Q/2+zaEWtttOgpl3JLjaZHp9HfcI+G681TnfaGJlvWfuyUdJPmqJiwJzjh uLFA6KQLz55KXc+zOOO0uVyJpTgj0VCLuag4EQCQBALeYwIAAA== Archived-At: Cc: Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 09:29:32 -0000 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- From nobody Thu Feb 2 04:49:28 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BB12940E; Thu, 2 Feb 2017 04:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 rn3I4VPqOGDH; Thu, 2 Feb 2017 04:49:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34592129400; Thu, 2 Feb 2017 04:49:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFR17800; Thu, 02 Feb 2017 12:49:19 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 2 Feb 2017 12:49:18 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Thu, 2 Feb 2017 20:49:12 +0800 From: Roni Even To: Magnus Westerlund , "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , "draft-ietf-rtcweb-jsep@tools.ietf.org" Thread-Topic: [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSeLyNdlGsubKC20y06tuA5xxgmqFVs8jg Date: Thu, 2 Feb 2017 12:49:12 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7716D7@DGGEMM506-MBX.china.huawei.com> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58932AD0.037F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 359c90da364523be5d4230b6c7375327 Archived-At: Subject: Re: [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:49:27 -0000 SGkgTWFnbnVzLA0KSXMgdGhlcmUgYSBuZWVkIHRvIHNwZWNpZnkgdGhlIG1hcHBpbmcgZm9yIHRo ZSBzaW11bGNhc3QgY2FzZSB3aGVyZSB0aGUgcmlkIGlkZW50aWZ5IHRoZSBtYXBwaW5nIGluIHRo ZSBtLWxpbmU/DQpSb25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog cnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWdu dXMNCj4gV2VzdGVybHVuZA0KPiBTZW50OiDXmdeV153CoNeVIDI3INeZ16DXldeQ16ggMjAxNyAx ODo0Mw0KPiBUbzogbW11c2ljIChFLW1haWwpOyBydGN3ZWJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt bW11c2ljLXNkcC1idW5kbGUtDQo+IG5lZ290aWF0aW9uQGlldGYub3JnOyBkcmFmdC1pZXRmLXJ0 Y3dlYi1qc2VwQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFtydGN3ZWJdIFRleHQgcHJvcG9z YWwgZm9yIEJ1bmRsZSByZWdhcmRpbmcgQXNzb2NpYXRpbmcgUlRQL1JUQ1ANCj4gV2l0aCBDb3Jy ZWN0IFNEUCBNZWRpYSBEZXNjcmlwdGlvbg0KPiANCj4gTU1VU0lDIGFuZCBSVENXRUIsDQo+IA0K PiBIZXJlIGlzIG5vdyBhIG1vcmUgY29tcGxldGUgdGV4dCBwcm9wb3NhbCB0aGF0IGFsc28gY29u c2lkZXJzIHRoZSBSVENQLg0KPiBJdCBhbHNvIGdvZXMgZnVydGhlciB0aGFuIHdoYXQgQXBwZW5k aXggQiBkZWZpbmVzIGluIG9uZSBhc3BlY3QsIG5hbWVseQ0KPiBleHBsaWNpdGx5IGNvbnNpZGVy aW5nIHRoaXJkIHBhcnR5IFJUQ1AgcmVwb3J0aW5nIGFuZCB3aGF0IHRvIGRvIHdpdGggaXQuDQo+ IA0KPiBGZWVkYmFjayBpcyBtdWNoIGFwcHJlY2lhdGVkLiBJIHBsYW4gdG8gcHV0IHRoaXMgaW50 byBhIFBSIHRvd2FyZHMgSlNFUA0KPiBBUFBFTkRJWCBCIG9uIG1vbmRheS4gSWYgb25seSB0byBn ZXQgdGhlIEpTRVAgYXV0aG9ycyBhdHRlbnRpb24gOy0pLg0KPiBIb3dldmVyLCB0aGUgdGV4dCBp cyByZWFsbHkgaW50ZW5kZWQgZm9yIHRoZSBuZXh0IHZlcnNpb24gb2YgQlVORExFLg0KPiANCj4g DQo+IFguICBBc3NvY2lhdGluZyBSVFAvUlRDUCBXaXRoIENvcnJlY3QgU0RQIE1lZGlhIERlc2Ny aXB0aW9uDQo+IA0KPiAgICAgQXMgZGVzY3JpYmVkIGluIFtSRkMzNTUwXSwgUlRQIHBhY2tldHMg YXJlIGFzc29jaWF0ZWQgd2l0aCBSVFANCj4gICAgIHN0cmVhbXMgW1JGQzc2NTZdLiAgRWFjaCBS VFAgc3RyZWFtIGlzIGlkZW50aWZpZWQgYnkgYW4gU1NSQyB2YWx1ZSwNCj4gICAgIGFuZCBlYWNo IFJUUCBwYWNrZXQgY2FycmllcyBhbiBTU1JDIHZhbHVlIHRoYXQgaXMgdXNlZCB0byBhc3NvY2lh dGUNCj4gICAgIHRoZSBwYWNrZXQgd2l0aCB0aGUgY29ycmVjdCBSVFAgc3RyZWFtLiAgUlRDUCBw YWNrZXRzIGFsc28gdXNlcyBTU1JDcw0KPiAgICAgdG8gaWRlbnRpZnkgb24gd2hpY2ggUlRQIHN0 cmVhbXMgYW55IHJlcG9ydCBvciBmZWVkYmFjayByZWxhdGUgdG8uDQo+ICAgICBUaHVzLCBhbiBS VENQIHBhY2tldCB3aWxsIGNvbW1vbmx5IGNhcnJ5IG11bHRpcGxlIFNTUkMgdmFsdWVzLCBhbmQN Cj4gICAgIG1pZ2h0IHRoZXJlZm9yZSBiZSBwcm92aWRpbmcgZmVlZGJhY2sgb3IgcmVwb3J0IG9u IG11bHRpcGxlIFJUUA0KPiAgICAgc3RyZWFtcy4NCj4gDQo+ICAgICBJbiBvcmRlciB0byBiZSBh YmxlIHRvIHByb2Nlc3MgcmVjZWl2ZWQgUlRQL1JUQ1AgcGFja2V0cyBjb3JyZWN0bHkgaXQNCj4g ICAgIG11c3QgYmUgcG9zc2libGUgdG8gYXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0aCB0aGUg Y29ycmVjdCAibT0iDQo+ICAgICBsaW5lLCBhcyB0aGUgIm09IiBsaW5lIGFuZCBTRFAgYXR0cmli dXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSINCj4gICAgIGxpbmUgY29udGFpbiBpbmZvcm1h dGlvbiBuZWVkZWQgdG8gcHJvY2VzcyB0aGUgcGFja2V0cy4NCj4gDQo+ICAgICBBcyBhbGwgUlRQ IHN0cmVhbXMgYXNzb2NpYXRlZCB3aXRoIGEgQlVORExFIGdyb3VwIGFyZSBwYXJ0IG9mIHRoZQ0K PiAgICAgc2FtZSBSVFAgc2Vzc2lvbiBhbmQgdXNpbmcgdGhlIHNhbWUgYWRkcmVzczpwb3J0IGNv bWJpbmF0aW9uIGZvcg0KPiAgICAgc2VuZGluZyBhbmQgcmVjZWl2aW5nIFJUUC9SVENQIHBhY2tl dHMsIHRoZSBsb2NhbCBhZGRyZXNzOnBvcnQNCj4gICAgIGNvbWJpbmF0aW9uIGNhbm5vdCBiZSB1 c2VkIHRvIGFzc29jaWF0ZSBhbiBSVFAgc3RyZWFtIHdpdGggdGhlDQo+ICAgICBjb3JyZWN0ICJt PSIgbGluZS4gIEluIGFkZGl0aW9uLCBtdWx0aXBsZSBSVFAgc3RyZWFtcyBtaWdodCBiZQ0KPiAg ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lICJtPSIgbGluZS4NCj4gDQo+ICAgICBBbHNvLCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMC4xLjEsIHRoZSBzYW1lIHBheWxvYWQgdHlwZSB2YWx1 ZQ0KPiAgICAgbWlnaHQgYmUgdXNlZCBieSBtdWx0aXBsZSBSVFAgc3RyZWFtcywgaW4gd2hpY2gg Y2FzZSB0aGUgcGF5bG9hZCB0eXBlDQo+ICAgICB2YWx1ZSBjYW5ub3QgYmUgdXNlZCB0byBhc3Nv Y2lhdGUgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBjb3JyZWN0ICJtPSINCj4gICAgIGxpbmUuICBI b3dldmVyLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgZWFjaCAibT0iIGxpbmUgaGFzIHVuaXF1ZQ0K PiAgICAgcGF5bG9hZCB0eXBlIHZhbHVlcywgYW5kIHRoZW4gdGhlIHBheWxvYWQgdHlwZSBjb3Vs ZCBzZXJ2ZSBhcw0KPiAgICAgaW5kaWNhdG9yIHRvIHRoZSByZWxldmFudCAibT0iIGxpbmUgdGhl IFJUUCBzdHJlYW0gaXMgYXNzb2NpYXRlZA0KPiAgICAgd2l0aC4NCj4gDQo+ICAgICBBbiBvZmZl cmVyIGFuZCBhbnN3ZXJlciBjYW4gaW5mb3JtIGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2YWx1ZXMg dGhleQ0KPiAgICAgd2lsbCB1c2UgZm9yIGFuIFJUUCBzdHJlYW0gYnkgdXNpbmcgdGhlIFNEUCAn c3NyYycgYXR0cmlidXRlDQo+ICAgICBbUkZDNTU3Nl0uICBIb3dldmVyLCBhbiBvZmZlcmVyIHdp bGwgbm90IGtub3cgd2hpY2ggU1NSQyB2YWx1ZXMgdGhlDQo+ICAgICBhbnN3ZXJlciB3aWxsIHVz ZSB1bnRpbCB0aGUgb2ZmZXJlciBoYXMgcmVjZWl2ZWQgdGhlIGFuc3dlciBwcm92aWRpbmcNCj4g DQo+IA0KPiANCj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMzEsIDIw MTcgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQo+IA0KDQo+IEludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNw0KPiAN Cj4gDQo+ICAgICB0aGF0IGluZm9ybWF0aW9uLiAgRHVlIHRvIHRoaXMsIGJlZm9yZSB0aGUgb2Zm ZXJlciBoYXMgcmVjZWl2ZWQgdGhlDQo+ICAgICBhbnN3ZXIsIHRoZSBvZmZlcmVyIHdpbGwgbm90 IGJlIGFibGUgdG8gYXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0aA0KPiAgICAgdGhlIGNvcnJl Y3QgIm09IiBsaW5lIHVzaW5nIHRoZSBTU1JDIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQ DQo+ICAgICBzdHJlYW0uICBJbiBhZGRpdGlvbiwgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIG1h eSBzdGFydCB1c2luZyBuZXcNCj4gICAgIFNTUkMgdmFsdWVzIG1pZC1zZXNzaW9uLCB3aXRob3V0 IGluZm9ybWluZyBlYWNoIG90aGVyIHVzaW5nIHRoZSBTRFANCj4gICAgICdzc3JjJyBhdHRyaWJ1 dGUuDQo+IA0KPiAgICAgSW4gb3JkZXIgZm9yIGFuIG9mZmVyZXIgYW5kIGFuc3dlcmVyIHRvIGFs d2F5cyBiZSBhYmxlIHRvIGFzc29jaWF0ZQ0KPiAgICAgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBj b3JyZWN0ICJtPSIgbGluZSwgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyDQo+ICAgICB1c2luZyB0 aGUgQlVORExFIGV4dGVuc2lvbiBNVVNUIHN1cHBvcnQgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGlu DQo+ICAgICBTZWN0aW9uIDE0LCB3aGVyZSB0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIgaW5jbHVk ZXMgdGhlDQo+ICAgICBpZGVudGlmaWNhdGlvbi10YWcgKHByb3ZpZGVkIGJ5IHRoZSByZW1vdGUg cGVlcikgYXNzb2NpYXRlZCB3aXRoIGFuDQo+ICAgICAibT0iIGxpbmUgaW4gdGhlIFJUUCBTdHJl YW1zIGFuZCBpbiBSVENQIFNERVMgcGFja2V0cyBwYXJ0IG9mIGENCj4gICAgIEJVTkRMRSBncm91 cC4NCj4gDQo+ICAgICBUaGUgbWFwcGluZyBmcm9tIGFuIFNTUkMgdG8gYW4gaWRlbnRpZmljYXRp b24tdGFnIGlzIGNhcnJpZWQgaW4gUlRDUA0KPiAgICAgU0RFUyBwYWNrZXRzIG9yIGluIFJUUCBo ZWFkZXIgZXh0ZW5zaW9ucyAoU2VjdGlvbiAxNCkuICBTaW5jZSBhDQo+ICAgICBjb21wb3VuZCBS VENQIHBhY2tldCBjYW4gY29udGFpbiBtdWx0aXBsZSBSVENQIFNERVMgcGFja2V0cywgYW5kIGVh Y2gNCj4gICAgIFJUQ1AgU0RFUyBwYWNrZXQgY2FuIGNvbnRhaW4gbXVsdGlwbGUgY2h1bmtzLCBh biBSVENQIHBhY2tldCBjYW4NCj4gICAgIGNvbnRhaW4gc2V2ZXJhbCBTU1JDIHRvIGlkZW50aWZp Y2F0aW9uLXRhZyBtYXBwaW5ncy4gIFRoZSBvZmZlcmVyIGFuZA0KPiAgICAgYW5zd2VyZXIgbWFp bnRhaW4gdGFibGVzIG1hcHBpbmcgUlRQIHN0cmVhbXMgaWRlbnRpZmllZCBieSBTU1JDIHRvDQo+ ICAgICAibT0iIGxpbmVzIGlkZW50aWZpZWQgYnkgdGhlIGlkZW50aWZpY2F0aW9uLXRhZy4gIFRo ZXNlIHRhYmxlcyBhcmUNCj4gICAgIHVwZGF0ZWQgZWFjaCB0aW1lIG5ldyBpbmZvcm1hdGlvbiB0 aGF0IGFmZmVjdHMgaG93IHBhY2tldHMgc2hvdWxkIGJlDQo+ICAgICBwcm9jZXNzZWQgYW5kIHJv dXRlZCBhcmUgcmVjZWl2ZWQuDQo+IA0KPiAgICAgVG8gcHJlcGFyZSBmb3IgZGVtdWx0aXBsZXhp bmcgUlRQIHN0cmVhbXMgdG8gdGhlIGNvcnJlY3QgIm09IiBsaW5lLA0KPiAgICAgdGhlIGZvbGxv d2luZyBzdGVwcyBNVVNUIGJlIGZvbGxvd2VkIGZvciBlYWNoIEJVTkRMRSBncm91cCBiYXNlZCBv bg0KPiAgICAgdGhlIFNEUCBzaWduYWxsaW5nIGluZm9ybWF0aW9uLg0KPiANCj4gICAgICAgIENv bnN0cnVjdCBhIHRhYmxlIG1hcHBpbmcgTUlEIHRvICJtPSIgbGluZSBmb3IgZWFjaCAibT0iIGxp bmUgaW4NCj4gICAgICAgIHRoaXMgQlVORExFIGdyb3VwLiAgTm90ZSB0aGF0IGFuICJtPSIgbGlu ZSBtYXkgb25seSBoYXZlIG9uZSBNSUQuDQo+IA0KPiAgICAgICAgQ29uc3RydWN0IGEgdGFibGUg bWFwcGluZyBpbmNvbWluZyBSVFAgc3RyZWFtcyAoU1NSQ3MpIHRvIHRoZWlyDQo+ICAgICAgICAi bT0iIGxpbmUgZm9yIGVhY2ggIm09IiBsaW5lIGluIHRoaXMgQlVORExFIGdyb3VwIGFuZCBmb3Ig ZWFjaCBSVFANCj4gICAgICAgIHN0cmVhbSBleHBsaWNpdGx5IHNpZ25hbGxlZCBmb3IgcmVjZWl2 aW5nIGluIHRoYXQgIm09IiBsaW5lLg0KPiANCj4gICAgICAgIENvbnN0cnVjdCBhIHRhYmxlIG1h cHBpbmcgcGF5bG9hZCB0eXBlcyB0byAibT0iIGxpbmUgZm9yIGVhY2ggIm09Ig0KPiAgICAgICAg bGluZSBpbiB0aGUgQlVORExFIGdyb3VwIGFuZCBmb3IgZWFjaCBwYXlsb2FkIHR5cGUgY29uZmln dXJlZCBmb3INCj4gICAgICAgIHJlY2VpdmluZyBpbiB0aGF0ICJtPSIgbGluZS4gIElmIGFueSBw YXlsb2FkIHR5cGUgaXMgY29uZmlndXJlZA0KPiAgICAgICAgZm9yIHJlY2VpdmluZyBpbiBtb3Jl IHRoYW4gb25lICJtPSIgbGluZSBpbiB0aGUgQlVORExFIGdyb3VwLCBkbw0KPiAgICAgICAgbm90 IGl0IGluY2x1ZGUgaXQgaW4gdGhlIHRhYmxlLg0KPiANCj4gICAgIE5vdGUgdGhhdCBmb3IgZWFj aCBvZiB0aGVzZSB0YWJsZXMsIHRoZXJlIGNhbiBvbmx5IGJlIG9uZSBtYXBwaW5nIGZvcg0KPiAg ICAgYW55IGdpdmVuIGtleSAoTUlELCBTU1JDLCBvciBQVCkuICBJbiBvdGhlciB3b3JkcywgdGhl IHRhYmxlcyBhcmUgbm90DQo+ICAgICBtdWx0aW1hcHMuDQo+IA0KPiAgICAgQXMgIm09IiBsaW5l cyBhcmUgYWRkZWQgb3IgcmVtb3ZlZCBmcm9tIHRoZSBCVU5ETEUgZ3JvdXBzLCBvciB0aGVpcg0K PiAgICAgY29uZmlndXJhdGlvbnMgYXJlIGNoYW5nZWQsIHRoZSB0YWJsZXMgYWJvdmUgTVVTVCBh bHNvIGJlIHVwZGF0ZWQuDQo+IA0KPiANCj4gDQo+IE5hbWUgICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBKdWx5IDMxLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KPiANCg0KPiBJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQtVGl0bGUgICAgICAgICAgICAg ICBKYW51YXJ5IDIwMTcNCj4gDQo+IA0KPiAgICAgUmVjZWl2ZWQgUlRQIHBhY2tldHMgdGhhdCBh cmUgc3ludGFjdGljYWxseSBjb3JyZWN0IGFyZSBwcm9jZXNzZWQgYnkNCj4gICAgIHRoZSBSVFAv UlRDUCBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiBmb3Igc3RhdGlzdGljcyBldGMuICBBZnRlciB0 aGlzDQo+ICAgICBwcm9jZXNzaW5nIHRoZXkgbmVlZCB0byBiZSByb3V0ZWQgdG8gdGhlIGhpZ2hl ciBsYXllciBjb250ZXh0DQo+ICAgICBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZSB3aXRo aW4gdGhlIEJVTkRMRSBncm91cC4gIFNvbWV3aGVyZSBpbg0KPiAgICAgdGhlIHByb2Nlc3Mgd2hl cmUgYW4gcmVjZWl2ZWQgUlRQIHBhY2tldCBpcyBwcm9jZXNzZWQgdG8gYmUgZGVsaXZlcmVkDQo+ ICAgICB0byB0aGUgaGlnaGVyIGxheWVyIGJ5IFJUUCB0aGUgbWF0Y2hpbmcgc3RlcCBiZWxvdyBN VVNUIGJlIHBlcmZvcm1lZDoNCj4gDQo+ICAgICAxLiAgUmVjZXB0aW9uIG9mIGFuIFJUUCBwYWNr ZXQgZm9yIGFuIFJUUCBzdHJlYW0gdGhhdCBoYXMgYW4gZXhpc3RpbmcNCj4gICAgICAgICBtYXBw aW5nIGluIHRoZSBSVFAgc3RyZWFtIHRvIG09IGxpbmUgdGFibGUuICBCZWZvcmUgcHJvY2VlZGlu ZyBpbg0KPiAgICAgICAgIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgaGlnaGVyIGxheWVy IGNvbnRleHQgYWNjb3JkaW5nIHRvDQo+ICAgICAgICAgdGhlIFJUUCBzdHJlYW0gdG8gIm09IiBs aW5lIG1hcHBpbmcgdGFibGUgdGhlIGZvbGxvd2luZyBjaGVja3MNCj4gICAgICAgICBNVVNUIGJl IHBlcmZvcm1lZDoNCj4gDQo+ICAgICAgICAgQS4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhbiBS VFAgaGVhZGVyIGV4dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4gICAgICAgICAgICAgdmFsdWUg dGhhdCBpcyBub3QgaW4gdGhlIHRhYmxlIG1hcHBpbmcgTUlEIHRvICJtPSIgbGluZSwgdGhlbg0K PiAgICAgICAgICAgICBkbyBub3QgZGVsaXZlciB0aGUgUlRQIHBhY2tldCB0byBoaWdoZXIgbGF5 ZXJzLg0KPiANCj4gICAgICAgICBCLiAgSWYgdGhlIHBhY2tldCBjYXJyaWVzIGFuIFJUUCBoZWFk ZXIgZXh0ZW5zaW9uIHdpdGggYSBTREVTIE1JRA0KPiAgICAgICAgICAgICB2YWx1ZSB0aGF0IGlz IGluIHRoZSB0YWJsZSBtYXBwaW5nIE1JRCB0byAibT0iIGxpbmUsIGFuZCB0aGUNCj4gICAgICAg ICAgICAgdmFsdWUgaW5kaWNhdGVzIGEgZGlmZmVyZW50ICJtPSIgbGluZSB0aGFuIHRoZSBjdXJy ZW50IFJUUA0KPiAgICAgICAgICAgICBzdHJlYW0gdG8gIm09IiBsaW5lIG1hcHBpbmcgdGFibGUs IHRoZW4gdXBkYXRlIHRoZSBSVFAgc3RyZWFtDQo+ICAgICAgICAgICAgIHRvICJtPSIgbGluZSBt YXBwaW5nLg0KPiANCj4gICAgIDIuICBSZWNlcHRpb24gb2YgYW4gUlRQIHBhY2tldCBmb3IgYW4g UlRQIHN0cmVhbSB0aGF0IGhhcyBubyBleGlzdGluZw0KPiAgICAgICAgIG1hcHBpbmcgdG8gYW4g bT0gbGluZS4gIEluIHRoaXMgY2FzZSB0aGUgZm9sbG93aW5nIGFjdGlvbnMgTVVTVA0KPiAgICAg ICAgIGJlIHBlcmZvcm1lZDoNCj4gDQo+ICAgICAgICAgQS4gIElmIHRoZSBwYWNrZXQgY2Fycmll cyBhbiBSVFAgaGVhZGVyIGV4dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4gICAgICAgICAgICAg dmFsdWUgdGhhdCBpcyBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB0aGVu DQo+ICAgICAgICAgICAgIGNyZWF0ZSBhbiBlbnRyeSBpbiB0aGUgUlRQIHN0cmVhbSB0byAibT0i IGxpbmUgbWFwcGluZyB0YWJsZQ0KPiAgICAgICAgICAgICBmb3IgdGhpcyBSVFAgc3RyZWFtIChT U1JDKS4gIFRoZW4gZGVsaXZlciB0aGUgUlRQIHBhY2tldCB0bw0KPiAgICAgICAgICAgICB0aGUg Im09IiBsaW5lIGNvbnRleHQgb2YgdGhlIGNyZWF0ZWQgbWFwcGluZyBhbmQgc3RvcC4NCj4gDQo+ ICAgICAgICAgQi4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhIFBheWxvYWQgVHlwZSB0aGF0IGlz IGluIHRoZSBwYXlsb2FkDQo+ICAgICAgICAgICAgIHR5cGUgdGFibGUsIHRoZW4gY3JlYXRlIGFu IGVudHJ5IGluIHRoZSBSVFAgc3RyZWFtIHRvICJtPSINCj4gICAgICAgICAgICAgbGluZSBtYXBw aW5nIHRhYmxlIGZvciB0aGlzIFJUUCBzdHJlYW0gKFNTUkMpLiAgVGhlbiBkZWxpdmVyDQo+ICAg ICAgICAgICAgIHRoZSBSVFAgcGFja2V0IHRvIHRoZSAibT0iIGxpbmUgY29udGV4dCBvZiB0aGUg Y3JlYXRlZA0KPiAgICAgICAgICAgICBtYXBwaW5nIGFuZCBzdG9wLg0KPiANCj4gICAgICAgICBD LiAgT3RoZXJ3aXNlIGRvIG5vdCBkZWxpdmVyIHRoZSBSVFAgcGFja2V0IHRvIGhpZ2hlciBsYXll cnMuDQo+ICAgICAgICAgICAgIE5vdGUsIHRoaXMgaW5jbHVkZXMgdW5rbm93biBNSUQgdmFsdWVz Lg0KPiANCj4gICAgIEZvciBlYWNoIFJUQ1AgcGFja2V0IHJlY2VpdmVkIChpbmNsdWRpbmcgZWFj aCBSVENQIHBhY2tldCB0aGF0IGlzDQo+ICAgICBwYXJ0IG9mIGEgY29tcG91bmQgUlRDUCBwYWNr ZXQpLCB0aGUgUlRDUCBwYWNrZXQgbmVlZHMgdG8gYmUNCj4gICAgIHByb2Nlc3NlZCBieSB0aGUg UlRQL1JUQ1AgaW1wbGVtZW50YXRpb24gYW5kIHJlbGV2YW50IGluZm9ybWF0aW9uIGFuZA0KPiAg ICAgZGF0YSBmcm9tIHRoZSBSVENQIHBhY2tldHMgbmVlZHMgdG8gYmUgcm91dGVkIHRvIHRoZSBh cHByb3ByaWF0ZQ0KPiAgICAgaGFuZGxlciBmb3IgdGhlIHJlbGF0ZWQgUlRQIHN0cmVhbXMuICBU aGUgYXBwcm9wcmlhdGUgaGFuZGxlciBpcw0KPiAgICAgZGV0ZXJtaW5lZCBieSB1c2luZyB0aGUg UlRQIHN0cmVhbSB0byAibT0iIGxpbmUgbWFwcGluZyB0YWJsZS4NCj4gDQo+IA0KPiANCj4gTmFt ZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAg ICAgIFtQYWdlIDRdDQo+IA0KDQo+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZp YXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNw0KPiANCj4gDQo+ICAgICBPbiBy ZWNlcHRpb24gb2YgYW55IGNvbXBvdW5kIFJUQ1AgcGFja2V0IHByaW9yIHRvIGRpc3BhdGNoaW5n IHRoZQ0KPiAgICAgcmVjZWl2ZWQgaW5mb3JtYXRpb24gYW5kIGRhdGEsIGlmIHRoZXJlIGlzIGFu IFJUQ1AgU0RFUyBwYWNrZXQNCj4gICAgIGluY2x1ZGVkIHRoYXQgU0hPVUxEIGJlIHByb2Nlc3Nl ZCBmaXJzdC4gIElmIHRoYXQgU0RFUyBwYWNrZXQNCj4gICAgIGNvbnRhaW5zIFNERVMgTUlEIGVu dHJpZXMsIHRoaXMgY2FuIHJlc3VsdHMgaW4gdXBkYXRlcyBhbmQgYWRkaXRpb25zDQo+ICAgICB0 byB0aGUgUlRQIHN0cmVhbSB0byAibT0iIGxpbmUgbWFwcGluZyB0YWJsZS4gIFRodXMgZWFjaCBv ZiB0aGUgU0RFUw0KPiAgICAgTUlEIGl0ZW1zIGFyZSBwcm9jZXNzZWQgYW5kIHRoZSBjdXJyZW50 IHRhYmxlIGVudHJpZXMgYXJlIGNoZWNrZWQgaWYNCj4gICAgIHRoZSBjb3JyZXNwb25kaW5nIE1J RCB2YWx1ZSBtYXRjaGVzIHRoZSBjdXJyZW50IFJUUCBzdHJlYW0gdG8gIm09Ig0KPiAgICAgbGlu ZSBtYXBwaW5nLCBlbHNlIHRoZSBlbnRyeSBpcyB1cGRhdGVkLiAgSWYgdGhlcmUgaXMgbm8gUlRQ IHN0cmVhbQ0KPiAgICAgdG8gIm09IiBsaW5lIHRhYmxlIG1hcHBpbmcgZW50cnkgZm9yIHRoZSBy ZWNlaXZlZCBTREVTIGl0ZW0ncyBTU1JDLA0KPiAgICAgc3VjaCBhbiBlbnRyeSBpcyBjcmVhdGVk LiAgTm90ZSwgdGhhdCBpbiB0aGUgcHJvY2VzcyBvZiB1cGRhdGluZyB0aGUNCj4gICAgIHRhYmxl IGVudHJpZXMsIHVwZGF0ZSBmbGFwIHN1cHByZXNzaW9uIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDQuMi42DQo+ICAgICBvZiBbUkZDNzk0MV0gc2hvdWxkIGJlIGNvbnNpZGVyZWQuDQo+IA0KPiAg ICAgVGhlIHZhcmlvdXMgZGlmZmVyZW50IFJUQ1AgcGFja2V0cyBhcyB3ZWxsIGFzIHRoZWlyIHZh cmlvdXMgc3ViDQo+ICAgICBwYXJ0cywgc3VjaCBhcyB0aGUgdmFyaW91cyBSVENQIEZlZWRiYWNr IG1lc3NhZ2UgdHlwZXMsIHJlbGF0ZXMgdG8NCj4gICAgIHRoZSBSVFAgc3RyZWFtcyBpbiBhIGNv dXBsZSBvZiBkaWZmZXJlbnQgd2F5cy4gIFRoZSBjdXJyZW50bHkga25vd24NCj4gICAgIHBhdHRl cm5zIGFyZSB0aGUgZm9sbG93aW5nOg0KPiANCj4gICAgIFJlcG9ydHMgb24gb3V0Z29pbmcgUlRQ IHN0cmVhbXM6ICBGb3IgYWxsIFJUUCBzdHJlYW1zIHRoYXQgdGhpcw0KPiAgICAgICAgZW5kcG9p bnQgaXMgdGhlIHNvdXJjZSBvZiwgaXQgY2FuIGV4cGVjdCB0byByZWNlaXZlIHJlcG9ydCBibG9j a3MNCj4gICAgICAgIG9mIHNldmVyYWwgdHlwZXMgaWRlbnRpZmllZCBhcyByZWxhdGluZyB0byBh biBvdXRnb2luZyBzdHJlYW0uDQo+ICAgICAgICBUaGUgYmFzaWMgcGF0dGVybiBmb3IgdGhlc2Ug YmxvY2tzIGFyZSB0aGF0IHRoZSBSVENQIHBhY2tldCBoZWFkZXINCj4gICAgICAgIGlkZW50aWZp ZXMgdGhlIHNvdXJjZSBvZiB0aGUgcmVwb3J0cywgYXMgaWRlbnRpZmllZCBieSBhbiBTU1JDLA0K PiAgICAgICAgYW5kIGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgcmVwb3J0IGJsb2Nrcywgd2hlcmUg ZWFjaCByZXBvcnQgYmxvY2sNCj4gICAgICAgIGlkZW50aWZpZXMgdGhlIFJUUCBzdHJlYW0sIHVz aW5nIHRoZSBTU1JDLCB0aGUgcmVwb3J0IHJlbGF0ZXMgdG8uDQo+ICAgICAgICBGb3IgdGhpcyBw YXR0ZXJuIHRoZSByZWxldmFudCByZXBvcnQgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgdG8NCj4g ICAgICAgIHRoZSBoaWdoZXIgbGF5ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSAibT0iIGxpbmUgdGhl IFJUUCBTdHJlYW0gdG8NCj4gICAgICAgICJtPSIgbGluZSB0YWJsZSBpZGVudGlmaWVzLiAgVGhl IHNvdXJjZSBTU1JDIGFzIGlkZW50aWZpZXIgb2YgdGhlDQo+ICAgICAgICBlbmRwb2ludCB0aGF0 IHRoZSByZXBvcnQgb3JpZ2luYXRlcyBhcmUgcmVsZXZhbnQgZm9yIGludGVycHJldGluZw0KPiAg ICAgICAgdGhlIGluZm9ybWF0aW9uLCBidXQgbm90IG5lY2Vzc2FyaWx5IGZvciByb3V0aW5nLiAg RXhhbXBsZSBvZiB0aGlzDQo+ICAgICAgICBpcyBwYXR0ZXJuIGFyZToNCj4gDQo+ICAgICAgICBT ZW5kZXIgUmVwb3J0IChTUikgYW5kIFJlY2VpdmVyIFJlcG9ydCAoUlIpICBUaGUgYmFzaWMgcmVj ZWl2ZXINCj4gICAgICAgICAgIHJlcG9ydCBibG9ja3MgZnJvbSBSRkMzNTUwIHN0YXJ0IHdpdGgg dGhlIFNTUkMgb2YgdGhlIFJUUA0KPiAgICAgICAgICAgc3RyZWFtIHRoZXkgcmVwb3J0IG9uLg0K PiANCj4gICAgICAgIEV4dGVuZGVkIFJlcG9ydHMgKFhSKTogIFJGQzM2MTEgaXMgYSBmcmFtZXdv cmsgdGhhdCBlbmFibGVzIGENCj4gICAgICAgICAgIGxhcmdlIG51bWJlciBvZiBkaWZmZXJlbnQg cmVwb3J0cy4gIEhvd2V2ZXIsIGEgbGFyZ2UgbnVtYmVyIG9mDQo+ICAgICAgICAgICB0aGVzZSBy ZXBvcnQgZm9ybWF0cyBhcmUgcmVwb3J0aW5nIG9uIHNwZWNpZmljIFJUUCBzdHJlYW1zIGFuZA0K PiAgICAgICAgICAgdGh1cyBlYWNoIGluZGl2aWR1YWwgcmVwb3J0IG9mIHRoZXNlIHR5cGVzIGNv bnRhaW5zIGEgU1NSQw0KPiAgICAgICAgICAgZmllbGQgdG8gaWRlbnRpZnkgdGhlIFJUUCBzdHJl YW0uDQo+IA0KPiAgICAgUlRDUCBGZWVkYmFjayBNZXNzYWdlcyBmb3Igb3V0Z29pbmcgUlRQIHN0 cmVhbXM6ICBUaGUgUkZDIDQ1ODUgUlRDUA0KPiAgICAgICAgZmVlZGJhY2sgbWVzc2FnZXMgYWxs b3cgZm9yIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB0eXBlIG9mIGZlZWRiYWNrDQo+ICAgICAgICBt ZXNzYWdlcy4gIEhvd2V2ZXIsIHRoZSBSVENQIGZlZWRiYWNrIG1lc3NhZ2UgaGVhZGVyIGNvbnRh aW5zIHRoZQ0KPiAgICAgICAgU1NSQyBpZGVudGlmeWluZyB0aGUgc291cmNlIG9mIHRoZSBmZWVk YmFjayBtZXNzYWdlcyBhcyB3ZWxsIGFzDQo+ICAgICAgICB0aGUgYWN0dWFsIHR5cGUgb2YgdGhl IGZlZWRiYWNrLiAgU29tZSBvZiB0aGUgZmVlZGJhY2sgbWVzc2FnZXMNCj4gICAgICAgIGFsc28g dXNlcyB0aGUgdGFyZ2V0IFNTUkMgZmllbGQgaW4gdGhlIGhlYWRlciB0byBpZGVudGlmeSB3aGlj aA0KPiANCj4gDQo+IA0KPiBOYW1lICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAz MSwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCj4gDQoNCj4gSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIEFiYnJldmlhdGVkLVRpdGxlICAgICAgICAgICAgICAgSmFudWFyeSAyMDE3 DQo+IA0KPiANCj4gICAgICAgIFJUUCBzdHJlYW0gdGhlIGZlZWRiYWNrIGlzIHJlbGF0ZWQgdG8u ICBGb3IgdGhlc2UgdHlwZXMgYWxsIHRoZQ0KPiAgICAgICAgRkNJIGVudHJpZXMsIGlmIG11bHRp cGxlIG9uZXMgYXJlIGZvcndhcmRlZCB0byB0aGUgaWRlbnRpZmllZA0KPiAgICAgICAgaGFuZGxl ci4gIEV4YW1wbGVzIG9mIHRoaXMgcGF0dGVybiBhcmU6DQo+IA0KPiAgICAgICAgUGljdHVyZSBM b3NzIEluZGljYXRpb24gKFBMSSk6ICBSRkMgNDU4NSAoUFQ9UFNGQiwgRk1UPTEpLg0KPiANCj4g ICAgICAgIFNsaWNlIExvc3MgSW5kaWNhdGlvbiAoU0xJKTogIFJGQyA0NTg1IChQVD1QU0ZCLCBG TVQ9MikuDQo+IA0KPiAgICAgICAgUmVmZXJlbmNlIFBpY3R1cmUgU2VsZWN0aW9uIEluZGljYXRp b24gKFJQU0kpOiAgUkZDIDQ1ODUgKFBUPVBTRkIsDQo+ICAgICAgICAgICBGTVQ9MykuDQo+IA0K PiAgICAgICAgR2VuZXJpYyBOQUNLOiAgW1JGQzQ1ODVdIChQVD1SVFBGQiBhbmQgRk1UPTEpLg0K PiANCj4gICAgICAgIE90aGVyIGZlZWRiYWNrIG1lc3NhZ2VzIGluY2x1ZGVzIHRoZSB0YXJnZXQg U1NSQyBpbiB0aGUgRmVlZGJhY2sNCj4gICAgICAgIENvbnRyb2wgSW5mb3JtYXRpb24gKEZDSSku ICBIZXJlIGVhY2ggRkNJIG5lZWRzIHRvIGJlIHByb2Nlc3NlZA0KPiAgICAgICAgYW5kIHRoZSBT U1JDIGZpZWxkIGlkZW50aWZpZWQuICBBbmQgdGhlIGluZGl2aWR1YWwgRkNJIGNvbWJpbmVkDQo+ ICAgICAgICB3aXRoIHRoZSBSVENQIHBhY2tldCBoZWFkZXIgY29udGV4dCBuZWVkcyB0byBiZSBm b3J3YXJkZWQgdG8gdGhlDQo+ICAgICAgICBpZGVudGlmaWVkIGhhbmRsZXIuICBFeGFtcGxlIG9m IHRoaXMgcGF0dGVybiBhcmU6DQo+IA0KPiAgICAgICAgRnVsbCBJbnRyYSBSZXF1ZXN0IChGSVIp OiAgW1JGQzUxMDRdIChQVD1QU0ZCLCBGTVQ9NCkuDQo+IA0KPiAgICAgICAgVGVtcG9yYWwtU3Bh dGlhbCBUcmFkZS1vZmYgUmVxdWVzdCAoVFNUUik6ICBbUkZDNTEwNF0gKFBUPVBTRkIsDQo+ICAg ICAgICAgICBGTVQ9NSkuDQo+IA0KPiAgICAgICAgVGVtcG9yYWwtU3BhdGlhbCBUcmFkZS1vZmYg Tm90aWZpY2F0aW9uIChUU1ROKTogIFRoaXMgW1JGQzUxMDRdDQo+ICAgICAgICAgICBkZWZpbmVk IG1lc3NhZ2UgKFBUPVBTRkIsIEZNVD01KSBpcyBhY3R1YWxseSBhIG5vdGlmY2lhdGlvbiBpbg0K PiAgICAgICAgICAgcmVzcG9uc2UgdG8gYSBUU1RSIHRoaXMgZW5kcG9pbnQgc2VudCB1c2luZyB0 aGUgU1NSQyB0aGUgRkNJDQo+ICAgICAgICAgICBpZGVudGlmaWVzIGFzIHNvdXJjZS4NCj4gDQo+ ICAgICAgICBILjI3MSBWaWRlbyBCYWNrIENoYW5uZWwgTWVzc2FnZSAoVkJDTSk6ICBbUkZDNTEw NF0gKFBUPVBTRkIsDQo+ICAgICAgICAgICBGTVQ9NykuDQo+IA0KPiAgICAgICAgTGF5ZXIgUmVm cmVzaCBSZXF1ZXN0IChMUlIpOiAgW0ktRC5pZXRmLWF2dGV4dC1scnJdIChQVD1QU0ZCLA0KPiAg ICAgICAgICAgRk1UPVRCRCkuDQo+IA0KPiAgICAgRGVzY3JpcHRpdmUgb3IgTm90aWZpY2F0aW9u cyBmb3IgYW4gaW5jb21pbmcgUlRQIHN0cmVhbTogIFRoZXJlIGV4aXN0DQo+ICAgICAgICBzb21l IFJUQ1AgcGFja2V0IHR5cGVzIHRoYXQgcHJvdmlkZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBv cg0KPiAgICAgICAgbm90aWZpZXMgYWJvdXQgZXZlbnRzIHJlbGF0ZWQgdG8gdGhlIFJUUCBzdHJl YW0gaWRlbnRpZmllZC4gIEluDQo+ICAgICAgICB0aGVzZSBjYXNlcyB0aGUgUlRQIHN0cmVhbSBp cyBpZGVudGlmaWVkIHVzaW5nIHRoZSBTU1JDIGZpZWxkDQo+ICAgICAgICB2YWx1ZSwgYW5kIHRo ZSBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCB0byB0aGUgaGlnaGVyIGxheWVyDQo+ICAgICAgICBh c3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZSBmb3IgdGhlIGluY29taW5nIFJUUCBzdHJlYW0g YXMNCj4gICAgICAgIGlkZW50aWZpZWQgYnkgdGhlIGN1cnJlbnQgUlRQIHN0cmVhbSB0byAibT0i IGxpbmUgdGFibGUuICBGb3IgdGhpcw0KPiAgICAgICAgdHlwZSBvZiBwYXR0ZXJuIGl0IGlzIGNv bW1vbiB0aGF0IHRoZSBSVENQIHBhY2tldHMgYW5kIGluZm9ybWF0aW9uDQo+ICAgICAgICBpcyBy ZXBlYXRlZCwgZWl0aGVyIHBlcmlvZGljYWxseSAoZS5nLiAgU0RFUyBpdGVtcyksIG9yIGZvciBh DQo+ICAgICAgICBkdXJhdGlvbiAoZS5nLiAgQllFKSwgdGh1cyBzdXBwcmVzc2lvbiBvZiByZXBl dGl0aW9ucyBjYW4gYmUNCj4gICAgICAgIGNvbnNpZGVyZWQuICBFeGFtcGxlcyBvZiB0aGVzZSBh cmU6DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQo+IA0KDQo+IEludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEph bnVhcnkgMjAxNw0KPiANCj4gDQo+ICAgICAgICBTb3VyY2UgRGVzY3JpcHRpb24gKFNERVMpIFJU Q1AgUGFja2V0OiAgVGhlIGJhc2UgUlRQL1JUQ1AgcHJvdG9jb2wNCj4gICAgICAgICAgIFtSRkMz NTUwXSBkZWZpbmVzIFNERVMgUlRDUCBwYWNrZXRzIGFzIGEgd2F5IG9mIHByb3ZpZGluZyBwZXIN Cj4gICAgICAgICAgIHNvdXJjZSAoU1NSQykgc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQgdGhl IHNvdXJjZS4gIEFuIFNERVMNCj4gICAgICAgICAgIHBhY2tldCBjb250YWlucyB6ZXJvIG9yIG1v cmUgY2h1bmtzLCB3aGVyZSBhIGNodW5rIGNvbnRhaW5zIHRoZQ0KPiAgICAgICAgICAgU1NSQyBm b3IgdGhlIHNvdXJjZSBiZWluZyBkZXNjcmliZWQgYnkgdGhlIG9uZSBvciBtb3JlIGl0ZW1zDQo+ ICAgICAgICAgICBpbmNsdWRlZCBpbiB0aGUgY2h1bmsuICBGb3J3YXJkIHRoZSBTREVTIGl0ZW1z IGluIGVhY2ggY2h1bmsgdG8NCj4gICAgICAgICAgIHRoZSBSVFAgc3RyZWFtJ3MgaGFuZGxlci4N Cj4gDQo+ICAgICAgICBHb29kYnllIChCWUUpIFJUQ1AgUGFja2V0OiAgVGhpcyBSVFAvUlRDUCBw cm90b2NvbCBbUkZDMzU1MF0NCj4gICAgICAgICAgIG1lY2hhbmlzbSBpbmRpY2F0ZXMgdGhhdCBh IHBhcnRpY3VsYXIgUlRQIHN0cmVhbSBpcyBsZWF2aW5nIHRoZQ0KPiAgICAgICAgICAgUlRQIHNl c3Npb24uICBUaHVzLCBhIG1vc3QgcmVsZXZhbnQgZXZlbnQgdG8gaW5mb3JtIHRoZSBoYW5kbGVy DQo+ICAgICAgICAgICBmb3IgdGhpcyBSVFAgc3RlYW0gb2YuDQo+IA0KPiAgICAgVGhpcmQgUGFy dHkgVGFyZ2V0ZWQgUmVwb3J0cyBvciBGZWVkYmFjazogIFRoZXJlIGV4aXN0IHNvbWUNCj4gICAg ICAgIG11bHRpcGFydHkgUlRQIFRvcG9sb2dpZXMgdGhhdCByZXN1bHRzIGluIHRoYXQgYW4gZW5k cG9pbnQNCj4gICAgICAgIHJlY2VpdmVzIHRoaXJkIHBhcnR5IHJlcG9ydHMgKFNSIFtSRkMzNTUw XSwgUlIgW1JGQzM1NTBdIG9yIFhSDQo+ICAgICAgICBbUkZDMzYxMV0pIGFzIHdlbGwgYXMgRmVl ZGJhY2sgTWVzc2FnZXMgW1JGQzQ1ODVdIHRoYXQgcmVsYXRlcyB0bw0KPiAgICAgICAgb3IgdGFy Z2V0cyBhbiBTU1JDIHRoYXQgb3JpZ2luYXRlcyBmcm9tIGFub3RoZXIgZW5kcG9pbnQsIGFuZA0K PiAgICAgICAgd2hlcmUgdGhlIHNvdXJjZSBvZiB0aGUgUlRDUCBwYWNrZXQgaXMgYWxzbyBhbm90 aGVyIGVuZHBvaW50Lg0KPiAgICAgICAgVGhpcyB0eXBlIG9mIHBhY2tldHMgc2hvdWxkIGJlIGZv cndhcmRlZCB0byB0aGUgaGlnaGVyIGxheWVyDQo+ICAgICAgICBmdW5jdGlvbiBkZWFsaW5nIHdp dGggdGhlIHRoaXJkIHBhcnR5IHJlcG9ydGluZy4gIEFuZCBpZiBub25lDQo+ICAgICAgICBleGlz dCB0aGVuIHRoZXkgY2FuIGJlIHN1cHByZXNzZWQuICBBcyB0aGUgdGhpcmQgcGFydHkgaGFuZGxl ciBjYW4NCj4gICAgICAgIGJlIGZvY3VzZWQgb24gZGV0ZXJtaW5pbmcgdGhlIGNvbmRpdGlvbnMg Zm9yIHRoZSBzb3VyY2Ugb2YgdGhlDQo+ICAgICAgICByZXBvcnRzIGFuZCBmZWVkYmFjaywgb3Ig Zm9jdXNlZCBvbiBob3cgdGhlIFJUUCBzdHJlYW0gc291cmNlDQo+ICAgICAgICBwcm9ncmVzc2Vz LCBvciBib3RoIHJlY29tbWVuZGF0aW9ucyBjYW4ndCBiZSBtYWRlLg0KPiANCj4gICAgIEFQUCBQ YWNrZXRzOiAgVGhlIFJUQ1AgQVBQIFBhY2tldHMgW1JGQzM1NTBdIGFyZSBhIG1lY2hhbmlzbSB0 aGF0DQo+ICAgICAgICBlbmFibGVzIGV4cGVyaW1lbnRhdGlvbi4gIFRoZSBBUFAgcGFja2V0IG9u bHkgc3BlY2lmaWVzIHRoZSBzb3VyY2UNCj4gICAgICAgIG9mIHRoZSBwYWNrZXQuICBUaHVzIHRo aXMgaW5mb3JtYXRpb24gY2FuIGJlIHJlbGF0ZWQgdG8gYW55IG9mIHRoZQ0KPiAgICAgICAgIm09 IiBsaW5lcywgdGh1cyBkZWxpdmVyIGEgY29weSBvZiB0aGUgcGFja2V0IHRvIGVhY2ggIm09IiBs aW5lIG9yDQo+ICAgICAgICBhbiBBUFAgc3BlY2lmaWMgaGFuZGxlci4NCj4gDQo+IC0tDQo+IENo ZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2Vy dmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIv VFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhv bmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9i aWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0 bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dl YiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Thu Feb 2 14:20:06 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38FD129A39 for ; Thu, 2 Feb 2017 14:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-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 pevEJ3auJpmQ for ; Thu, 2 Feb 2017 14:20:03 -0800 (PST) Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 3F43D129A3A for ; Thu, 2 Feb 2017 14:20:03 -0800 (PST) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BDE902521B; Thu, 2 Feb 2017 17:19:57 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 09B9925214; Thu, 2 Feb 2017 17:19:56 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 02 Feb 2017 17:19:57 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 2 Feb 2017 15:19:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:20:05 -0000 > On Jan 31, 2017, at 10:43 AM, Jonathan Lennox = wrote: >=20 > In general, this looks good. >=20 > 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=3D line, but whose PT is not valid for that m=3D line? >=20 > Should it > 1. Cause the stream=E2=80=99s mapping to be moved to another m=3D = line, if the received PT is in the payload type table for some other m=3D = line? > or=20 > 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.=20 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.=20 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=20 1) if you have mid, use that and latch the SSRC 2) if you have a unique pt, use that and latch the SSRC=20 3) if you have a latched SSRC use that=20 If you had signaled SSRC, guess I would insert that as step 1.5 of use = that=20 From nobody Thu Feb 2 14:25:25 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3212957E; Thu, 2 Feb 2017 14:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 iyJYTFMcRNEW; Thu, 2 Feb 2017 14:25:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3696129A3C; Thu, 2 Feb 2017 14:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25030; q=dns/txt; s=iport; t=1486073995; x=1487283595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LMqyjwby9ejCRfdfajLlDdiinvNN0vXLdQBnErDdCuo=; b=O1kcjkDcuJ/AEsUu4c9T2btgHU2yK+Otbzgi5MrfEuOEpnjCruu3HLc3 cyJWjRYg5reGHXUleGlNRkGhpd9zF2CTaY2IpmAlAqNY5kwd0P84X3B3L mj+XFT5vS+T8k0oo/BGhALn7ojopRZLBtEBVhIz509eui+hjbESNZn8gv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQD7r5NY/5xdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMoK2GBCQeDCkaKCJILlTWCDR8LhS5KAhqCPT8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBAQMBAQEKFxEzBwsFCQICAQYCGAICHwQDAgICGQwLFAEQAgQOBYlpC?= =?us-ascii?q?A6PA51OgiWLLAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYEGh0WCaoQlKBeCby6?= =?us-ascii?q?CMQWGWYIshjGFeoYtAYZne4IjgyGEYIF7iXqFDYgoil4BHziBSxUYIxEBhDIdG?= =?us-ascii?q?YFIdYd3gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="207573262" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 22:19:54 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v12MJrMr018742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Feb 2017 22:19:54 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 17:19:53 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Thu, 2 Feb 2017 17:19:52 -0500 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5sVd9K8JGDU+bnDtTRZpMhQ== Date: Thu, 2 Feb 2017 22:19:52 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> In-Reply-To: <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <9A06325F7675CE4F89E5294AABE4600C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:25:17 -0000 DQpTbyBJIG11Y2ggcHJlZmVyIHRoZSBjdXJyZW50IHRleHQgYW5kIHRoaW5rIHRoZXJlIGFyZSBh IGJ1bmNoIG9mIHByb2JsZW1zIHdpdGggdGhpcyB0ZXh0LiBJZiB3ZSBhY3R1YWxseSBoYWQgZW1h aWxzIGV4cGxhaW5pbmcgd2hhdCBwcm9ibGVtcyBpbiB0aGUgY3VycmVudCB0ZXh0IHRoaXMgd2Fz IHRyeWluZyB0byBmaXgsIHdpdGggaW5kaXZpZHVhbCBQUnMgZm9yIHRob3NlLCB0aGlzIHdvdWxk IGJlIG11Y2ggZWFzaWVyIHRvIHJlc29sdmUgZWFjaCBvZiB0aGVtIGFuZCBnZXQgdGhlbSBmaXhl ZC4NCg0KMSkgd2UgaGF2ZSBiZWVuIHRyeWluZyB0byBhdm9pZCB0aGUgdXNlIG9mICJSVFAgc2Vz c2lvbiIgYXMgaXQgaGFzIGJlZW4gdmVyeSB1bmNsZWFyIHRvIGltcGxlbWVudG9ycyB3aGF0IGl0 IGlzLiBJIHRoaW5rIHRoaXMgd291bGQgYmUgYmV0dGVyIGlmIHdlIGNvdWxkIHJlcGhyYXNlIHRv IG5vdCB1c2UgdGhhdA0KDQoyKSBib3RoIHRoZSBwcm9wb3NlZCBhbmQgY3VycmVudCB0ZXh0IHNl ZW0gbGFja2luZyBpbiBkZWFsaW5nIHdpdGggbXVsdGlwbGUgYnVuZGxlIGdyb3VwcyANCg0KMykg U3RhdHMgYXJlIHR5cGljYWxseSBtYWludGFpbmVkIGJ5IHRoaW5ncyBhZnRlciB0aGUgcGFja2V0 IGlzIHJvdXRlZCAtIG5vdCBiZWZvcmUuIA0KDQo0KSBOZWVkIHRvIGV4cGxhaW4gaG93IHRoZSBT REVTIGluIGNvbXBvdW5kIFJUQ1AgY2F1c2VzIHVwZGF0ZXMgDQoNCjUpIGdpdmVuIHRoaXMgcmVt b3ZlcyB0aGUgb3V0Z29pbmcgU1NSQyB0YWJsZSwgbm90IGNsZWFyIGhvdyBpdCByb3V0ZXMgUlRD UCByZXBvcnRzLiBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLiANCg0KNikgSSBk b24ndCB0aGluayBtb3N0IGltcGxlbWVudGVycyBhcmUgZ29pbmcgdG8gaGF2ZSBhIGNsdWUgd2hh dCB0byBkbyBmb3IgdGhlICJUaGlyZCBQYXJ0eSBUYXJnZXRlZCBSZXBvcnRzIG9yIEZlZWRiYWNr IiBzZWN0aW9uDQoNCkkgd2lsbCB0cnkgYW5kIHRha2UgeW91ciBQUiBhbmQgYnJlYWsgaXQgdXAg aW50byBzb21lIGJpdCBzaXplIHBpZWNlcyBzbyB3ZSBjYW4gdHJ5IGFuZCBzZWUgaWYgd2UgY2Fu IGdldCB0aGUgZWFzeSBvbmVzIG91dCBvZiB0aGUgd2F5IGFuZCBmb2N1cyBvbiB0aGUgcGFydHMg dGhhdCBhcmUga2V5IGNoYW5nZXMuIA0KDQoNCg0KPiBPbiBKYW4gMzAsIDIwMTcsIGF0IDY6MTgg QU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdy b3RlOg0KPiANCj4gSGksDQo+IA0KPiBJIGhhdmUgbm93IGdlbmVyYXRlZCBhIHB1bGwgcmVxdWVz dCBmb3IgdGhpcyB0ZXh0LCB3aXRoIHNvbWUgdmVyeSBtaW5vciBjaGFuZ2VzLg0KPiANCj4gaHR0 cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL3B1bGwvNTM4DQo+IA0KPiBDaGVlcnMNCj4g DQo+IE1hZ251cw0KPiANCj4gRGVuIDIwMTctMDEtMjcga2wuIDE3OjQzLCBza3JldiBNYWdudXMg V2VzdGVybHVuZDoNCj4+IE1NVVNJQyBhbmQgUlRDV0VCLA0KPj4gDQo+PiBIZXJlIGlzIG5vdyBh IG1vcmUgY29tcGxldGUgdGV4dCBwcm9wb3NhbCB0aGF0IGFsc28gY29uc2lkZXJzIHRoZSBSVENQ Lg0KPj4gSXQgYWxzbyBnb2VzIGZ1cnRoZXIgdGhhbiB3aGF0IEFwcGVuZGl4IEIgZGVmaW5lcyBp biBvbmUgYXNwZWN0LCBuYW1lbHkNCj4+IGV4cGxpY2l0bHkgY29uc2lkZXJpbmcgdGhpcmQgcGFy dHkgUlRDUCByZXBvcnRpbmcgYW5kIHdoYXQgdG8gZG8gd2l0aCBpdC4NCj4+IA0KPj4gRmVlZGJh Y2sgaXMgbXVjaCBhcHByZWNpYXRlZC4gSSBwbGFuIHRvIHB1dCB0aGlzIGludG8gYSBQUiB0b3dh cmRzIEpTRVANCj4+IEFQUEVORElYIEIgb24gbW9uZGF5LiBJZiBvbmx5IHRvIGdldCB0aGUgSlNF UCBhdXRob3JzIGF0dGVudGlvbiA7LSkuDQo+PiBIb3dldmVyLCB0aGUgdGV4dCBpcyByZWFsbHkg aW50ZW5kZWQgZm9yIHRoZSBuZXh0IHZlcnNpb24gb2YgQlVORExFLg0KPj4gDQo+PiANCj4+IFgu ICBBc3NvY2lhdGluZyBSVFAvUlRDUCBXaXRoIENvcnJlY3QgU0RQIE1lZGlhIERlc2NyaXB0aW9u DQo+PiANCj4+ICAgQXMgZGVzY3JpYmVkIGluIFtSRkMzNTUwXSwgUlRQIHBhY2tldHMgYXJlIGFz c29jaWF0ZWQgd2l0aCBSVFANCj4+ICAgc3RyZWFtcyBbUkZDNzY1Nl0uICBFYWNoIFJUUCBzdHJl YW0gaXMgaWRlbnRpZmllZCBieSBhbiBTU1JDIHZhbHVlLA0KPj4gICBhbmQgZWFjaCBSVFAgcGFj a2V0IGNhcnJpZXMgYW4gU1NSQyB2YWx1ZSB0aGF0IGlzIHVzZWQgdG8gYXNzb2NpYXRlDQo+PiAg IHRoZSBwYWNrZXQgd2l0aCB0aGUgY29ycmVjdCBSVFAgc3RyZWFtLiAgUlRDUCBwYWNrZXRzIGFs c28gdXNlcyBTU1JDcw0KPj4gICB0byBpZGVudGlmeSBvbiB3aGljaCBSVFAgc3RyZWFtcyBhbnkg cmVwb3J0IG9yIGZlZWRiYWNrIHJlbGF0ZSB0by4NCj4+ICAgVGh1cywgYW4gUlRDUCBwYWNrZXQg d2lsbCBjb21tb25seSBjYXJyeSBtdWx0aXBsZSBTU1JDIHZhbHVlcywgYW5kDQo+PiAgIG1pZ2h0 IHRoZXJlZm9yZSBiZSBwcm92aWRpbmcgZmVlZGJhY2sgb3IgcmVwb3J0IG9uIG11bHRpcGxlIFJU UA0KPj4gICBzdHJlYW1zLg0KPj4gDQo+PiAgIEluIG9yZGVyIHRvIGJlIGFibGUgdG8gcHJvY2Vz cyByZWNlaXZlZCBSVFAvUlRDUCBwYWNrZXRzIGNvcnJlY3RseSBpdA0KPj4gICBtdXN0IGJlIHBv c3NpYmxlIHRvIGFzc29jaWF0ZSBhbiBSVFAgc3RyZWFtIHdpdGggdGhlIGNvcnJlY3QgIm09Ig0K Pj4gICBsaW5lLCBhcyB0aGUgIm09IiBsaW5lIGFuZCBTRFAgYXR0cmlidXRlcyBhc3NvY2lhdGVk IHdpdGggdGhlICJtPSINCj4+ICAgbGluZSBjb250YWluIGluZm9ybWF0aW9uIG5lZWRlZCB0byBw cm9jZXNzIHRoZSBwYWNrZXRzLg0KPj4gDQo+PiAgIEFzIGFsbCBSVFAgc3RyZWFtcyBhc3NvY2lh dGVkIHdpdGggYSBCVU5ETEUgZ3JvdXAgYXJlIHBhcnQgb2YgdGhlDQo+PiAgIHNhbWUgUlRQIHNl c3Npb24gYW5kIHVzaW5nIHRoZSBzYW1lIGFkZHJlc3M6cG9ydCBjb21iaW5hdGlvbiBmb3INCj4+ ICAgc2VuZGluZyBhbmQgcmVjZWl2aW5nIFJUUC9SVENQIHBhY2tldHMsIHRoZSBsb2NhbCBhZGRy ZXNzOnBvcnQNCj4+ICAgY29tYmluYXRpb24gY2Fubm90IGJlIHVzZWQgdG8gYXNzb2NpYXRlIGFu IFJUUCBzdHJlYW0gd2l0aCB0aGUNCj4+ICAgY29ycmVjdCAibT0iIGxpbmUuICBJbiBhZGRpdGlv biwgbXVsdGlwbGUgUlRQIHN0cmVhbXMgbWlnaHQgYmUNCj4+ICAgYXNzb2NpYXRlZCB3aXRoIHRo ZSBzYW1lICJtPSIgbGluZS4NCj4+IA0KPj4gICBBbHNvLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAxMC4xLjEsIHRoZSBzYW1lIHBheWxvYWQgdHlwZSB2YWx1ZQ0KPj4gICBtaWdodCBiZSB1c2Vk IGJ5IG11bHRpcGxlIFJUUCBzdHJlYW1zLCBpbiB3aGljaCBjYXNlIHRoZSBwYXlsb2FkIHR5cGUN Cj4+ICAgdmFsdWUgY2Fubm90IGJlIHVzZWQgdG8gYXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0 aCB0aGUgY29ycmVjdCAibT0iDQo+PiAgIGxpbmUuICBIb3dldmVyLCB0aGVyZSBhcmUgY2FzZXMg d2hlcmUgZWFjaCAibT0iIGxpbmUgaGFzIHVuaXF1ZQ0KPj4gICBwYXlsb2FkIHR5cGUgdmFsdWVz LCBhbmQgdGhlbiB0aGUgcGF5bG9hZCB0eXBlIGNvdWxkIHNlcnZlIGFzDQo+PiAgIGluZGljYXRv ciB0byB0aGUgcmVsZXZhbnQgIm09IiBsaW5lIHRoZSBSVFAgc3RyZWFtIGlzIGFzc29jaWF0ZWQN Cj4+ICAgd2l0aC4NCj4+IA0KPj4gICBBbiBvZmZlcmVyIGFuZCBhbnN3ZXJlciBjYW4gaW5mb3Jt IGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2YWx1ZXMgdGhleQ0KPj4gICB3aWxsIHVzZSBmb3IgYW4g UlRQIHN0cmVhbSBieSB1c2luZyB0aGUgU0RQICdzc3JjJyBhdHRyaWJ1dGUNCj4+ICAgW1JGQzU1 NzZdLiAgSG93ZXZlciwgYW4gb2ZmZXJlciB3aWxsIG5vdCBrbm93IHdoaWNoIFNTUkMgdmFsdWVz IHRoZQ0KPj4gICBhbnN3ZXJlciB3aWxsIHVzZSB1bnRpbCB0aGUgb2ZmZXJlciBoYXMgcmVjZWl2 ZWQgdGhlIGFuc3dlciBwcm92aWRpbmcNCj4+IA0KPj4gDQo+PiANCj4+IE5hbWUgICAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDMxLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQtVGl0bGUg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMTcNCj4+IA0KPj4gDQo+PiAgIHRoYXQgaW5mb3JtYXRp b24uICBEdWUgdG8gdGhpcywgYmVmb3JlIHRoZSBvZmZlcmVyIGhhcyByZWNlaXZlZCB0aGUNCj4+ ICAgYW5zd2VyLCB0aGUgb2ZmZXJlciB3aWxsIG5vdCBiZSBhYmxlIHRvIGFzc29jaWF0ZSBhbiBS VFAgc3RyZWFtIHdpdGgNCj4+ICAgdGhlIGNvcnJlY3QgIm09IiBsaW5lIHVzaW5nIHRoZSBTU1JD IHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQDQo+PiAgIHN0cmVhbS4gIEluIGFkZGl0aW9u LCB0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIgbWF5IHN0YXJ0IHVzaW5nIG5ldw0KPj4gICBTU1JD IHZhbHVlcyBtaWQtc2Vzc2lvbiwgd2l0aG91dCBpbmZvcm1pbmcgZWFjaCBvdGhlciB1c2luZyB0 aGUgU0RQDQo+PiAgICdzc3JjJyBhdHRyaWJ1dGUuDQo+PiANCj4+ICAgSW4gb3JkZXIgZm9yIGFu IG9mZmVyZXIgYW5kIGFuc3dlcmVyIHRvIGFsd2F5cyBiZSBhYmxlIHRvIGFzc29jaWF0ZQ0KPj4g ICBhbiBSVFAgc3RyZWFtIHdpdGggdGhlIGNvcnJlY3QgIm09IiBsaW5lLCB0aGUgb2ZmZXJlciBh bmQgYW5zd2VyZXINCj4+ICAgdXNpbmcgdGhlIEJVTkRMRSBleHRlbnNpb24gTVVTVCBzdXBwb3J0 IHRoZSBtZWNoYW5pc20gZGVmaW5lZCBpbg0KPj4gICBTZWN0aW9uIDE0LCB3aGVyZSB0aGUgb2Zm ZXJlciBhbmQgYW5zd2VyZXIgaW5jbHVkZXMgdGhlDQo+PiAgIGlkZW50aWZpY2F0aW9uLXRhZyAo cHJvdmlkZWQgYnkgdGhlIHJlbW90ZSBwZWVyKSBhc3NvY2lhdGVkIHdpdGggYW4NCj4+ICAgIm09 IiBsaW5lIGluIHRoZSBSVFAgU3RyZWFtcyBhbmQgaW4gUlRDUCBTREVTIHBhY2tldHMgcGFydCBv ZiBhDQo+PiAgIEJVTkRMRSBncm91cC4NCj4+IA0KPj4gICBUaGUgbWFwcGluZyBmcm9tIGFuIFNT UkMgdG8gYW4gaWRlbnRpZmljYXRpb24tdGFnIGlzIGNhcnJpZWQgaW4gUlRDUA0KPj4gICBTREVT IHBhY2tldHMgb3IgaW4gUlRQIGhlYWRlciBleHRlbnNpb25zIChTZWN0aW9uIDE0KS4gIFNpbmNl IGENCj4+ICAgY29tcG91bmQgUlRDUCBwYWNrZXQgY2FuIGNvbnRhaW4gbXVsdGlwbGUgUlRDUCBT REVTIHBhY2tldHMsIGFuZCBlYWNoDQo+PiAgIFJUQ1AgU0RFUyBwYWNrZXQgY2FuIGNvbnRhaW4g bXVsdGlwbGUgY2h1bmtzLCBhbiBSVENQIHBhY2tldCBjYW4NCj4+ICAgY29udGFpbiBzZXZlcmFs IFNTUkMgdG8gaWRlbnRpZmljYXRpb24tdGFnIG1hcHBpbmdzLiAgVGhlIG9mZmVyZXIgYW5kDQo+ PiAgIGFuc3dlcmVyIG1haW50YWluIHRhYmxlcyBtYXBwaW5nIFJUUCBzdHJlYW1zIGlkZW50aWZp ZWQgYnkgU1NSQyB0bw0KPj4gICAibT0iIGxpbmVzIGlkZW50aWZpZWQgYnkgdGhlIGlkZW50aWZp Y2F0aW9uLXRhZy4gIFRoZXNlIHRhYmxlcyBhcmUNCj4+ICAgdXBkYXRlZCBlYWNoIHRpbWUgbmV3 IGluZm9ybWF0aW9uIHRoYXQgYWZmZWN0cyBob3cgcGFja2V0cyBzaG91bGQgYmUNCj4+ICAgcHJv Y2Vzc2VkIGFuZCByb3V0ZWQgYXJlIHJlY2VpdmVkLg0KPj4gDQo+PiAgIFRvIHByZXBhcmUgZm9y IGRlbXVsdGlwbGV4aW5nIFJUUCBzdHJlYW1zIHRvIHRoZSBjb3JyZWN0ICJtPSIgbGluZSwNCj4+ ICAgdGhlIGZvbGxvd2luZyBzdGVwcyBNVVNUIGJlIGZvbGxvd2VkIGZvciBlYWNoIEJVTkRMRSBn cm91cCBiYXNlZCBvbg0KPj4gICB0aGUgU0RQIHNpZ25hbGxpbmcgaW5mb3JtYXRpb24uDQo+PiAN Cj4+ICAgICAgQ29uc3RydWN0IGEgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lIGZvciBl YWNoICJtPSIgbGluZSBpbg0KPj4gICAgICB0aGlzIEJVTkRMRSBncm91cC4gIE5vdGUgdGhhdCBh biAibT0iIGxpbmUgbWF5IG9ubHkgaGF2ZSBvbmUgTUlELg0KPj4gDQo+PiAgICAgIENvbnN0cnVj dCBhIHRhYmxlIG1hcHBpbmcgaW5jb21pbmcgUlRQIHN0cmVhbXMgKFNTUkNzKSB0byB0aGVpcg0K Pj4gICAgICAibT0iIGxpbmUgZm9yIGVhY2ggIm09IiBsaW5lIGluIHRoaXMgQlVORExFIGdyb3Vw IGFuZCBmb3IgZWFjaCBSVFANCj4+ICAgICAgc3RyZWFtIGV4cGxpY2l0bHkgc2lnbmFsbGVkIGZv ciByZWNlaXZpbmcgaW4gdGhhdCAibT0iIGxpbmUuDQo+PiANCj4+ICAgICAgQ29uc3RydWN0IGEg dGFibGUgbWFwcGluZyBwYXlsb2FkIHR5cGVzIHRvICJtPSIgbGluZSBmb3IgZWFjaCAibT0iDQo+ PiAgICAgIGxpbmUgaW4gdGhlIEJVTkRMRSBncm91cCBhbmQgZm9yIGVhY2ggcGF5bG9hZCB0eXBl IGNvbmZpZ3VyZWQgZm9yDQo+PiAgICAgIHJlY2VpdmluZyBpbiB0aGF0ICJtPSIgbGluZS4gIElm IGFueSBwYXlsb2FkIHR5cGUgaXMgY29uZmlndXJlZA0KPj4gICAgICBmb3IgcmVjZWl2aW5nIGlu IG1vcmUgdGhhbiBvbmUgIm09IiBsaW5lIGluIHRoZSBCVU5ETEUgZ3JvdXAsIGRvDQo+PiAgICAg IG5vdCBpdCBpbmNsdWRlIGl0IGluIHRoZSB0YWJsZS4NCj4+IA0KPj4gICBOb3RlIHRoYXQgZm9y IGVhY2ggb2YgdGhlc2UgdGFibGVzLCB0aGVyZSBjYW4gb25seSBiZSBvbmUgbWFwcGluZyBmb3IN Cj4+ICAgYW55IGdpdmVuIGtleSAoTUlELCBTU1JDLCBvciBQVCkuICBJbiBvdGhlciB3b3Jkcywg dGhlIHRhYmxlcyBhcmUgbm90DQo+PiAgIG11bHRpbWFwcy4NCj4+IA0KPj4gICBBcyAibT0iIGxp bmVzIGFyZSBhZGRlZCBvciByZW1vdmVkIGZyb20gdGhlIEJVTkRMRSBncm91cHMsIG9yIHRoZWly DQo+PiAgIGNvbmZpZ3VyYXRpb25zIGFyZSBjaGFuZ2VkLCB0aGUgdGFibGVzIGFib3ZlIE1VU1Qg YWxzbyBiZSB1cGRhdGVkLg0KPj4gDQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQo+PiAN Cj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAg ICAgICAgIEphbnVhcnkgMjAxNw0KPj4gDQo+PiANCj4+ICAgUmVjZWl2ZWQgUlRQIHBhY2tldHMg dGhhdCBhcmUgc3ludGFjdGljYWxseSBjb3JyZWN0IGFyZSBwcm9jZXNzZWQgYnkNCj4+ICAgdGhl IFJUUC9SVENQIHByb3RvY29sIGltcGxlbWVudGF0aW9uIGZvciBzdGF0aXN0aWNzIGV0Yy4gIEFm dGVyIHRoaXMNCj4+ICAgcHJvY2Vzc2luZyB0aGV5IG5lZWQgdG8gYmUgcm91dGVkIHRvIHRoZSBo aWdoZXIgbGF5ZXIgY29udGV4dA0KPj4gICBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZSB3 aXRoaW4gdGhlIEJVTkRMRSBncm91cC4gIFNvbWV3aGVyZSBpbg0KPj4gICB0aGUgcHJvY2VzcyB3 aGVyZSBhbiByZWNlaXZlZCBSVFAgcGFja2V0IGlzIHByb2Nlc3NlZCB0byBiZSBkZWxpdmVyZWQN Cj4+ICAgdG8gdGhlIGhpZ2hlciBsYXllciBieSBSVFAgdGhlIG1hdGNoaW5nIHN0ZXAgYmVsb3cg TVVTVCBiZSBwZXJmb3JtZWQ6DQo+PiANCj4+ICAgMS4gIFJlY2VwdGlvbiBvZiBhbiBSVFAgcGFj a2V0IGZvciBhbiBSVFAgc3RyZWFtIHRoYXQgaGFzIGFuIGV4aXN0aW5nDQo+PiAgICAgICBtYXBw aW5nIGluIHRoZSBSVFAgc3RyZWFtIHRvIG09IGxpbmUgdGFibGUuICBCZWZvcmUgcHJvY2VlZGlu ZyBpbg0KPj4gICAgICAgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBoaWdoZXIgbGF5ZXIg Y29udGV4dCBhY2NvcmRpbmcgdG8NCj4+ICAgICAgIHRoZSBSVFAgc3RyZWFtIHRvICJtPSIgbGlu ZSBtYXBwaW5nIHRhYmxlIHRoZSBmb2xsb3dpbmcgY2hlY2tzDQo+PiAgICAgICBNVVNUIGJlIHBl cmZvcm1lZDoNCj4+IA0KPj4gICAgICAgQS4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhbiBSVFAg aGVhZGVyIGV4dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4+ICAgICAgICAgICB2YWx1ZSB0aGF0 IGlzIG5vdCBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB0aGVuDQo+PiAg ICAgICAgICAgZG8gbm90IGRlbGl2ZXIgdGhlIFJUUCBwYWNrZXQgdG8gaGlnaGVyIGxheWVycy4N Cj4+IA0KPj4gICAgICAgQi4gIElmIHRoZSBwYWNrZXQgY2FycmllcyBhbiBSVFAgaGVhZGVyIGV4 dGVuc2lvbiB3aXRoIGEgU0RFUyBNSUQNCj4+ICAgICAgICAgICB2YWx1ZSB0aGF0IGlzIGluIHRo ZSB0YWJsZSBtYXBwaW5nIE1JRCB0byAibT0iIGxpbmUsIGFuZCB0aGUNCj4+ICAgICAgICAgICB2 YWx1ZSBpbmRpY2F0ZXMgYSBkaWZmZXJlbnQgIm09IiBsaW5lIHRoYW4gdGhlIGN1cnJlbnQgUlRQ DQo+PiAgICAgICAgICAgc3RyZWFtIHRvICJtPSIgbGluZSBtYXBwaW5nIHRhYmxlLCB0aGVuIHVw ZGF0ZSB0aGUgUlRQIHN0cmVhbQ0KPj4gICAgICAgICAgIHRvICJtPSIgbGluZSBtYXBwaW5nLg0K Pj4gDQo+PiAgIDIuICBSZWNlcHRpb24gb2YgYW4gUlRQIHBhY2tldCBmb3IgYW4gUlRQIHN0cmVh bSB0aGF0IGhhcyBubyBleGlzdGluZw0KPj4gICAgICAgbWFwcGluZyB0byBhbiBtPSBsaW5lLiAg SW4gdGhpcyBjYXNlIHRoZSBmb2xsb3dpbmcgYWN0aW9ucyBNVVNUDQo+PiAgICAgICBiZSBwZXJm b3JtZWQ6DQo+PiANCj4+ICAgICAgIEEuICBJZiB0aGUgcGFja2V0IGNhcnJpZXMgYW4gUlRQIGhl YWRlciBleHRlbnNpb24gd2l0aCBhIFNERVMgTUlEDQo+PiAgICAgICAgICAgdmFsdWUgdGhhdCBp cyBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB0aGVuDQo+PiAgICAgICAg ICAgY3JlYXRlIGFuIGVudHJ5IGluIHRoZSBSVFAgc3RyZWFtIHRvICJtPSIgbGluZSBtYXBwaW5n IHRhYmxlDQo+PiAgICAgICAgICAgZm9yIHRoaXMgUlRQIHN0cmVhbSAoU1NSQykuICBUaGVuIGRl bGl2ZXIgdGhlIFJUUCBwYWNrZXQgdG8NCj4+ICAgICAgICAgICB0aGUgIm09IiBsaW5lIGNvbnRl eHQgb2YgdGhlIGNyZWF0ZWQgbWFwcGluZyBhbmQgc3RvcC4NCj4+IA0KPj4gICAgICAgQi4gIElm IHRoZSBwYWNrZXQgY2FycmllcyBhIFBheWxvYWQgVHlwZSB0aGF0IGlzIGluIHRoZSBwYXlsb2Fk DQo+PiAgICAgICAgICAgdHlwZSB0YWJsZSwgdGhlbiBjcmVhdGUgYW4gZW50cnkgaW4gdGhlIFJU UCBzdHJlYW0gdG8gIm09Ig0KPj4gICAgICAgICAgIGxpbmUgbWFwcGluZyB0YWJsZSBmb3IgdGhp cyBSVFAgc3RyZWFtIChTU1JDKS4gIFRoZW4gZGVsaXZlcg0KPj4gICAgICAgICAgIHRoZSBSVFAg cGFja2V0IHRvIHRoZSAibT0iIGxpbmUgY29udGV4dCBvZiB0aGUgY3JlYXRlZA0KPj4gICAgICAg ICAgIG1hcHBpbmcgYW5kIHN0b3AuDQo+PiANCj4+ICAgICAgIEMuICBPdGhlcndpc2UgZG8gbm90 IGRlbGl2ZXIgdGhlIFJUUCBwYWNrZXQgdG8gaGlnaGVyIGxheWVycy4NCj4+ICAgICAgICAgICBO b3RlLCB0aGlzIGluY2x1ZGVzIHVua25vd24gTUlEIHZhbHVlcy4NCj4+IA0KPj4gICBGb3IgZWFj aCBSVENQIHBhY2tldCByZWNlaXZlZCAoaW5jbHVkaW5nIGVhY2ggUlRDUCBwYWNrZXQgdGhhdCBp cw0KPj4gICBwYXJ0IG9mIGEgY29tcG91bmQgUlRDUCBwYWNrZXQpLCB0aGUgUlRDUCBwYWNrZXQg bmVlZHMgdG8gYmUNCj4+ICAgcHJvY2Vzc2VkIGJ5IHRoZSBSVFAvUlRDUCBpbXBsZW1lbnRhdGlv biBhbmQgcmVsZXZhbnQgaW5mb3JtYXRpb24gYW5kDQo+PiAgIGRhdGEgZnJvbSB0aGUgUlRDUCBw YWNrZXRzIG5lZWRzIHRvIGJlIHJvdXRlZCB0byB0aGUgYXBwcm9wcmlhdGUNCj4+ICAgaGFuZGxl ciBmb3IgdGhlIHJlbGF0ZWQgUlRQIHN0cmVhbXMuICBUaGUgYXBwcm9wcmlhdGUgaGFuZGxlciBp cw0KPj4gICBkZXRlcm1pbmVkIGJ5IHVzaW5nIHRoZSBSVFAgc3RyZWFtIHRvICJtPSIgbGluZSBt YXBwaW5nIHRhYmxlLg0KPj4gDQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEp1bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQo+PiANCj4+ IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAg ICAgIEphbnVhcnkgMjAxNw0KPj4gDQo+PiANCj4+ICAgT24gcmVjZXB0aW9uIG9mIGFueSBjb21w b3VuZCBSVENQIHBhY2tldCBwcmlvciB0byBkaXNwYXRjaGluZyB0aGUNCj4+ICAgcmVjZWl2ZWQg aW5mb3JtYXRpb24gYW5kIGRhdGEsIGlmIHRoZXJlIGlzIGFuIFJUQ1AgU0RFUyBwYWNrZXQNCj4+ ICAgaW5jbHVkZWQgdGhhdCBTSE9VTEQgYmUgcHJvY2Vzc2VkIGZpcnN0LiAgSWYgdGhhdCBTREVT IHBhY2tldA0KPj4gICBjb250YWlucyBTREVTIE1JRCBlbnRyaWVzLCB0aGlzIGNhbiByZXN1bHRz IGluIHVwZGF0ZXMgYW5kIGFkZGl0aW9ucw0KPj4gICB0byB0aGUgUlRQIHN0cmVhbSB0byAibT0i IGxpbmUgbWFwcGluZyB0YWJsZS4gIFRodXMgZWFjaCBvZiB0aGUgU0RFUw0KPj4gICBNSUQgaXRl bXMgYXJlIHByb2Nlc3NlZCBhbmQgdGhlIGN1cnJlbnQgdGFibGUgZW50cmllcyBhcmUgY2hlY2tl ZCBpZg0KPj4gICB0aGUgY29ycmVzcG9uZGluZyBNSUQgdmFsdWUgbWF0Y2hlcyB0aGUgY3VycmVu dCBSVFAgc3RyZWFtIHRvICJtPSINCj4+ICAgbGluZSBtYXBwaW5nLCBlbHNlIHRoZSBlbnRyeSBp cyB1cGRhdGVkLiAgSWYgdGhlcmUgaXMgbm8gUlRQIHN0cmVhbQ0KPj4gICB0byAibT0iIGxpbmUg dGFibGUgbWFwcGluZyBlbnRyeSBmb3IgdGhlIHJlY2VpdmVkIFNERVMgaXRlbSdzIFNTUkMsDQo+ PiAgIHN1Y2ggYW4gZW50cnkgaXMgY3JlYXRlZC4gIE5vdGUsIHRoYXQgaW4gdGhlIHByb2Nlc3Mg b2YgdXBkYXRpbmcgdGhlDQo+PiAgIHRhYmxlIGVudHJpZXMsIHVwZGF0ZSBmbGFwIHN1cHByZXNz aW9uIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQuMi42DQo+PiAgIG9mIFtSRkM3OTQxXSBzaG91 bGQgYmUgY29uc2lkZXJlZC4NCj4+IA0KPj4gICBUaGUgdmFyaW91cyBkaWZmZXJlbnQgUlRDUCBw YWNrZXRzIGFzIHdlbGwgYXMgdGhlaXIgdmFyaW91cyBzdWINCj4+ICAgcGFydHMsIHN1Y2ggYXMg dGhlIHZhcmlvdXMgUlRDUCBGZWVkYmFjayBtZXNzYWdlIHR5cGVzLCByZWxhdGVzIHRvDQo+PiAg IHRoZSBSVFAgc3RyZWFtcyBpbiBhIGNvdXBsZSBvZiBkaWZmZXJlbnQgd2F5cy4gIFRoZSBjdXJy ZW50bHkga25vd24NCj4+ICAgcGF0dGVybnMgYXJlIHRoZSBmb2xsb3dpbmc6DQo+PiANCj4+ICAg UmVwb3J0cyBvbiBvdXRnb2luZyBSVFAgc3RyZWFtczogIEZvciBhbGwgUlRQIHN0cmVhbXMgdGhh dCB0aGlzDQo+PiAgICAgIGVuZHBvaW50IGlzIHRoZSBzb3VyY2Ugb2YsIGl0IGNhbiBleHBlY3Qg dG8gcmVjZWl2ZSByZXBvcnQgYmxvY2tzDQo+PiAgICAgIG9mIHNldmVyYWwgdHlwZXMgaWRlbnRp ZmllZCBhcyByZWxhdGluZyB0byBhbiBvdXRnb2luZyBzdHJlYW0uDQo+PiAgICAgIFRoZSBiYXNp YyBwYXR0ZXJuIGZvciB0aGVzZSBibG9ja3MgYXJlIHRoYXQgdGhlIFJUQ1AgcGFja2V0IGhlYWRl cg0KPj4gICAgICBpZGVudGlmaWVzIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcG9ydHMsIGFzIGlkZW50 aWZpZWQgYnkgYW4gU1NSQywNCj4+ICAgICAgYW5kIGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgcmVw b3J0IGJsb2Nrcywgd2hlcmUgZWFjaCByZXBvcnQgYmxvY2sNCj4+ICAgICAgaWRlbnRpZmllcyB0 aGUgUlRQIHN0cmVhbSwgdXNpbmcgdGhlIFNTUkMsIHRoZSByZXBvcnQgcmVsYXRlcyB0by4NCj4+ ICAgICAgRm9yIHRoaXMgcGF0dGVybiB0aGUgcmVsZXZhbnQgcmVwb3J0IGluZm9ybWF0aW9uIGlz IHByb3ZpZGVkIHRvDQo+PiAgICAgIHRoZSBoaWdoZXIgbGF5ZXIgYXNzb2NpYXRlZCB3aXRoIHRo ZSAibT0iIGxpbmUgdGhlIFJUUCBTdHJlYW0gdG8NCj4+ICAgICAgIm09IiBsaW5lIHRhYmxlIGlk ZW50aWZpZXMuICBUaGUgc291cmNlIFNTUkMgYXMgaWRlbnRpZmllciBvZiB0aGUNCj4+ICAgICAg ZW5kcG9pbnQgdGhhdCB0aGUgcmVwb3J0IG9yaWdpbmF0ZXMgYXJlIHJlbGV2YW50IGZvciBpbnRl cnByZXRpbmcNCj4+ICAgICAgdGhlIGluZm9ybWF0aW9uLCBidXQgbm90IG5lY2Vzc2FyaWx5IGZv ciByb3V0aW5nLiAgRXhhbXBsZSBvZiB0aGlzDQo+PiAgICAgIGlzIHBhdHRlcm4gYXJlOg0KPj4g DQo+PiAgICAgIFNlbmRlciBSZXBvcnQgKFNSKSBhbmQgUmVjZWl2ZXIgUmVwb3J0IChSUikgIFRo ZSBiYXNpYyByZWNlaXZlcg0KPj4gICAgICAgICByZXBvcnQgYmxvY2tzIGZyb20gUkZDMzU1MCBz dGFydCB3aXRoIHRoZSBTU1JDIG9mIHRoZSBSVFANCj4+ICAgICAgICAgc3RyZWFtIHRoZXkgcmVw b3J0IG9uLg0KPj4gDQo+PiAgICAgIEV4dGVuZGVkIFJlcG9ydHMgKFhSKTogIFJGQzM2MTEgaXMg YSBmcmFtZXdvcmsgdGhhdCBlbmFibGVzIGENCj4+ICAgICAgICAgbGFyZ2UgbnVtYmVyIG9mIGRp ZmZlcmVudCByZXBvcnRzLiAgSG93ZXZlciwgYSBsYXJnZSBudW1iZXIgb2YNCj4+ICAgICAgICAg dGhlc2UgcmVwb3J0IGZvcm1hdHMgYXJlIHJlcG9ydGluZyBvbiBzcGVjaWZpYyBSVFAgc3RyZWFt cyBhbmQNCj4+ICAgICAgICAgdGh1cyBlYWNoIGluZGl2aWR1YWwgcmVwb3J0IG9mIHRoZXNlIHR5 cGVzIGNvbnRhaW5zIGEgU1NSQw0KPj4gICAgICAgICBmaWVsZCB0byBpZGVudGlmeSB0aGUgUlRQ IHN0cmVhbS4NCj4+IA0KPj4gICBSVENQIEZlZWRiYWNrIE1lc3NhZ2VzIGZvciBvdXRnb2luZyBS VFAgc3RyZWFtczogIFRoZSBSRkMgNDU4NSBSVENQDQo+PiAgICAgIGZlZWRiYWNrIG1lc3NhZ2Vz IGFsbG93IGZvciBhIG51bWJlciBvZiBkaWZmZXJlbnQgdHlwZSBvZiBmZWVkYmFjaw0KPj4gICAg ICBtZXNzYWdlcy4gIEhvd2V2ZXIsIHRoZSBSVENQIGZlZWRiYWNrIG1lc3NhZ2UgaGVhZGVyIGNv bnRhaW5zIHRoZQ0KPj4gICAgICBTU1JDIGlkZW50aWZ5aW5nIHRoZSBzb3VyY2Ugb2YgdGhlIGZl ZWRiYWNrIG1lc3NhZ2VzIGFzIHdlbGwgYXMNCj4+ICAgICAgdGhlIGFjdHVhbCB0eXBlIG9mIHRo ZSBmZWVkYmFjay4gIFNvbWUgb2YgdGhlIGZlZWRiYWNrIG1lc3NhZ2VzDQo+PiAgICAgIGFsc28g dXNlcyB0aGUgdGFyZ2V0IFNTUkMgZmllbGQgaW4gdGhlIGhlYWRlciB0byBpZGVudGlmeSB3aGlj aA0KPj4gDQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMzEsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQo+PiANCj4+IEludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkg MjAxNw0KPj4gDQo+PiANCj4+ICAgICAgUlRQIHN0cmVhbSB0aGUgZmVlZGJhY2sgaXMgcmVsYXRl ZCB0by4gIEZvciB0aGVzZSB0eXBlcyBhbGwgdGhlDQo+PiAgICAgIEZDSSBlbnRyaWVzLCBpZiBt dWx0aXBsZSBvbmVzIGFyZSBmb3J3YXJkZWQgdG8gdGhlIGlkZW50aWZpZWQNCj4+ICAgICAgaGFu ZGxlci4gIEV4YW1wbGVzIG9mIHRoaXMgcGF0dGVybiBhcmU6DQo+PiANCj4+ICAgICAgUGljdHVy ZSBMb3NzIEluZGljYXRpb24gKFBMSSk6ICBSRkMgNDU4NSAoUFQ9UFNGQiwgRk1UPTEpLg0KPj4g DQo+PiAgICAgIFNsaWNlIExvc3MgSW5kaWNhdGlvbiAoU0xJKTogIFJGQyA0NTg1IChQVD1QU0ZC LCBGTVQ9MikuDQo+PiANCj4+ICAgICAgUmVmZXJlbmNlIFBpY3R1cmUgU2VsZWN0aW9uIEluZGlj YXRpb24gKFJQU0kpOiAgUkZDIDQ1ODUgKFBUPVBTRkIsDQo+PiAgICAgICAgIEZNVD0zKS4NCj4+ IA0KPj4gICAgICBHZW5lcmljIE5BQ0s6ICBbUkZDNDU4NV0gKFBUPVJUUEZCIGFuZCBGTVQ9MSku DQo+PiANCj4+ICAgICAgT3RoZXIgZmVlZGJhY2sgbWVzc2FnZXMgaW5jbHVkZXMgdGhlIHRhcmdl dCBTU1JDIGluIHRoZSBGZWVkYmFjaw0KPj4gICAgICBDb250cm9sIEluZm9ybWF0aW9uIChGQ0kp LiAgSGVyZSBlYWNoIEZDSSBuZWVkcyB0byBiZSBwcm9jZXNzZWQNCj4+ICAgICAgYW5kIHRoZSBT U1JDIGZpZWxkIGlkZW50aWZpZWQuICBBbmQgdGhlIGluZGl2aWR1YWwgRkNJIGNvbWJpbmVkDQo+ PiAgICAgIHdpdGggdGhlIFJUQ1AgcGFja2V0IGhlYWRlciBjb250ZXh0IG5lZWRzIHRvIGJlIGZv cndhcmRlZCB0byB0aGUNCj4+ICAgICAgaWRlbnRpZmllZCBoYW5kbGVyLiAgRXhhbXBsZSBvZiB0 aGlzIHBhdHRlcm4gYXJlOg0KPj4gDQo+PiAgICAgIEZ1bGwgSW50cmEgUmVxdWVzdCAoRklSKTog IFtSRkM1MTA0XSAoUFQ9UFNGQiwgRk1UPTQpLg0KPj4gDQo+PiAgICAgIFRlbXBvcmFsLVNwYXRp YWwgVHJhZGUtb2ZmIFJlcXVlc3QgKFRTVFIpOiAgW1JGQzUxMDRdIChQVD1QU0ZCLA0KPj4gICAg ICAgICBGTVQ9NSkuDQo+PiANCj4+ICAgICAgVGVtcG9yYWwtU3BhdGlhbCBUcmFkZS1vZmYgTm90 aWZpY2F0aW9uIChUU1ROKTogIFRoaXMgW1JGQzUxMDRdDQo+PiAgICAgICAgIGRlZmluZWQgbWVz c2FnZSAoUFQ9UFNGQiwgRk1UPTUpIGlzIGFjdHVhbGx5IGEgbm90aWZjaWF0aW9uIGluDQo+PiAg ICAgICAgIHJlc3BvbnNlIHRvIGEgVFNUUiB0aGlzIGVuZHBvaW50IHNlbnQgdXNpbmcgdGhlIFNT UkMgdGhlIEZDSQ0KPj4gICAgICAgICBpZGVudGlmaWVzIGFzIHNvdXJjZS4NCj4+IA0KPj4gICAg ICBILjI3MSBWaWRlbyBCYWNrIENoYW5uZWwgTWVzc2FnZSAoVkJDTSk6ICBbUkZDNTEwNF0gKFBU PVBTRkIsDQo+PiAgICAgICAgIEZNVD03KS4NCj4+IA0KPj4gICAgICBMYXllciBSZWZyZXNoIFJl cXVlc3QgKExSUik6ICBbSS1ELmlldGYtYXZ0ZXh0LWxycl0gKFBUPVBTRkIsDQo+PiAgICAgICAg IEZNVD1UQkQpLg0KPj4gDQo+PiAgIERlc2NyaXB0aXZlIG9yIE5vdGlmaWNhdGlvbnMgZm9yIGFu IGluY29taW5nIFJUUCBzdHJlYW06ICBUaGVyZSBleGlzdA0KPj4gICAgICBzb21lIFJUQ1AgcGFj a2V0IHR5cGVzIHRoYXQgcHJvdmlkZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBvcg0KPj4gICAg ICBub3RpZmllcyBhYm91dCBldmVudHMgcmVsYXRlZCB0byB0aGUgUlRQIHN0cmVhbSBpZGVudGlm aWVkLiAgSW4NCj4+ICAgICAgdGhlc2UgY2FzZXMgdGhlIFJUUCBzdHJlYW0gaXMgaWRlbnRpZmll ZCB1c2luZyB0aGUgU1NSQyBmaWVsZA0KPj4gICAgICB2YWx1ZSwgYW5kIHRoZSBpbmZvcm1hdGlv biBpcyBwcm92aWRlZCB0byB0aGUgaGlnaGVyIGxheWVyDQo+PiAgICAgIGFzc29jaWF0ZWQgd2l0 aCB0aGUgIm09IiBsaW5lIGZvciB0aGUgaW5jb21pbmcgUlRQIHN0cmVhbSBhcw0KPj4gICAgICBp ZGVudGlmaWVkIGJ5IHRoZSBjdXJyZW50IFJUUCBzdHJlYW0gdG8gIm09IiBsaW5lIHRhYmxlLiAg Rm9yIHRoaXMNCj4+ICAgICAgdHlwZSBvZiBwYXR0ZXJuIGl0IGlzIGNvbW1vbiB0aGF0IHRoZSBS VENQIHBhY2tldHMgYW5kIGluZm9ybWF0aW9uDQo+PiAgICAgIGlzIHJlcGVhdGVkLCBlaXRoZXIg cGVyaW9kaWNhbGx5IChlLmcuICBTREVTIGl0ZW1zKSwgb3IgZm9yIGENCj4+ICAgICAgZHVyYXRp b24gKGUuZy4gIEJZRSksIHRodXMgc3VwcHJlc3Npb24gb2YgcmVwZXRpdGlvbnMgY2FuIGJlDQo+ PiAgICAgIGNvbnNpZGVyZWQuICBFeGFtcGxlcyBvZiB0aGVzZSBhcmU6DQo+PiANCj4+IA0KPj4g DQo+PiANCj4+IA0KPj4gTmFtZSAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMzEs IDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQo+PiANCj4+IEludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBBYmJyZXZpYXRlZC1UaXRsZSAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNw0K Pj4gDQo+PiANCj4+ICAgICAgU291cmNlIERlc2NyaXB0aW9uIChTREVTKSBSVENQIFBhY2tldDog IFRoZSBiYXNlIFJUUC9SVENQIHByb3RvY29sDQo+PiAgICAgICAgIFtSRkMzNTUwXSBkZWZpbmVz IFNERVMgUlRDUCBwYWNrZXRzIGFzIGEgd2F5IG9mIHByb3ZpZGluZyBwZXINCj4+ICAgICAgICAg c291cmNlIChTU1JDKSBzcGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc291cmNlLiAgQW4g U0RFUw0KPj4gICAgICAgICBwYWNrZXQgY29udGFpbnMgemVybyBvciBtb3JlIGNodW5rcywgd2hl cmUgYSBjaHVuayBjb250YWlucyB0aGUNCj4+ICAgICAgICAgU1NSQyBmb3IgdGhlIHNvdXJjZSBi ZWluZyBkZXNjcmliZWQgYnkgdGhlIG9uZSBvciBtb3JlIGl0ZW1zDQo+PiAgICAgICAgIGluY2x1 ZGVkIGluIHRoZSBjaHVuay4gIEZvcndhcmQgdGhlIFNERVMgaXRlbXMgaW4gZWFjaCBjaHVuayB0 bw0KPj4gICAgICAgICB0aGUgUlRQIHN0cmVhbSdzIGhhbmRsZXIuDQo+PiANCj4+ICAgICAgR29v ZGJ5ZSAoQllFKSBSVENQIFBhY2tldDogIFRoaXMgUlRQL1JUQ1AgcHJvdG9jb2wgW1JGQzM1NTBd DQo+PiAgICAgICAgIG1lY2hhbmlzbSBpbmRpY2F0ZXMgdGhhdCBhIHBhcnRpY3VsYXIgUlRQIHN0 cmVhbSBpcyBsZWF2aW5nIHRoZQ0KPj4gICAgICAgICBSVFAgc2Vzc2lvbi4gIFRodXMsIGEgbW9z dCByZWxldmFudCBldmVudCB0byBpbmZvcm0gdGhlIGhhbmRsZXINCj4+ICAgICAgICAgZm9yIHRo aXMgUlRQIHN0ZWFtIG9mLg0KPj4gDQo+PiAgIFRoaXJkIFBhcnR5IFRhcmdldGVkIFJlcG9ydHMg b3IgRmVlZGJhY2s6ICBUaGVyZSBleGlzdCBzb21lDQo+PiAgICAgIG11bHRpcGFydHkgUlRQIFRv cG9sb2dpZXMgdGhhdCByZXN1bHRzIGluIHRoYXQgYW4gZW5kcG9pbnQNCj4+ICAgICAgcmVjZWl2 ZXMgdGhpcmQgcGFydHkgcmVwb3J0cyAoU1IgW1JGQzM1NTBdLCBSUiBbUkZDMzU1MF0gb3IgWFIN Cj4+ICAgICAgW1JGQzM2MTFdKSBhcyB3ZWxsIGFzIEZlZWRiYWNrIE1lc3NhZ2VzIFtSRkM0NTg1 XSB0aGF0IHJlbGF0ZXMgdG8NCj4+ICAgICAgb3IgdGFyZ2V0cyBhbiBTU1JDIHRoYXQgb3JpZ2lu YXRlcyBmcm9tIGFub3RoZXIgZW5kcG9pbnQsIGFuZA0KPj4gICAgICB3aGVyZSB0aGUgc291cmNl IG9mIHRoZSBSVENQIHBhY2tldCBpcyBhbHNvIGFub3RoZXIgZW5kcG9pbnQuDQo+PiAgICAgIFRo aXMgdHlwZSBvZiBwYWNrZXRzIHNob3VsZCBiZSBmb3J3YXJkZWQgdG8gdGhlIGhpZ2hlciBsYXll cg0KPj4gICAgICBmdW5jdGlvbiBkZWFsaW5nIHdpdGggdGhlIHRoaXJkIHBhcnR5IHJlcG9ydGlu Zy4gIEFuZCBpZiBub25lDQo+PiAgICAgIGV4aXN0IHRoZW4gdGhleSBjYW4gYmUgc3VwcHJlc3Nl ZC4gIEFzIHRoZSB0aGlyZCBwYXJ0eSBoYW5kbGVyIGNhbg0KPj4gICAgICBiZSBmb2N1c2VkIG9u IGRldGVybWluaW5nIHRoZSBjb25kaXRpb25zIGZvciB0aGUgc291cmNlIG9mIHRoZQ0KPj4gICAg ICByZXBvcnRzIGFuZCBmZWVkYmFjaywgb3IgZm9jdXNlZCBvbiBob3cgdGhlIFJUUCBzdHJlYW0g c291cmNlDQo+PiAgICAgIHByb2dyZXNzZXMsIG9yIGJvdGggcmVjb21tZW5kYXRpb25zIGNhbid0 IGJlIG1hZGUuDQo+PiANCj4+ICAgQVBQIFBhY2tldHM6ICBUaGUgUlRDUCBBUFAgUGFja2V0cyBb UkZDMzU1MF0gYXJlIGEgbWVjaGFuaXNtIHRoYXQNCj4+ICAgICAgZW5hYmxlcyBleHBlcmltZW50 YXRpb24uICBUaGUgQVBQIHBhY2tldCBvbmx5IHNwZWNpZmllcyB0aGUgc291cmNlDQo+PiAgICAg IG9mIHRoZSBwYWNrZXQuICBUaHVzIHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIHJlbGF0ZWQgdG8g YW55IG9mIHRoZQ0KPj4gICAgICAibT0iIGxpbmVzLCB0aHVzIGRlbGl2ZXIgYSBjb3B5IG9mIHRo ZSBwYWNrZXQgdG8gZWFjaCAibT0iIGxpbmUgb3INCj4+ICAgICAgYW4gQVBQIHNwZWNpZmljIGhh bmRsZXIuDQo+PiANCj4gDQo+IA0KPiAtLSANCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywg RXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFC ICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2 ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3Rv Y2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= From nobody Thu Feb 2 14:25:53 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D872129A2D for ; Thu, 2 Feb 2017 14:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 sh3W9GlBwYTi for ; Thu, 2 Feb 2017 14:25:36 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51547129A2C for ; Thu, 2 Feb 2017 14:25:36 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v77so9093335wmv.0 for ; Thu, 02 Feb 2017 14:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Dur5cq2+qm7oKDL+DeLsAsIjm1melt/31unwFpLMFf8=; b=Hpa26onW1NeEoBjDeumEZWALpCmxebrbLLnHauGhUZgCRoHZ01h7mNrBVSSUuM4bIX i2wZiCVd63zpyM9GmXClZTRB3BCsWlq3Q3GpWyDeP9SHi8tQGYh6+llvJwFFjWCH5O9s 1EzfuQzcVUgAuu7xhk0Z6tUKLfZAuZmKFjERKhGQpzZgMJqGdHJRSTGFWfIxDtjyA+pw 8/qSQnBEkhTRG9oHh9KehJEJpyBs7o6ucwdlnOiBlcAT4ozsYQ5wqB980E4sZl4wDqvf 5mNxmX14Keym4XoEwlWg1aoW2CgyJaCI6YQ4g2gMUBmTgQbuMiiwf/DHwbYHmdH5tunD VV9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Dur5cq2+qm7oKDL+DeLsAsIjm1melt/31unwFpLMFf8=; b=fel2Xo16ESHYWrddF/EsHLlYZhb3mAeo+oRESTZF0pqJSl+odLA9RcZnahTnVp5rql sWYKl1xPz26wflcXrBnNO9WifOUxA9bQ4+aH8c0+RFwgLteY/k0Nbp8UmX5+7lXeEZ6V wmMgondP8ey5GRtqtjUxOsYFjihOrYl56cEoYoBF56o+iIL964c7yvgOYIakMquXxP7X 2iQpYikVG6uxpFw5XqLQRqrTOIVlK8+aY4DJkv7wh34HV3y2wqGvtndOAV8jIyAlFDXf 1t54T5jEVcAD090c27/ZQIfnik3JqADfJFReI4tmzGzwxKJa8fyLhdMT1v2VY6bViioD kaGg== X-Gm-Message-State: AIkVDXLseSgoprDgmAbTjNpHgbs8eBs1jNld7k5qxq7Ikv+1y2J/tznD8jhU35fgWpW6gBbPy4V2VzQMBc/mcA== X-Received: by 10.223.134.104 with SMTP id 37mr9109931wrw.121.1486074334805; Thu, 02 Feb 2017 14:25:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Thu, 2 Feb 2017 14:25:14 -0800 (PST) In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 2 Feb 2017 23:25:14 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:25:38 -0000 2017-02-02 23:19 GMT+01:00 Cullen Jennings : > But imagine that A and B had an SSRC collision Very likely :) --=20 I=C3=B1aki Baz Castillo From nobody Thu Feb 2 16:42:55 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABECA129A50 for ; Thu, 2 Feb 2017 16:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yI-6ejMzIyNm for ; Thu, 2 Feb 2017 16:42:53 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E354129A4C for ; Thu, 2 Feb 2017 16:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1486082573; x=1487292173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/Jl22EsMvju9nKlx04WDlvhIQvMVJ8XxhRWL2zFhLII=; b=UXXga1Hd6edQzgVCOXicyQbzr1rbIAqYCaGdiOS5qGLPeIfi5X01UsvF Ct+x8kIy8W3XZ1D18wxM+xKkQkq222KkH51fwImCWqv/O4+9XVH7CD3FL jS9IWIqqDpTbIcKEJyyj+9ijLGbvZF/xR/rkskQDcnPci865PlrLELkjF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQC00ZNY/5ldJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNTYYEJB4NRigiSC5U2gg0fC4UuSgIagj0/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEDAQEBIRE6CwULAgEIGAICJgICAiULFRACBA4FiWkIDqxkgiWLPAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQuHRYJqhCaDLS6CMQWbXQGGZ4sfkQKTBgE?= =?us-ascii?q?fOIFLFTsRAYYwdQGIE4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="380807701" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2017 00:42:52 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v130gqrN006965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2017 00:42:52 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 19:42:51 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Thu, 2 Feb 2017 19:42:51 -0500 From: "Cullen Jennings (fluffy)" To: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24=?= Thread-Topic: [rtcweb] Identity in the SDP Thread-Index: AQHSfbZyYKPNaJdUrEGqyTsHHnyZ2A== Date: Fri, 3 Feb 2017 00:42:51 +0000 Message-ID: <37AAE77D-828B-40D3-9F53-36CA27080305@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <5BBBB11E7EC98346BA03D7EE37745C91@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Identity in the SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:42:54 -0000 DQphZGRlIGFzIA0KaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy81NDYN Cg0KDQo+IE9uIEphbiAzMCwgMjAxNywgYXQgNDo1NSBBTSwgU3RlZmFuIEjDpWthbnNzb24gTEsg PHN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwN Cj4gDQo+IHRoaXMgcmVsYXRlcyB0byBpZGVudGl0eSB3aGVuIHdlYnJ0YyBpcyB1c2VkIHdpdGgg YW4gSWRlbnRpdHlQcm92aWRlciAoSWRQKS4NCj4gDQo+IEkndmUgYmVlbiBicm93c2luZyB0aGUg c3BlY3MsIGFuZCB0byBtZSBpdCBzZWVtcyB0aGF0IHRoZSBvbmx5IHBsYWNlIA0KPiB3aGVyZSB3 ZSBkZXNjcmliZSBob3cgdGhlIFNEUCBpcyBhZmZlY3RlZCBpcyBpbiAtc2VjdXJpdHktYXJjaCBb MV0uDQo+IA0KPiBJcyB0aGlzIHJpZ2h0PyBBbmQgaXMgdGhhdCB0aGUgd2F5IGl0IGlzIHN1cHBv c2VkIHRvIGJlPw0KPiANCj4gKEFza2luZyBzaW5jZSBpbiBhIGRpc2N1c3Npb24gaW4gVzNDIFdl YlJUQyBbMl0gDQo+IGRyYWZ0LWlldGYtc3Rpci1yZmM0NDc0YmlzIGlzIG1lbnRpb25lZDsgaXMg dGhhdCBvdXQgb2Ygc2NvcGUgb3IgaW4gc2NvcGU/KS4NCj4gDQo+IEFsc28sIEkgdGhpbmsgYWRk aW5nIGlkZW50aXR5IHRvIHRoZSBKU0VQIGFuZCBTRFAgKGkuZS4gDQo+IGRyYWZ0LWlldGYtcnRj d2ViLXNkcCkgc3BlY3Mgd291bGQgYmUgYSBnb29kIHRoaW5nLg0KPiANCj4gU3RlZmFuDQo+IA0K PiANCj4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1z ZWN1cml0eS1hcmNoLTEyDQo+IFsyXSBodHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9p c3N1ZXMvOTY0DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K From nobody Thu Feb 2 19:43:14 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B9E127071; Thu, 2 Feb 2017 19:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0de8FMsJiEBJ; Thu, 2 Feb 2017 19:43:12 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9F7126BF7; Thu, 2 Feb 2017 19:43:12 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id y143so596420pfb.1; Thu, 02 Feb 2017 19:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UCIt8LBLa2yaD9zrT15p3PRa9qLLuSz9jb8i1T7jdSg=; b=FNYIWBc/BQgoFMsuZd6XVQxBqafWz0I74bGpbeQX9CqfwZvC+51ClKsWAiOWoVolUn IKWAQAH97xlddFHCM0Jwotj2xkG4GqYtTtckEHDnHteK4L98z0p39qYsyAIau6XRmeCQ H/wy3oT3GWuLPJCUzrmSxiM5rkUaQ9Q1FHXua3QQp3YdOSX6br8chnVEikFonofYV3Z6 UZuhW05pANERpC5g6D55qzwKZvtWA+9iS6WGzPaVvPV05tuXoWj0PygcSu9vPb1gyXFQ gyDAe9Zuomnm5eCq52luPDMh1att+YeDIwSiUWpnjDsSh6lRWl3/6LzDDWCWKw3kWON/ FY+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UCIt8LBLa2yaD9zrT15p3PRa9qLLuSz9jb8i1T7jdSg=; b=HZrUwI4wuARCwjeSd+jCtxV8Z1uJsLHooaVyLVTNFgaFAAngK2FMtcnmZRryub9bJg MDcJdcxAObfhUpfjzx6sWTKPw/YhfK5gQbyBnvqMjgGIaOhRZtWqlv/RDQuAtjedr76Q 1BNe0r6qrTqwyaP13ZovQ6L10u89t7JTifxgdAreHuzJlJuV39ZxnTXKKZm4XmDDNOPW r6JGhLa+DqfscsLEehyM8PMtJvpMQMzDzC9eap9OJZ/SqOH8NRJP4ndPCKPsUHLcGqfW K2/tQ4eb1A9iRylt3qPGMWbdS/gJjcsNgH0IOi65ispSyvb/JP1wbW/9GaNhbEq46zFS x1nA== X-Gm-Message-State: AIkVDXJpUD51rM7MuzCJnl71ZQP3MltRKXEr5H6Bk999Y4EzoW3xvzTnPFRF5uz2As0RDQ== X-Received: by 10.98.212.23 with SMTP id a23mr15423316pfh.18.1486093391775; Thu, 02 Feb 2017 19:43:11 -0800 (PST) Received: from [10.69.52.226] (mobile-166-176-184-127.mycingular.net. [166.176.184.127]) by smtp.gmail.com with ESMTPSA id r8sm62142358pfi.82.2017.02.02.19.43.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 19:43:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14D27) In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Date: Thu, 2 Feb 2017 19:43:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <61E68192-A460-4F6D-BC31-28C459D63756@gmail.com> References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> To: Cullen Jennings Archived-At: Cc: Jonathan Lennox , "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 03:43:13 -0000 Assuming the collision is detected and B sends a BYE then once the SSRC latc= h is removed then A's packets will match on PT, a new SSRC latch is put in p= lace and everything works. > On Feb 2, 2017, at 2:19 PM, Cullen Jennings wrote: >=20 >=20 >> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox wrote:= >>=20 >> In general, this looks good. >>=20 >> I have one question, however. What should happen if an RTP packet (witho= ut a MID) is received for a stream that has an existing mapping to an m=3D l= ine, but whose PT is not valid for that m=3D line? >>=20 >> Should it >> 1. Cause the stream=E2=80=99s mapping to be moved to another m=3D line, i= f the received PT is in the payload type table for some other m=3D line? >> or=20 >> 2. Be an error? >=20 >=20 > Imagine a case where we have two sends call A and B and they each use one P= T that is unique and go to different m lines on receiver C via a SFU. Initi= ally C get a packet from B with a given SSRC and the PT and creates a mappin= g for it. But imagine that A and B had an SSRC collision which they sort tha= t 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 b= ecause the PT points at the m-line A is using but the old SSRC incorrectly p= oints at the m-line B is using.=20 >=20 > To put this a different way, if the packet has a mid, I think it is very c= lear the mid has to override the PT. Same for the PT. The mid is effectively= just an extended PT.=20 >=20 > 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, i= mplement, and understand works is simply a priority order where roughly=20 >=20 > 1) if you have mid, use that and latch the SSRC > 2) if you have a unique pt, use that and latch the SSRC=20 > 3) if you have a latched SSRC use that=20 >=20 > If you had signaled SSRC, guess I would insert that as step 1.5 of use tha= t=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 3 00:46:57 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFDA129614 for ; Fri, 3 Feb 2017 00:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OcewAFJKsQ9v for ; Fri, 3 Feb 2017 00:46:54 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E84129503 for ; Fri, 3 Feb 2017 00:46:53 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id b65so17556825wmf.0 for ; Fri, 03 Feb 2017 00:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=YHGAaMc+77CYi4Bd6T76aLsZWPFXxO7Z/zMLgmCreAQ=; b=Ti4CdCrw7JoUJml+P1rpPyrSXjGVlbZxRUsdoYPQAGrFnHsH6Tt0NY4Jc9Hx3In6xv RWKKukOYQy0oix3Fz1yVyB8i1HVKcfQImIiWa+DMGuHKoyYcJmjBWQ5advbkA6pA6V+S 01idGxZ47PzePdvU25iTcI0rRWVzPwovntBH8HGcJgvLpalNtJ145iHO9LFu7qMNLjHn aF9Q1WkinI814SfbF543Lbwc++L7NkAcr+iywgWhyF2rtE/evzjdCxUa6X+isHXediT2 3h5uHyfut0zNeX3wMHyIsD4yne5OJI4ZdPVNSlOajuFyZ+wzT0BCPOIZZvBMpc9DkXov QygA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YHGAaMc+77CYi4Bd6T76aLsZWPFXxO7Z/zMLgmCreAQ=; b=SDTFyYieGskk8tUmJ3k0hXkzSEZYv8zmtjWUbvresXpaOJFbrLBJaqFTPAVzWYXKPG YQh5CaEjQPSbSPU3ZjFwidub31GVTOZs0o9uj/XsNyfFjux2aNLm3B47XNzw5iYNa8wy NTqBIpzy2kQokBvUibmPhN8RuPIutwOmD+Bhk7Jf6w6lyfuV6Y3WeH/8RfjUhRKN62cp QaQX5zZnFNBFfc7Uz27z3IFxbnO1nSLaT4gFEqcs1IoTvLwtCHXNa5JWCFJWz/p6cjv4 jUYC6kg0kVGSYD1/2GPQ1c4ZKsNWANZkCpOwdFLdOv+PJfHkT0OUVRonhDombvrGUb2A /xUg== X-Gm-Message-State: AMke39lKRYYOIUTnZRfipfNvsFgypjKbWZ2HodM99nwtISTf6iBpsxcF177zXX57RHA72A== X-Received: by 10.28.18.134 with SMTP id 128mr315824wms.53.1486111612198; Fri, 03 Feb 2017 00:46:52 -0800 (PST) Received: from [192.168.1.37] (112.red-83-36-98.dynamicip.rima-tde.net. [83.36.98.112]) by smtp.googlemail.com with ESMTPSA id o70sm43923083wrc.20.2017.02.03.00.46.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 00:46:50 -0800 (PST) To: rtcweb@ietf.org References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> From: Sergio Garcia Murillo Message-ID: Date: Fri, 3 Feb 2017 09:46:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 08:46:55 -0000 On 02/02/2017 23:19, Cullen Jennings 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 nobody Fri Feb 3 02:42:24 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6012951F for ; Fri, 3 Feb 2017 02:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FbwmNFjW-ySR for ; Fri, 3 Feb 2017 02:42:20 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FB1127078 for ; Fri, 3 Feb 2017 02:42:20 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l19so8767526ywc.2 for ; Fri, 03 Feb 2017 02:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=woz3FMcu4/4kMW/9wrsSARUa+C4lzCFnOlqxaLK+98U=; b=nvRIxXTHVyJPAN1ks86nAcO2HedLBXe27j/QoDlXBTQjTpvaPMDxiG7IHmLLYN9vMr yje9B1GQHP9XsilDnx0zMy2/0+ER7DhzoWRgDKD5WbeytDeRPRt8fv/oapm8ViCBhC2P hnOoyj/lS+krEYqr3/gXykw/0NbIoG43SviUnbVO9lrkJIsV9RPWZP3Nn7X8lJCX2knm 5Oco6pzclYi/Zwe43DorwD1tIw0TVF3xdie2EndQPdswNMSmUynjyEjr7wkthil/5F2K DXMLYNnTayEIDjR1IUoVmJUYLjrSOIpEWQDUlV8Wsjo5KfFj4k6ckC7jX04BqsGr3FNx OR1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=woz3FMcu4/4kMW/9wrsSARUa+C4lzCFnOlqxaLK+98U=; b=mPUcxd54Inu5OgX561ez3zxkVesZ54cnPLy/Az1Xr7D4HjX8EMa3x0t/4/omu59UvO GaLsO1W0YguhtWGd4IE71z0nthUVyeIkPaa8Uhr/pgrHfgPJanvqRevcyAa68iYCc4uL /n56IIg/HDPwTBZjJ9qT5fsAsXgn4ejJEkqg+H0vII5s1Qzezyb6anLygDZbkJ1p79wX KaIITGqvM4jD3dMvQP0WA33J6JtFBOGXN9z4LWH98YX6P2r5iGm9W3wINAJ1qtLm7sQT 0ceKSHa9BIPmPh6NuBI/YHpiCNDfMHq2/NA/3JDe6UCMtLvDuHioDyLnTlAEz/nhWQfJ X4zw== X-Gm-Message-State: AIkVDXKX1kVOJS7iuZ8qQtkJwnSNDYMrMZacOWLGZnWMmLK4JHDwSCii3nBPmWWJnvSWXOLqp+JN0LEzmIxR9Q== X-Received: by 10.13.225.85 with SMTP id k82mr8958019ywe.178.1486118539919; Fri, 03 Feb 2017 02:42:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.202.16 with HTTP; Fri, 3 Feb 2017 02:42:19 -0800 (PST) In-Reply-To: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> From: Kevin Dempsey Date: Fri, 3 Feb 2017 10:42:19 +0000 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=94eb2c07664caaa47e05479deffc Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:42:22 -0000 --94eb2c07664caaa47e05479deffc Content-Type: text/plain; charset=UTF-8 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 < sergio.garcia.murillo@gmail.com> wrote: > On 02/02/2017 23:19, Cullen Jennings 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c07664caaa47e05479deffc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I always thought of the MID as a port extension, since wit= hout bundle the port would identify the m=3D line. It that case would the p= riority be:
1) MID
2) latched SSRC
3) signalled SSR= C
4) unique PT

On 3 February 2017 at 08:46, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 02/02/2017 23:19, Cullen Jenni= ngs wrote:

Imagine a case where we have two sends call A and B and they each use one P= T that is unique and go to different m lines on receiver C via a SFU.=C2=A0= 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 d= on'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 SSR= C 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


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c07664caaa47e05479deffc-- From nobody Fri Feb 3 02:42:46 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10431127078; Fri, 3 Feb 2017 02:42:42 -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 isngXanBEGuT; Fri, 3 Feb 2017 02:42:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 89556129BDA; Fri, 3 Feb 2017 02:42:38 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-82-58945e9cd894 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id E1.14.32317.C9E54985; Fri, 3 Feb 2017 11:42:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Fri, 3 Feb 2017 11:42:30 +0100 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5jrr91gBvrE2+PKFOpdD0GaFXKnMA Date: Fri, 3 Feb 2017 10:42:30 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <986C7FAA008B9D46BA9ED85C3F95178E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7ve6cuCkRBn+n6FhMn/WOzWJ+xzo2 i47JbBZTlz9msVj7r53dgdVjyu+NrB5Llvxk8vhy+TNbAHMUl01Kak5mWWqRvl0CV8af7neM Baf7GCuWHZvA3sA4N7uLkZNDQsBEonndFbYuRi4OIYF1jBKXmy5DOYsYJWa+7mDqYuTgYBOw kOj+pw3SICKQLtH+4BEziM0s0MEkcWmFAogtLFAtcWDWXkaImhqJNauvsELYRhJXe46C2SwC KhJ3p61lA7F5BawlNuz9ywKxawWjxM9N05lAEpwCthIfpr4HG8QoICbx/dQaJohl4hK3nsxn grhaQGLJnvPMELaoxMvH/8AWiAroSSx/voYZ5GYJAUWJ5f1yEK16EjemTmGDsK0ler+/hLpf W2LZwtfMEPcISpyc+YRlAqP4LCTbZiFpn4WkfRaS9llI2hcwsq5iFC1OLS7OTTcy1kstykwu Ls7P08tLLdnECIzLg1t+6+5gXP3a8RCjAAejEg/vhsbJEUKsiWXFlbmHGCU4mJVEeAX9pkQI 8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwJi+nI/398Fa mfsJSjkcaWZcG6z6Pm28OO3nkaex15bVLmYNyZxgl+opfS4nap2M647oUyHRey5ESSZ8aRT5 NrPfJnlvDwv/O63nExSW6mrI7v+78ggP/9FOIfnPC4Pkq59rGlg8czomvtsnQlph7fzf95cL SHzZ2WW88d6mV4bsizmv57A/eKbEUpyRaKjFXFScCAAhOCAjxwIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:42:42 -0000 Hi, >2) both the proposed and current text seem lacking in dealing with >multiple bundle groups 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 > >> On Jan 30, 2017, at 6:18 AM, Magnus Westerlund >> wrote: >>=20 >> Hi, >>=20 >> I have now generated a pull request for this text, with some very minor >>changes. >>=20 >> https://github.com/rtcweb-wg/jsep/pull/538 >>=20 >> Cheers >>=20 >> Magnus >>=20 >> Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund: >>> MMUSIC and RTCWEB, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> X. Associating RTP/RTCP With Correct SDP Media Description >>>=20 >>> 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. >>>=20 >>> 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=3D" >>> line, as the "m=3D" line and SDP attributes associated with the "m=3D= " >>> line contain information needed to process the packets. >>>=20 >>> 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=3D" line. In addition, multiple RTP streams might be >>> associated with the same "m=3D" line. >>>=20 >>> 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= =3D" >>> line. However, there are cases where each "m=3D" line has unique >>> payload type values, and then the payload type could serve as >>> indicator to the relevant "m=3D" line the RTP stream is associated >>> with. >>>=20 >>> 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 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>2] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> 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=3D" 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. >>>=20 >>> In order for an offerer and answerer to always be able to associate >>> an RTP stream with the correct "m=3D" 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=3D" line in the RTP Streams and in RTCP SDES packets part of a >>> BUNDLE group. >>>=20 >>> 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=3D" 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. >>>=20 >>> To prepare for demultiplexing RTP streams to the correct "m=3D" line, >>> the following steps MUST be followed for each BUNDLE group based on >>> the SDP signalling information. >>>=20 >>> Construct a table mapping MID to "m=3D" line for each "m=3D" line = in >>> this BUNDLE group. Note that an "m=3D" line may only have one MID= . >>>=20 >>> Construct a table mapping incoming RTP streams (SSRCs) to their >>> "m=3D" line for each "m=3D" line in this BUNDLE group and for each= RTP >>> stream explicitly signalled for receiving in that "m=3D" line. >>>=20 >>> Construct a table mapping payload types to "m=3D" line for each "m= =3D" >>> line in the BUNDLE group and for each payload type configured for >>> receiving in that "m=3D" line. If any payload type is configured >>> for receiving in more than one "m=3D" line in the BUNDLE group, do >>> not it include it in the table. >>>=20 >>> 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. >>>=20 >>> As "m=3D" lines are added or removed from the BUNDLE groups, or their >>> configurations are changed, the tables above MUST also be updated. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>3] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> 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=3D" line within the BUNDLE group. Somewhere i= n >>> 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: >>>=20 >>> 1. Reception of an RTP packet for an RTP stream that has an existing >>> mapping in the RTP stream to m=3D line table. Before proceeding = in >>> delivering the packet to the higher layer context according to >>> the RTP stream to "m=3D" line mapping table the following checks >>> MUST be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is not in the table mapping MID to "m=3D" line, th= en >>> do not deliver the RTP packet to higher layers. >>>=20 >>> B. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, and th= e >>> value indicates a different "m=3D" line than the current RTP >>> stream to "m=3D" line mapping table, then update the RTP stre= am >>> to "m=3D" line mapping. >>>=20 >>> 2. Reception of an RTP packet for an RTP stream that has no existing >>> mapping to an m=3D line. In this case the following actions MUST >>> be performed: >>>=20 >>> A. If the packet carries an RTP header extension with a SDES MID >>> value that is in the table mapping MID to "m=3D" line, then >>> create an entry in the RTP stream to "m=3D" line mapping tabl= e >>> for this RTP stream (SSRC). Then deliver the RTP packet to >>> the "m=3D" line context of the created mapping and stop. >>>=20 >>> 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=3D" >>> line mapping table for this RTP stream (SSRC). Then deliver >>> the RTP packet to the "m=3D" line context of the created >>> mapping and stop. >>>=20 >>> C. Otherwise do not deliver the RTP packet to higher layers. >>> Note, this includes unknown MID values. >>>=20 >>> 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=3D" line mapping table. >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>4] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> 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=3D" line mapping table. Thus each of the SDE= S >>> MID items are processed and the current table entries are checked if >>> the corresponding MID value matches the current RTP stream to "m=3D" >>> line mapping, else the entry is updated. If there is no RTP stream >>> to "m=3D" 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. >>>=20 >>> 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: >>>=20 >>> 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=3D" line the RTP Stream to >>> "m=3D" line table identifies. The source SSRC as identifier of th= e >>> endpoint that the report originates are relevant for interpreting >>> the information, but not necessarily for routing. Example of this >>> is pattern are: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>5] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> 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: >>>=20 >>> Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >>>=20 >>> Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >>>=20 >>> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSF= B, >>> FMT=3D3). >>>=20 >>> Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >>>=20 >>> 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: >>>=20 >>> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>>=20 >>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, >>> FMT=3D5). >>>=20 >>> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >>> defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation= in >>> response to a TSTR this endpoint sent using the SSRC the FCI >>> identifies as source. >>>=20 >>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, >>> FMT=3D7). >>>=20 >>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, >>> FMT=3DTBD). >>>=20 >>> 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=3D" line for the incoming RTP stream as >>> identified by the current RTP stream to "m=3D" line table. For th= is >>> 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: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Name Expires July 31, 2017 [Page >>>6] >>>=20 >>> Internet-Draft Abbreviated-Title January >>>2017 >>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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=3D" lines, thus deliver a copy of the packet to each "m=3D" lin= e or >>> an APP specific handler. >>>=20 >>=20 >>=20 >> --=20 >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Feb 3 03:25:07 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9DC129C11 for ; Fri, 3 Feb 2017 03:25:06 -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 WN5eFA3UQoDN for ; Fri, 3 Feb 2017 03:25:04 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 DEA26129C0E for ; Fri, 3 Feb 2017 03:25:03 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-cd-5894688d6688 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 23.F2.16488.D8864985; Fri, 3 Feb 2017 12:25:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Fri, 3 Feb 2017 12:25:01 +0100 From: Christer Holmberg To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ7jrr91gBvrE2+PKFOpdD0GaFW6BgAgABOOwA= Date: Fri, 3 Feb 2017 11:25:00 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1821593BDBCE1C4CA06D3A665FF7E9A0@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7gW5fxpQIg78yFmv/tbNbPP23ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgytjxYA9LwRmeiu2X57E1MHZydTFyckgImEhM mTuBvYuRi0NIYB2jxOS7F6GcRYwSy3YuZ+li5OBgE7CQ6P6nDdIgIpAksfvcXVYQW1igWuLA rL2MEPEaiTWrr7CClIsIWEkcX2cJEmYRUJGYvvYpM0iYV8Ba4lyfCcT0q4wSjVOOsIDUcArY SjzecY0JxGYUEJP4fmoNmM0sIC5x68l8Jog7BSSW7DnPDGGLSrx8/A/sBFEBPYnlz9eAzZcQ UJKYtjUNotVA4v25+cwQtrXE3j2P2CBsbYllC1+DxXkFBCVOznzCMoFRbBaSbbOQtM9C0j4L SfssJO0LGFlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG1MEtv612MB587niIUYCDUYmH d0Pj5Agh1sSy4srcQ4wSHMxKIrzPEqZECPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEgg PbEkNTs1tSC1CCbLxMEp1cAYKXmVqWLfEtNdmavTVB2LX1y+EM26Wtcu9tvhWQt0WwJ6vwoz 3JKfeiCX8/b3p0LeypU3VhZf6NwVP6/4js8zh+77Z0R08tZvv7p29521JvFHGS68Zp34RYff o+rT/t7c61mSz3ojb2x8+q9mv1TTybWat1YassdYHA+M3zBxjteFdbMMhBeLK7EUZyQaajEX FScCAFWgu8+kAgAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 11:25:06 -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=B9s an error). As Sergio said, the SFU needs to handle it. =8Auntil 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" wrote: >On 02/02/2017 23:19, Cullen Jennings 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 > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 3 05:55:29 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A03129CE6; Fri, 3 Feb 2017 05:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TPT8AcEzFts0; Fri, 3 Feb 2017 05:55:21 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F2B1279EB; Fri, 3 Feb 2017 05:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3638; q=dns/txt; s=iport; t=1486130121; x=1487339721; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hWkfEQSmKlzbpUYZyXQa7pxHMaqz38mfe1CSD+b9rgc=; b=LKNE3ewAInegHAuO27f21tKsVS1fU/7AB5mGQM+eq/P5XCsxT9iWsT5X gZDpvjsgS/aIODwVtZnwVJJhQJeN+eDOwH7537FBRuigJn44J5qS5v9td mbCrjKCjOybBP4Vor6RvB7WncSYv9L0gMn5RefMt90ybFvTU6JT6x9Fvp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQBADgipRY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhKl+DWIoIkgqIEo0pgg0fC4UuSgKCWz8YAQIBAQEBAQEBYii?= =?us-ascii?q?EaQEBAQQBASEVLwcLEAsRAwECAQICJgICIQYoAwUGAQwGAgEBEIlFAwgNDq1Og?= =?us-ascii?q?iWHNw2DcQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQIIFCIJiglGFAoJAHwW?= =?us-ascii?q?QOIpzOIZohwmEF4F7hReDKoZGiCiCBYhdHziBLh0VO4REHYF/IjWJIAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,328,1477958400"; d="scan'208";a="193803121" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2017 13:55:20 +0000 Received: from [10.98.149.206] (bxb-fandreas-88113.cisco.com [10.98.149.206]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v13DtJLV008427; Fri, 3 Feb 2017 13:55:19 GMT To: Victor Pascual Avila , Bernard Aboba References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Flemming Andreasen Message-ID: Date: Fri, 3 Feb 2017 08:55:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 13:55:23 -0000 Based on the feedback received, it seems fine to make this change. Thanks -- Flemming (as MMUSIC co-chair) On 1/30/17 8:28 AM, Victor Pascual Avila wrote: > fine with me > > On Fri, Jan 27, 2017 at 7:20 PM, Bernard Aboba wrote: >> I am in favor of the change. >> >> On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen >> wrote: >>> Hi Harald >>> >>> Since the document is not yet in Auth48 and the change is relatively >>> minor, it is possible to update it during Auth48. >>> >>> However, from an MMUSIC chair point of view, I would like to get positive >>> confirmation from some of the stakeholders that this change is indeed >>> desired. Similarly, if anybody has any concerns with the suggested change, >>> please send an e-mail to that effect. >>> >>> Thanks >>> >>> -- Flemming (as MMUSIC co-chair) >>> >>> >>> >>> On 1/23/17 10:18 AM, Harald Alvestrand wrote: >>>> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>>>> Ted pointed out to me that I sent this to the wrong group. >>>>> >>>>> Chairs and members, please advise. >>>> My proposed change is here: >>>> >>>> https://github.com/alvestrand/rtcweb-msid/pull/16 >>>> >>>> The filed issue is here: >>>> >>>> https://github.com/alvestrand/rtcweb-msid/issues/15 >>>> >>>> (CCing RTCWEB - please keep discussion, if any, on mmusic) >>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: [rtcweb] Modifying an approved document: MSID >>>>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>>>> From: Harald Alvestrand >>>>> To: rtcweb@ietf.org >>>>> >>>>> >>>>> >>>>> When reviewing the implications of the PeerConnection API change to >>>>> support AddTrack rather than AddStream, I found an issue. >>>>> >>>>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>>>> REF-WAIT state (I believe). >>>>> >>>>> The issue is that it is possible to add a track without specifying a >>>>> stream. Since the track's ID needs to be carried, we have to send an >>>>> "a=msid" line, but the track's ID is the *second* field on that line, >>>>> with the first being the stream's ID. >>>>> >>>>> This creates a problem. >>>>> >>>>> Suggested fix: Insert two lines in the document: >>>>> >>>>> 1) On SDP generation: >>>>> >>>>> "If there is no stream associated with the track, use the reserved ID >>>>> value '-'" >>>>> >>>>> 2) On SDP parsing >>>>> >>>>> "If the stream ID is the reserved value '-', the track is not associated >>>>> with a stream, and no stream is signalled or created." >>>>> >>>>> If this is OK with the community, I'll issue an updated draft with this >>>>> change. >>>>> >>>>> >>>>> -- >>>>> Surveillance is pervasive. Go Dark. >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> . >>>> >>> _______________________________________________ >>> 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 >> > > From nobody Tue Feb 7 05:19:46 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C73129426; Tue, 7 Feb 2017 05:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 0PudR1CgJIaF; Tue, 7 Feb 2017 05:19:43 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA02129BC9; Tue, 7 Feb 2017 05:19:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DF9717C54A9; Tue, 7 Feb 2017 14:19:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wab-TBhn8S4Q; Tue, 7 Feb 2017 14:19:39 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5F1137C5427; Tue, 7 Feb 2017 14:19:39 +0100 (CET) To: Flemming Andreasen , Victor Pascual Avila , Bernard Aboba References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Harald Alvestrand Message-ID: Date: Tue, 7 Feb 2017 14:19:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:19:45 -0000 Den 03. feb. 2017 14:55, skrev Flemming Andreasen: > Based on the feedback received, it seems fine to make this change. Thank you; I've submitted -16 with this change. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > On 1/30/17 8:28 AM, Victor Pascual Avila wrote: >> fine with me >> >> On Fri, Jan 27, 2017 at 7:20 PM, Bernard Aboba >> wrote: >>> I am in favor of the change. >>> >>> On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen >>> wrote: >>>> Hi Harald >>>> >>>> Since the document is not yet in Auth48 and the change is relatively >>>> minor, it is possible to update it during Auth48. >>>> >>>> However, from an MMUSIC chair point of view, I would like to get >>>> positive >>>> confirmation from some of the stakeholders that this change is indeed >>>> desired. Similarly, if anybody has any concerns with the suggested >>>> change, >>>> please send an e-mail to that effect. >>>> >>>> Thanks >>>> >>>> -- Flemming (as MMUSIC co-chair) >>>> >>>> >>>> >>>> On 1/23/17 10:18 AM, Harald Alvestrand wrote: >>>>> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>>>>> Ted pointed out to me that I sent this to the wrong group. >>>>>> >>>>>> Chairs and members, please advise. >>>>> My proposed change is here: >>>>> >>>>> https://github.com/alvestrand/rtcweb-msid/pull/16 >>>>> >>>>> The filed issue is here: >>>>> >>>>> https://github.com/alvestrand/rtcweb-msid/issues/15 >>>>> >>>>> (CCing RTCWEB - please keep discussion, if any, on mmusic) >>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: [rtcweb] Modifying an approved document: MSID >>>>>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>>>>> From: Harald Alvestrand >>>>>> To: rtcweb@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> When reviewing the implications of the PeerConnection API change to >>>>>> support AddTrack rather than AddStream, I found an issue. >>>>>> >>>>>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>>>>> REF-WAIT state (I believe). >>>>>> >>>>>> The issue is that it is possible to add a track without specifying a >>>>>> stream. Since the track's ID needs to be carried, we have to send an >>>>>> "a=msid" line, but the track's ID is the *second* field on that line, >>>>>> with the first being the stream's ID. >>>>>> >>>>>> This creates a problem. >>>>>> >>>>>> Suggested fix: Insert two lines in the document: >>>>>> >>>>>> 1) On SDP generation: >>>>>> >>>>>> "If there is no stream associated with the track, use the reserved ID >>>>>> value '-'" >>>>>> >>>>>> 2) On SDP parsing >>>>>> >>>>>> "If the stream ID is the reserved value '-', the track is not >>>>>> associated >>>>>> with a stream, and no stream is signalled or created." >>>>>> >>>>>> If this is OK with the community, I'll issue an updated draft with >>>>>> this >>>>>> change. >>>>>> >>>>>> >>>>>> -- >>>>>> Surveillance is pervasive. Go Dark. >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> . >>>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > From nobody Wed Feb 8 07:20:02 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D5129BC8; Wed, 8 Feb 2017 07:19:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148656719516.3771.16523737882765261992.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2017 07:19:55 -0800 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:19:55 -0000 An update to a meeting session request has just been submitted by Alissa Cooper, a ART Area Director. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Alissa Cooper Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 70 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc quic Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen dane opsawg People who must be present: Eric Rescorla Sean Turner Cullen Jennings Martin Thomson Alissa Cooper Ted Hardie Justin Uberti Harald Alvestrand Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Feb 8 10:05:12 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7490129D0D; Wed, 8 Feb 2017 10:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 hw1D1wOBlIwY; Wed, 8 Feb 2017 10:05:09 -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 538DF129D13; Wed, 8 Feb 2017 10:05:05 -0800 (PST) X-AuditID: c1b4fb30-f7ac898000007389-61-589b5dcf9a40 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 84.68.29577.FCD5B985; Wed, 8 Feb 2017 19:05:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 19:04:57 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" , "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 Thread-Index: AQHSgh7nDawjvle/D0q6jviCIPW5gaFfZtcw Date: Wed, 8 Feb 2017 18:04:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFF21B3@ESESSMB209.ericsson.se> References: <148656719516.3771.16523737882765261992.idtracker@ietfa.amsl.com> In-Reply-To: <148656719516.3771.16523737882765261992.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM2K7me752NkRBg+mKVr0vL3BYrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyDv+eyFRwibdi0tSZTA2M/dxdjJwcEgImEienfmDp YuTiEBJYxyjRveAXO4SziFHi/6TTjF2MHBxsAhYS3f+0QRpEBGIkmh9PYQexhQUCJH79eMkO EQ+U2P/jJBuEbSTRenURmM0ioCKxctdrRhCbV8BXonfTc7C4EJC9ZvpbMJtTwE9iyYtXYHMY BcQkvp9awwRiMwuIS9x6Mp8J4lABiSV7zjND2KISLx//Y4WwlSTWHt7OAlGvI7Fg9yc2CFtb YtnC18wQewUlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiBUXBwy2+DHYwvnzseYhTgYFTi4d3QOStCiDWxrLgy9xCjBAezkgivVuTsCCHelMTK qtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4pRoYa93/Xa5s+bytI+r6 o0fW+y9cvS7GuoV5423RKbmL+37ND7eV32H98/tX/78zzH+eavd9Ur/g17VFn3sjH8hwfJz+ Pnn9g5iU/7qWl/NVHvTz7LPVreDttegOVd/eyBRYd2jpGf6vzT5tnEYCD49GndnLvuhynO8x xp8RmxNELjIo7A/24P02W4mlOCPRUIu5qDgRAL8W06l+AgAA Archived-At: Subject: Re: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:05:11 -0000 Hi, I wonder whether people would be interested/available to have an off-line d= iscussion about the RTP mapping issue (unless we managed to agree on text b= efore Chicago, that is). E.g., on Sunday? I think it would be a waste of time trying to solve the issue behind the mi= crophone during the meeting... Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of "IETF Meeting Se= ssion Request Tool" Sent: 08 February 2017 17:20 To: session-request@ietf.org Cc: rtcweb@ietf.org; rtcweb-chairs@ietf.org Subject: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 An update to a meeting session request has just been submitted by Alissa Co= oper, a ART Area Director. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Appl= ications and Real-Time Area Session Requester: Alissa Cooper Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 70 Conflicts to Avoid:=20 First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir ac= me mmusic payload sipcore perc quic Second Priority: dprive tcpinc straw t= svwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen dane o= psawg People who must be present: Eric Rescorla Sean Turner Cullen Jennings Martin Thomson Alissa Cooper Ted Hardie Justin Uberti Harald Alvestrand Resources Requested: =20 Special Requests: =20 --------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Feb 8 10:07:16 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A23F129580; Wed, 8 Feb 2017 10:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 n_bauGq3DLd0; Wed, 8 Feb 2017 10:07:13 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9DD1212956C; Wed, 8 Feb 2017 10:07:12 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-b0-589b5e4e9bdf Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id CC.46.24099.E4E5B985; Wed, 8 Feb 2017 19:07:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 19:06:26 +0100 From: Christer Holmberg To: Christer Holmberg , "rtcweb@ietf.org" , "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 Thread-Index: AQHSgjXmXUmgemiVbkOyB6u3uQWqOKFfZ4uA Date: Wed, 8 Feb 2017 18:06:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFF2204@ESESSMB209.ericsson.se> References: <148656719516.3771.16523737882765261992.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFF21B3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFF21B3@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5f3OwIgwsLjS163t5gsVj7r53d gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ1yfcYC94JFjxqGE2WwPjKb4uRk4OCQETidauVjYQ W0hgPaPEiUm5XYxcQPYiRoldR96wdDFycLAJWEh0/9MGiYsITGCUeLLkPQtIg7BAgETb2tNg tohAoMSW4/1QtpHEv7mzWEFsFgEViQ9N15hAbF4BX4k1C3vZIBZMZJS4ueIdWBGngJ/Eq03f wZoZBcQkvp9aA9bALCAucevJfCaISwUkluw5zwxhi0q8fPyPFcJWklh7eDsLRL2OxILdn9gg bG2JZQtfM0MsFpQ4OfMJywRGkVlIxs5C0jILScssJC0LGFlWMYoWpxYX56YbGemlFmUmFxfn 5+nlpZZsYgTGwcEtv612MB587niIUYCDUYmHd0PnrAgh1sSy4srcQ4wSHMxKIrxakbMjhHhT EiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamBUXThtrsjMmCs3 VB7Gfs6+6nHq09P7pmtmLlx9YUqkltq1wGA7I2/hY6Ly9lxd7ZE7t9iEGyQlTeF+8NLpxBK+ vleX5RiTZ6R4+OkuEyyo83Jg+HtMJPjQ+a/bPLuKzBhS2/oEPW6G5//8Y9iivfz1uden5x5U 0XLfovpUpkj/v2mV7mR/xQYlluKMREMt5qLiRACtDhj9fwIAAA== Archived-At: Subject: Re: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:07:14 -0000 Also, having a phone meeting to discuss the issue before Chicago would also= be good, I think. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 08 February 2017 20:05 To: rtcweb@ietf.org; rtcweb-chairs@ietf.org Subject: Re: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF= 98 Hi, I wonder whether people would be interested/available to have an off-line d= iscussion about the RTP mapping issue (unless we managed to agree on text b= efore Chicago, that is). E.g., on Sunday? I think it would be a waste of time trying to solve the issue behind the mi= crophone during the meeting... Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of "IETF Meeting Se= ssion Request Tool" Sent: 08 February 2017 17:20 To: session-request@ietf.org Cc: rtcweb@ietf.org; rtcweb-chairs@ietf.org Subject: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 98 An update to a meeting session request has just been submitted by Alissa Co= oper, a ART Area Director. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Appl= ications and Real-Time Area Session Requester: Alissa Cooper Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 70 Conflicts to Avoid:=20 First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir ac= me mmusic payload sipcore perc quic Second Priority: dprive tcpinc straw t= svwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen dane o= psawg People who must be present: Eric Rescorla Sean Turner Cullen Jennings Martin Thomson Alissa Cooper Ted Hardie Justin Uberti Harald Alvestrand Resources Requested: =20 Special Requests: =20 --------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Feb 8 13:13:42 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492D81295D0 for ; Wed, 8 Feb 2017 13:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=unavailable 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 B5hN_oJx6Amv for ; Wed, 8 Feb 2017 13:13:35 -0800 (PST) Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (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 9CC7F1294B7 for ; Wed, 8 Feb 2017 13:13:35 -0800 (PST) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D4DE9251EE; Wed, 8 Feb 2017 16:13:24 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8C2F624F86; Wed, 8 Feb 2017 16:13:24 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.4.137] ([UNAVAILABLE]. [128.107.241.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 08 Feb 2017 16:13:24 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2017 13:13:23 -0800 Message-Id: To: mmusic Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: [rtcweb] normative dependencies in draft-ietf-mmusic-sdp-bundle-negotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:13:41 -0000 Looking at draft-ietf-mmusic-sdp-bundle-negotiation, it seems that it = would be fine to normatively depend on RFC 5245 instead of = ietf-mmusic-ice-sip-sdp. It does not rely on any changes in made from = 4245 to ice-sip-sdp.=20 We don't want JSEP to normatively depend on ietf-mmusic-ice-sip-sdp = since that is not needed. Could you change = draft-ietf-mmusic-sdp-bundle-negotiation to not normatively depend on = ietf-mmusic-ice-sip-sdp? Thanks From nobody Wed Feb 8 13:22:13 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E544127ABE; Wed, 8 Feb 2017 13:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 jD0ZXiIqZE6R; Wed, 8 Feb 2017 13:22:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 5E72612949A; Wed, 8 Feb 2017 13:22:08 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-a6-589b8bfe2d87 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 65.2C.24099.EFB8B985; Wed, 8 Feb 2017 22:22:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 22:22:05 +0100 From: Christer Holmberg To: Cullen Jennings , mmusic Thread-Topic: [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-negotiation Thread-Index: AQHSglA50cSQ9ZWGAEW5AKQpNBZRyqFfngYg Date: Wed, 8 Feb 2017 21:22:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFF2670@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hO6/7tkRBo++qlt8WP+D0WLq8scs Fmv/tbM7MHssWfKTyePy+Y+MAUxRXDYpqTmZZalF+nYJXBlfN85mKzjAXnH+XxdzA+Mati5G Tg4JAROJj9NvgtlCAusYJY7eDIKwFzFKHPjL18XIwcEmYCHR/U8bJCwiYCvRt+sEM4jNLKAo 8WX5fLBWYYEoiSfHfzND1ERLfN4wiw3CNpJo3jCLFcRmEVCReHP3DhvISF4BX4l9l3ghNllK 3H99jxUkzClgJTF7TjxImFFATOL7qTVMEJvEJW49mc8EcbCAxJI955khbFGJl4//sULYShJr D29ngajXkViw+xMbhK0tsWzha7B6XgFBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFq cXFuupGRXmpRZnJxcX6eXl5qySZGYKQc3PLbagfjweeOhxgFOBiVeHg3ZM2OEGJNLCuuzD3E KMHBrCTC69YBFOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNT qoFxU8mxlR9s89bIKW34vK7s8vIviScdteo3RXZvafoeNOnMBbknqgJb9gp+WJybHWqdUlt6 juvEWUbtYq+cHZeVvXRe9Ds3HNz15JDekvtTD3/f0nCHj9frxuetaxJdN1+Y9/qJmqO1T7ik asgbSWZGjZpH4X9XaQoLvJN6qCLWfDR43Qvrqwd5lViKMxINtZiLihMBxNPjW5ACAAA= Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-negotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:22:10 -0000 Hi, Don't you also reference trickle in JSEP? Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 08 February 2017 23:13 To: mmusic Cc: RTCWeb IETF Subject: [MMUSIC] normative dependencies in draft-ietf-mmusic-sdp-bundle-ne= gotiation Looking at draft-ietf-mmusic-sdp-bundle-negotiation, it seems that it would= be fine to normatively depend on RFC 5245 instead of ietf-mmusic-ice-sip-s= dp. It does not rely on any changes in made from 4245 to ice-sip-sdp.=20 We don't want JSEP to normatively depend on ietf-mmusic-ice-sip-sdp since t= hat is not needed. Could you change draft-ietf-mmusic-sdp-bundle-negotiatio= n to not normatively depend on ietf-mmusic-ice-sip-sdp? Thanks _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Feb 10 10:16:45 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C7129A7B for ; Fri, 10 Feb 2017 10:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lorantech1com.onmicrosoft.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 1W96pbV6zEoD for ; Fri, 10 Feb 2017 10:16:42 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::618]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6A5129A6A for ; Fri, 10 Feb 2017 10:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=LORANTECH1COM.onmicrosoft.com; s=selector1-lorantech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GpPIYrlS9ONIQFdd60M8D78Br2UF/opRHWthWAtvCHM=; b=N1LLmStp2xxga8T+lLu9bdQr50MMYlWpXTtw8PljEJVNXxSvVXoZcDVnbp5FeydRQnBRJX7dUHyU1wt+g8SxdSllispk1mC91KiB4P8Atn9gS8OWUysSz/lQb5hct2Ec7IQmJV8kmoAJLdKY5VFvcf/+Es57+NwNZjBVEzjRQAU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rene.levesques@lorantech.com; Received: from LTRlevesques3 (70.83.0.154) by MWHPR1701MB1709.namprd17.prod.outlook.com (10.172.61.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 18:16:17 +0000 From: To: Date: Fri, 10 Feb 2017 13:16:13 -0500 Organization: Lorantech Message-ID: <01ed01d283c9$c5fd1b50$51f751f0$@lorantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKDycK17wBPv2BzS8yJOimFmjFBeA== Content-Language: fr-ca X-Originating-IP: [70.83.0.154] X-ClientProxiedBy: MWHPR18CA0019.namprd18.prod.outlook.com (10.173.238.157) To MWHPR1701MB1709.namprd17.prod.outlook.com (10.172.61.136) X-MS-Office365-Filtering-Correlation-Id: 3b7e2902-16c0-4922-afe9-08d451e0e804 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:MWHPR1701MB1709; X-Microsoft-Exchange-Diagnostics: 1; MWHPR1701MB1709; 3:3zvL4rf/ZgGRwkiOIHbfr4bXuvk5bxEzBe6PzQ5lCXKITtoES6E4OjUYpP/MkbGMjtcjt1d35xcGCJKdg+UI455lJAWHXvq7d/o9e5ugMV61zofNMJhIjc2vax/wcO/1piK21FOFzNkvXx6S2j99avssck6/k9MNvSIKKKWE/Y9e/pt+GPRO2Jt9AekeWmD+Mlokw4WN3wEh+BihGMjVhUt9P10/3RwmTamtd2liaMyJHSGx1uXz7fz68ZmbJeeSh7C6qwA5FVWEL8xhCkAueg==; 25:bLuLskMuRVAHHnCyDIKeiNbYQ6EuEbOLxuwOyI/Sw6nGIkNKL50zqVNxLg0hfEOke77KAPM0hRkcU1wocyyl9o2JBqPNhE0NbCPuOezQJa/Em/tez4++RNN5+UdaQxkldm7kZqw2nfl+gV9O4F5xd0yHbS+vWh5M2p+EqlebhBWrLs/HUl97pu3UntG7lZmdUwmUNNF7TCzDZGJxkrn64ISKGcXHGq3r/72AJmAM0UOenYanG2HDiZSuxwvbzJX+8YRoW80pQu3VrocY9IVBclUCqoMJdUP/MlQyzXqsh1vTPJYE/nQVWz3ezbFnN2lShLdYMIX19Jv91+7IW4HhI+foVkRqoUZvI33dIjF6ITSNNDd3M4PaE23xAo6vYtLNgUraViqp41ziZ/FBqE8CVCY1Z6Qd1lTsSvnXUh4qCRIQ60VvbzUJMhbjrVd66MTsj/tfsjqHhE/NBpyubfDDqw== X-Microsoft-Exchange-Diagnostics: 1; MWHPR1701MB1709; 31:uspQiyEe+pFZAlAluWpUDI/vukvcRtjCf3w6p3pF1HgJFqFVl7xATcOIX6yPCD9NSWXsaqi2ltqrQQIsO6itqQeyjAQmlvq5vainNPH0c0MVGmAMotNmllzjgtzkKzDtvlrujxEKGj+d/5DVLFTp939MF7haBCLrfZkb8XgA7Rpn0y/EFqahedoja7lVNzm0Hx5FmpaM+/WJXzo2ftT70w7WxwBYKN5anJN57MzenipCZwv1ILktz7JUoKhlmKQ9jc7QLiIccJ4zMMJb8S5G2Gt/IfXxGEWrL8LVAnXYTeo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(194151415913766); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(2016111802025)(20161123558025)(6072148)(6043046); SRVR:MWHPR1701MB1709; BCL:0; PCL:0; RULEID:; SRVR:MWHPR1701MB1709; X-Microsoft-Exchange-Diagnostics: 1; MWHPR1701MB1709; 4:mXgAGPqO/y7WA8/yKWq61ZNZ+VhKx7qX20ZJCkYrocAIl8Iy4/AZYFl5PS+zOTOJkyJH6/r2wIJTZER/7Q0DW1LuDPRI15Uoll4T1H6xUE4vTwEE7WMqUOiNOf/JTi1UtWtZsyx+K7UTrevRWPftNGIUXw7WiPMBAY2ydyXuhsVeWpn4FJZ3TR/+xLLY/LoF4Sff6qysNgXqbPytvqZmfvwyXnCwd6Rw4UG5zbuHjN7Z4OmR2JedjDAYNe8fm7dpioMhHD7CVieIEYX9wo/t//MXcGaM2V7RThDmyE8eeDw6K4cHbwk9o5wBkSCKAZkTjBbZenQYzkn5pmTPjBNfGt7Yde5YdWkaSkTCkE5iiyd5CZzsKYlsJcWL1kCnd4MHIN/a0QR8AIVUg3U9jIcePzw9njtwrKwAxUUiJJovVh/Zq5LHiIa6wv/nRL9qNH5xGCQWCr/PNAdIxt1P+CbyFRzoA2h9jTDFVv9A2rECtJkHLUHBB2l2k5gcWs14+TBPUmix5OdBZatq5lumtttE2IGCg2rL6zItb+S1QE7rzYbxokySwNYJHTEOTflop29P3rsyCtkhLoBrSSbTC+pNooPasdQmmgM0wlgIUor3jamcR/J7PoS2YPSiC67N48Dzy5i80og98ErzMwqRidbJGrfQ3A1tGc8fn5TVcgEKbQUGNYgAFAFeXnNOKoSnpZSWlzCV+S+PAp6Kc5oP06bbCQ== X-Forefront-PRVS: 0214EB3F68 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(39830400002)(39450400003)(39410400002)(55784002)(189002)(199003)(450100001)(11990500001)(2876002)(6666003)(6916009)(305945005)(2906002)(7736002)(47776003)(189998001)(66066001)(6496005)(50986999)(97736004)(36756003)(75216001)(86362001)(53936002)(46816001)(5660300001)(101416001)(50226002)(68736007)(86152003)(105586002)(61296003)(42186005)(224303003)(50466002)(92566002)(6306002)(25786008)(106356001)(38730400002)(110136004)(23756003)(81166006)(33646002)(6116002)(2351001)(44736005)(102836003)(8746002)(81156014)(1420700001)(84116002)(6486002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1701MB1709; H:LTRlevesques3; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: lorantech.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; MWHPR1701MB1709; 23:5rr0kyVKAsjzYVW65gkc2hFfyWqCzH48cJbV3?= =?iso-8859-1?Q?G14l2z3cgc9GtW5x1BkHgMyIZbHxHcbXVkTQ2aJ6xv0LysrunTTydhkTKk?= =?iso-8859-1?Q?2wTqy4JkIsnH5lTcPeqsjPJAqb4tnbvMFKduu4M9njyMt8RJMchskk6aM1?= =?iso-8859-1?Q?mgzJiat6adQ1yjpHs/pxdb2cEtq+vrzNBHOpuNMCgd4MW7NzXRRL5uv+D/?= =?iso-8859-1?Q?bWUvX7jefE4SWNiHtFsLn3MVSHgQwfJKE6WkG+4Ng4g0PtOPCJNiI8NDZ0?= =?iso-8859-1?Q?T6GiRz/kieX+nVzGntknufsDTgdNIKOXA8lUR87vpSFm628uRB1evmOYZM?= =?iso-8859-1?Q?HrJm/jVeDJxHyfUT20gC9NVMMDfI+y1rMBrMLq5asrPJWCm8F5IF5Hbp0g?= =?iso-8859-1?Q?MIYrGJQjGlFzAlYB/+Q9CT/hOR+PfrxGn8IkZE2W748jajVx87IaF5SSRF?= =?iso-8859-1?Q?nB5U6MXoat16uU3wnUQ36E2ODgns4KTAn5PNC6hYFyAwdWJX4EqTAFMApo?= =?iso-8859-1?Q?WajE+Ob8gAoNFh4VXYUs1SpJTzfQMM/Y49L8kgZoTZfWtoNe0VkKI1csXr?= =?iso-8859-1?Q?7ClU5A1ooWMU8bsUC+v5DT+2bAjq27o3utSPqaBNwTTPPUK+cEF7Aw0NYN?= =?iso-8859-1?Q?/Puoc7xf+tdMq1/1NIJZK31JqRe3b6/z/DlUwdwL0tlELvvgqKHa/x1/iP?= =?iso-8859-1?Q?TArkBCDHPpFgDFIMW4my2zugXNbRLLbbLbAFu+9Djfsn35m9dm36QAeA9d?= =?iso-8859-1?Q?Q+WauOS4jQ0VY5kxq1rFx4QtxYI60jkRrPgtRYlOWdlSm5Ex9sgXwTOjXt?= =?iso-8859-1?Q?shj/DRB0AtVT8nKpPh1nRze4H4Ut1leMTfE2Ku8keKeVEYzsnk2r1bMOA3?= =?iso-8859-1?Q?bht540DuoM/FqjdmQNMAt64V5O/Gr0QUyIfwf0OYX3/O/7Br12LHR2s3ys?= =?iso-8859-1?Q?7BS/RzvgYI+hmKgl+QAIqpK/EoobFPJy+YnYHicb9t1toc+iidhkx3mkri?= =?iso-8859-1?Q?0vXfChozDhSP/DZdah33p/8g5ctn2fWvK/On1UumyLO3rivlXkWxUW8kvm?= =?iso-8859-1?Q?kOGE/4zWFG64hLTJFFz+633c/XT0tst+GUkOswL7ICiTt51RimCXmGaz5L?= =?iso-8859-1?Q?udK7l4tHnPlvt7GZLG2tsDlF5vDqfwfbXvwUJoYDjMa7b4PrjK7kq+yNtG?= =?iso-8859-1?Q?a+fA0JHbaSOA6HeSJrDd9VM+qX35+dqjMt/0Va+jzc5gqY2/YeVAG2zO/w?= =?iso-8859-1?Q?jLqb1wt9KksNZ0a7m2U4c56wvFWBV5pCJNvdf3nIWb9uKxpOZmdUH0txAG?= =?iso-8859-1?Q?z5h549ODsELLkxURRez2KDjraEQfN8VFEVDix4r6+nt6krHGsR3ke30/sl?= =?iso-8859-1?Q?5ict4je8FrJDGDeU6zILXJdBOTyui3BHGAztJ7fUPLrCBF5NDVEjA=3D?= =?iso-8859-1?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR1701MB1709; 6:BkCH4tzSYOTYeUxDJgsiMrVjn2konc/zWgGEpEISjoZFFuv+0kTKDhE7CD6eYx/ukSOLFG7ZXnmNJ5GuZAzdxpdtfvwzB+3waEHYj1GaJN/XMleuLjbRbNNlUcorjigTCdaa7ZR6N8PaCrVw6iXQV0L5L5fKmru/0/VT9gpg7tx5X/wrFz+dV45FbN1e5WY1SKzQ//YmsNibfVVNkiGrLyJJwaMxCXJIeoRXJvOlxz0DPc46qgZWA0Av5CC4I7r/qUI9/wk4P9EYu8u3IrqfFK6zSHrjjA/mah6zmTQHcG3sACI85BmQyfbJgdRghRoPRvFlBoj1cQlSMKq3pdEmXQ7CMQEfPYc0cXIiz+fNX8muojs/XhQfgC9kntiVL3RP9ANdrrEpbBNiSwubxxFNTg==; 5:1yXbpjbtdjG9YtfAsB8/Y0xYUaDePLyZeqVx4JINxDRUZlhd+D1Tu46wIXRGK1NCmG44IdYjJC5piZ8e80lDdHL92TjgBW+hg/nKB01FqyPr9R5O752FnOrFEXqAaUl+NU7TSQtBtOgecOn7DPqp6Q==; 24:IbsQy8jschWFwentl/sYeCXJmh2bJH0wJRmTqXyFpjbrSIkTVyIfp02SQinSDG9TiyY2QSMNWc7VrJJlFxuFNLXVCqS93S1kC/apjbX4vaw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR1701MB1709; 7:aReV9ZOc1aQbMTdxgfwDxiL1i4evRqDQnDxFDwYvuj8RIuAkOSyAL9375EejYAK2FUw0Q3qDT9h2iANGAPinE4NyAluxT8H+xTF5AJsMoQNKEq82VU+5gZTBMmZDJhW4F5Zn+d5ADpnBF2c57+EcF4CaGPpRHgc3Qgo02rB5tKCMDEW812Q5BzNTNbCKZSE2BhyVeJSk4tsjK8XRiKnTZulS3vd33HsPWSFD/sJE9IOQ9cZCAtoblyr8G2OEPavmplWXjK7J7cnu1tlaN6O5Ecm600wgAd+y5mETVOFJ3rU28/R1bplQYlVeb+M/i6EBZpSfEJgpM99fOH2HjtP5F+5ElDHVv0OtJRuAVMBqVazKN6nc4+e8b5oES9+2yYcEV2T5Gsi2a3k8cVje7sgZ1dsHAlwmC5LHIlauoaSvym6+F/+C5BqTvzr+ppZkkrAQKvbyxD2hxh8zKwJNjNbQZHFLqgk8s7asY9oxGN8qTu42UIJcatxDMTMnmV8+khLM4jmJOc/Ih/EXqqcrIZNtgw== X-OriginatorOrg: lorantech.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2017 18:16:17.0545 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1701MB1709 Archived-At: Subject: [rtcweb] =?iso-8859-1?q?14h00_au_Pavillon_Pouliot_de_l=27Universi?= =?iso-8859-1?q?t=E9_Laval_=28Salle_PLT-3903=29=2E?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:16:44 -0000 14h00 au Pavillon Pouliot de l=92Universit=E9 Laval (Salle PLT-3903). Pascal Cardin : pascal.cardin@cnesst.gouv.qc.ca Mathieu Simard : mathieu.simard@cnesst.gouv.qc.ca Jacques Martin : jacques.martin@cnesst.gouv.qc.ca Louis Gosselin : louis.gosselin@hotmail.com Ren=E9 L=E9vesque : rene.levesques@lorantech.com -----Message d'origine----- De=A0: rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de rtcweb-request@ietf.org Envoy=E9=A0: 9 f=E9vrier 2017 15:00 =C0=A0: rtcweb@ietf.org Objet=A0: rtcweb Digest, Vol 72, Issue 9 Send rtcweb mailing list submissions to rtcweb@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/rtcweb or, via email, send a message with subject or body 'help' to rtcweb-request@ietf.org You can reach the person managing the list at rtcweb-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of rtcweb digest..." From nobody Sat Feb 11 22:16:06 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC12129443; Sat, 11 Feb 2017 22:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 L4JZ72a5AStj; Sat, 11 Feb 2017 22:16:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425F212009C; Sat, 11 Feb 2017 22:16:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGG66588; Sun, 12 Feb 2017 06:15:59 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 12 Feb 2017 06:15:58 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Sun, 12 Feb 2017 14:15:55 +0800 From: Roni Even To: Christer Holmberg , "rtcweb@ietf.org" , "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] Associating RTP/RTCP With Correct SDP Media Description - bundle Thread-Index: AdKE93YjXBD5PRulSiS9KQYIZ7xp6Q== Date: Sun, 12 Feb 2017 06:15:54 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD773513@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.589FFD9F.01CC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d00494ab87353a863299d33532a44e1a Archived-At: Subject: Re: [rtcweb] Associating RTP/RTCP With Correct SDP Media Description - bundle X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 06:16:05 -0000 Changing the subject I am OK with both options and agree that it will not work on the microphone Roni=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: =E9=E5=ED=A0=E3 08 =F4=E1=F8=E5=E0=F8 2017 20:06 > To: Christer Holmberg; rtcweb@ietf.org; rtcweb-chairs@ietf.org > Subject: Re: [rtcweb] rtcweb - Update to a Meeting Session Request for IE= TF > 98 >=20 > Also, having a phone meeting to discuss the issue before Chicago would al= so > be good, I think. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: 08 February 2017 20:05 > To: rtcweb@ietf.org; rtcweb-chairs@ietf.org > Subject: Re: [rtcweb] rtcweb - Update to a Meeting Session Request for IE= TF > 98 >=20 > Hi, >=20 > I wonder whether people would be interested/available to have an off-line > discussion about the RTP mapping issue (unless we managed to agree on > text before Chicago, that is). E.g., on Sunday? >=20 > I think it would be a waste of time trying to solve the issue behind the > microphone during the meeting... >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of "IETF Meeting > Session Request Tool" > Sent: 08 February 2017 17:20 > To: session-request@ietf.org > Cc: rtcweb@ietf.org; rtcweb-chairs@ietf.org > Subject: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 9= 8 >=20 >=20 >=20 > An update to a meeting session request has just been submitted by Alissa > Cooper, a ART Area Director. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Real-Time Communication in WEB-browsers Area > Name: Applications and Real-Time Area Session Requester: Alissa Cooper >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 1 Hour > Number of Attendees: 70 > Conflicts to Avoid: > First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir = acme > mmusic payload sipcore perc quic Second Priority: dprive tcpinc straw ts= vwg > tsvarea ace uta netvc capport Third Priority: insipid irtfopen dane opsa= wg >=20 >=20 > People who must be present: > Eric Rescorla > Sean Turner > Cullen Jennings > Martin Thomson > Alissa Cooper > Ted Hardie > Justin Uberti > Harald Alvestrand >=20 > Resources Requested: >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Feb 14 06:21:01 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675FC129A1E; Tue, 14 Feb 2017 06:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 WjYj0yL-k9yf; Tue, 14 Feb 2017 06:20:58 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2DDBA129502; Tue, 14 Feb 2017 06:20:57 -0800 (PST) X-AuditID: c1b4fb3a-7d7ff70000005e23-0c-58a312468720 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id F4.EA.24099.64213A85; Tue, 14 Feb 2017 15:20:56 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.319.2; Tue, 14 Feb 2017 15:20:54 +0100 From: Magnus Westerlund To: "Cullen Jennings (fluffy)" References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Message-ID: <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> Date: Tue, 14 Feb 2017 15:20:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM2K7uq6H0OIIg5W/uSymz3rHZjG/Yx2b RcdkNoupyx+zWKz9187uwOox5fdGVo8lS34yeXy5/JktgDmKyyYlNSezLLVI3y6BK6Ov5wlz wS71iv3Ny9kbGN/KdTFyckgImEh8/7ubDcQWEljHKPHrglMXIxeQvZxRYtajR0wgCTYBC4mb PxrBioQFqiU2zP4JFhcRMJRo2jOPCaJhBaPEz03TwRLMAh1MEpdWKIDYvAL2Ek9PH2PtYuTg YBFQlWjo8QUJiwrESOztv88EUSIocXLmExYQm1PAVuLD1PeMEGMsJGbOPw9ly0s0b53NDHGo tkRDUwfrBEaBWUjaZyFpmYWkZQEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwOA9uOW3 1Q7Gg88dDzEKcDAq8fB+OLkwQog1say4MvcQowQHs5IIr7Dg4ggh3pTEyqrUovz4otKc1OJD jNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGHWXl6kKrZ+besryzJ2EujS9vRWvr1pa bzY4+P/krjWR9/heanx4HHzcz+7yNVvhf5eCeVT0ss+uS2Re5nvweOSEGTob9V6q5K3/5avJ e+ma3CbXPSn/4mrKNa/M7D78/b95wq5PizumaG1+mdtcOkN6V9nCndv23135q/nKMn+JGVFG K2QPCcsosRRnJBpqMRcVJwIA4Ax+OloCAAA= Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:21:00 -0000 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 > multiple bundle groups 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 > routed - not before. 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: 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. 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- From nobody Tue Feb 14 06:21:18 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E0129A4D; Tue, 14 Feb 2017 06:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 XR0gz6YVSANa; Tue, 14 Feb 2017 06:21:01 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 4A6B71298C1; Tue, 14 Feb 2017 06:21:00 -0800 (PST) X-AuditID: c1b4fb3a-7d7ff70000005e23-21-58a3124b7da0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 38.EA.24099.B4213A85; Tue, 14 Feb 2017 15:21:00 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Tue, 14 Feb 2017 15:20:59 +0100 From: Magnus Westerlund To: Cullen Jennings , Jonathan Lennox References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Message-ID: Date: Tue, 14 Feb 2017 15:20:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM2J7lK6P0OIIg3nGFtNnvWOzmN+xjs3i w/ofjBb7F59ntpi6/DGLxdp/7ewObB5Llvxk8rh8/iOjx5fLn9k82p7dYQ9gieKySUnNySxL LdK3S+DKWDAtvWCWUsXl3/dZGhhvSXUxcnJICJhI3J3wh62LkYtDSGAdo8Tn39eZIJzljBI3 r/9nAqliE7CQuPmjkQ3EFhYokjjwso0ZxBYR8JRYtuUtVPciRon12y4xgzjMAn8ZJToXLmUB qeIVsJf42n2fFcRmEVCVaD70gx3EFhWIkdjbf58JokZQ4uTMJ2D1nAJWEheOzgfbwAy0eeb8 84wQtrxE89bZYHEhAW2JhqYO1gmMArOQtM9C0jILScsCRuZVjKLFqcXFuelGRnqpRZnJxcX5 eXp5qSWbGIFBfXDLb6sdjAefOx5iFOBgVOLh/XByYYQQa2JZcWXuIUYJDmYlEV5hwcURQrwp iZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTBa/blW2iumqHm0 MmzK9uctR/XvneKafuS059XqU//L7obtPP1C1zuOQaDE1tU7clqg8Bshh0evfpgFO1wOeFYj FdK4gTvzdIWDqp4i18Q71hbmIjFT2e1cq0WPv771gn+pz+KP+7+K+7r35If+3q//YtdJi1mP ptkfjVnFedC/LyCTY3dn5HklluKMREMt5qLiRADSufa8ZgIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:21:02 -0000 Hi, Please see below for my feedback on this. Den 2017-02-02 kl. 23:19, skrev Cullen Jennings: > >> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox >> wrote: >> >> 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? >> >> 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 > 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- From nobody Wed Feb 15 05:10:02 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437D1294CD; Wed, 15 Feb 2017 05:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b-FNYM_nhWVd; Wed, 15 Feb 2017 05:10:00 -0800 (PST) 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 C5E16127071; Wed, 15 Feb 2017 05:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7670; q=dns/txt; s=iport; t=1487164199; x=1488373799; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NHv1n8NpTpuTjLxCXOI5pa6vR/FBAq533q+29/kzS34=; b=Ub9bJtOOWUmCcuR8JawxcU3unbtOPI9c4fYyzeAGXMXu157MonY4sJA+ HOYoQq05XgHDFZXvlzoomhxdf7pWSU6K5qafORqniy0KPpuC/DQM+hWcI HZqojxms703UAjmbzWusbwyf4D9sn+N7rcwQuywJzWAKsYa2IA4Q+BrgT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AgAHUqRY/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDDEaKCJFxH5Mngg+CDIYiAhqBcj8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQMBDBcRRQUJAgIBBgIYAgIfBAMCAgIZFxQBEAIEDgWJYwiSEp1OgiWLY?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaHRwiCYoRrgm8ugjEFiQ2SagGJR0e?= =?us-ascii?q?IBYF7jwuILYppAR84PUNRFU4BhDMdGYFIdYh7gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="385802434" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2017 13:09:58 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1FD9v0V009221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 13:09:57 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 08:09:56 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 08:09:56 -0500 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5sVd9K8JGDU+bnDtTRZpMhaFo86YAgAF+fAA= Date: Wed, 15 Feb 2017 13:09:56 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> In-Reply-To: <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <0E7CBD95D90AC6459E638937E116BEC2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 13:10:01 -0000 DQpUbyB0cnkgYW5kIGhlbHAgZ2V0IHlvdSB0ZXh0IG1lcmdlZCBpbiwgSSBzZXBhcmF0ZWQgeW91 ciB0ZXh0IHVwIGludG8gYSBidW5jaCBvZiBQUnMgc28gdGhhdCB0aGUgZGlmZnMgd2VyZSBhbGwg Y2xlYXIgYW5kIGVhY2ggUFIgdHJpZWQgdG8gZGVhbCB3aXRoIG9uZSBpc3N1ZS4gVGhlcmUgYXJl IGFsbCBpbiBnaXRodWIgbm93IGFuZCBjb21tZW50aW5nIG9uIHRoZXNlcyB3b3VsZCBwcm9iYWJs eSBiZSB0aGUgZWFzaWVzIHdheSB0byBnZXQgdG8gc29tZSBjb21iaW5lZCB0ZXh0LiANCg0KDQo+ IE9uIEZlYiAxNCwgMjAxNywgYXQgNzoyMCBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBm b3IgdGhlIGZlZWRiYWNrLiBTb3JyeSBmb3IgbXkgZGVsYXkgaW4gcmVzcG9uZGluZywgYSBjb2xk IGhhdmUNCj4ga2VwdCBmcm9tIHdvcmsuDQo+IA0KPiBEZW4gMjAxNy0wMi0wMiBrbC4gMjM6MTks IHNrcmV2IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KToNCj4+IA0KPj4gU28gSSBtdWNoIHByZWZl ciB0aGUgY3VycmVudCB0ZXh0IGFuZCB0aGluayB0aGVyZSBhcmUgYSBidW5jaCBvZg0KPj4gcHJv YmxlbXMgd2l0aCB0aGlzIHRleHQuIElmIHdlIGFjdHVhbGx5IGhhZCBlbWFpbHMgZXhwbGFpbmlu ZyB3aGF0DQo+PiBwcm9ibGVtcyBpbiB0aGUgY3VycmVudCB0ZXh0IHRoaXMgd2FzIHRyeWluZyB0 byBmaXgsIHdpdGggaW5kaXZpZHVhbA0KPj4gUFJzIGZvciB0aG9zZSwgdGhpcyB3b3VsZCBiZSBt dWNoIGVhc2llciB0byByZXNvbHZlIGVhY2ggb2YgdGhlbSBhbmQNCj4+IGdldCB0aGVtIGZpeGVk Lg0KPj4gDQo+PiAxKSB3ZSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGF2b2lkIHRoZSB1c2Ugb2YgIlJU UCBzZXNzaW9uIiBhcyBpdCBoYXMNCj4+IGJlZW4gdmVyeSB1bmNsZWFyIHRvIGltcGxlbWVudG9y cyB3aGF0IGl0IGlzLiBJIHRoaW5rIHRoaXMgd291bGQgYmUNCj4+IGJldHRlciBpZiB3ZSBjb3Vs ZCByZXBocmFzZSB0byBub3QgdXNlIHRoYXQNCj4gDQo+IE9rYXksIGJ1dCB0aGUgUlRQIHNlc3Np b24gaXMgdmVyeSBlYXN5IHRvIG1ha2UgY2xlYXIgaW4gdGhlIGNvbnRleHQgaW4NCj4gb2YgQlVO RExFLCB3aGVyZSB0aGlzIHRleHQgaXMgaW50ZW5kZWQgdG8gYmUuIEkgY2FuIGltcHJvdmUgdGhh dC4NCj4gDQo+PiANCj4+IDIpIGJvdGggdGhlIHByb3Bvc2VkIGFuZCBjdXJyZW50IHRleHQgc2Vl bSBsYWNraW5nIGluIGRlYWxpbmcgd2l0aA0KPj4gbXVsdGlwbGUgYnVuZGxlIGdyb3Vwcw0KPiAN Cj4gT2theSwgdGhhdCBjYW4gYmUgZml4ZWQgYnkgY2xhcmlmeWluZyB0aGF0IGVhY2ggYnVuZGxl IGdyb3VwIHJlc3VsdHMgaW4NCj4gaXRzIG93biBSVFAgc2Vzc2lvbiwgdGh1cyB0aGUgcHJvY2Vk dXJlcyBpbiB0aGlzIGlzIHBlciBidW5kbGUgZ3JvdXAuDQo+IA0KPj4gDQo+PiAzKSBTdGF0cyBh cmUgdHlwaWNhbGx5IG1haW50YWluZWQgYnkgdGhpbmdzIGFmdGVyIHRoZSBwYWNrZXQgaXMNCj4+ IHJvdXRlZCAtIG5vdCBiZWZvcmUuDQo+IA0KPiBTbyB0aGlzIGNvbWVzIGEgcXVlc3Rpb24gb2Yg b25lcyB2aWV3IG9mIFJUUCBzdGFjayBhbmQgdGhlIHF1ZXN0aW9uIG9mDQo+IGxheWVyaW5nLiBB bmQgdGhpcyBpcyBleGFjdGx5IHdoeSBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQgaXMNCj4gcHJv YmxlbWF0aWMuIEl0IHRha2VzIG9uZSB2ZXJ5IHBhcnRpY3VsYXIgdmlldywgd2h5IEkgYXR0ZW1w dGVkIHRvIGJlDQo+IG11Y2ggbW9yZSBuZXV0cmFsIG9uIHdoaWNoIG9yZGVyIHRoaW5ncyBoYXBw ZW5zLiBUaGVyZSBhcmUgYSBudW1iZXIgb2YNCj4gZnVuY3Rpb25zIHRoYXQgYXJlIGluIHRoZSBS VFAgcHJvdG9jb2wgbGF5ZXIsIG5vdCBpbiB0aGUgaGlnaGVyIGxheWVycy4NCj4gVGhlcmUgYXJl IGhvd2V2ZXIgc29tZSB0aGluZ3MsIGxpa2UgWFIgVm9JUCBtZXRyY2lzIHRoYXQgYXJlIG1ldHJp Y3MgaW4NCj4gdGhlIGhpZ2hlciBsYXllcnMuIFNvLCB5ZXMgdGhpcyBpcyBub3QgY2xlYXIgY3V0 LiBJIHRoaW5rIG9uZXMgdmlldyBvZg0KPiB0aGlzIGRlcGVuZHMgb24gaWYgb25lIGhhdmUgYSB2 ZXJ5IGludGVncmF0ZWQgUlRQIGltcGxlbWVudGF0aW9uLCB0aGVuDQo+IHdoYXQgeW91IHNheSBt YWtlcyBzZW5zZSwgYnV0IGlmIG9uZSBoYXMgYSB2ZXJ5IGxheWVyZWQgYW5kIG1vZHVsYXJpemVk DQo+IGRlc2lnbiwgdGhlbiBteSB2aWV3cG9pbnQgbWFrZXMgbW9yZSBzZW5zZS4NCj4gDQo+IEZy b20gbXkgcGVyc3BlY3RpdmUgdGhlIG1vc3QgaW1wb3J0YW50IHRoaW5nIGhlcmUgaXMgdGhhdCB0 aGlzIHRleHQgaWYNCj4gaXQgY29udGFpbnMgYW55IFJGQyAyMTE5IHdvcmRzIGNhbid0IHByZXZl bnQgc29tZSBwb3NzaWJsZQ0KPiBpbXBsZW1lbnRhdGlvbiBjaG9pY2VzIG9mIHRoZSBSVFAgc3Rh Y2suDQo+IA0KPj4gDQo+PiA0KSBOZWVkIHRvIGV4cGxhaW4gaG93IHRoZSBTREVTIGluIGNvbXBv dW5kIFJUQ1AgY2F1c2VzIHVwZGF0ZXMNCj4+IA0KPiANCj4gSSBjYW4gYXR0ZW1wdCB0byBjbGFy aWZ5IHRoaXMuIEhvd2V2ZXIsIHRoZXJlIGlzIGEgcG90ZW50aWFsIGlzc3VlIGhlcmUNCj4gaW4g dGhhdCBzb21lIGltcGxlbWVudGF0aW9ucyBtYXkgbm90IGJlIGFibGUgdG8gZm9yY2UgdGhlIHJl Y2VpdmVyIHRvDQo+IHByb2Nlc3MgdGhlIGNvbnRlbnQgb2YgdGhlIFNERVMgUlRDUCBwYWNrZXQg cHJpb3IgdG8gc29tZSBvciBldmVuIGFsbA0KPiB0aGUgb3RoZXIgUlRDUCBwYWNrZXRzIGluIGEg Y29tcG91bmQgcGFja2V0Lg0KPiANCj4gV2hhdCBpbiB0aGUgY3VycmVudCB0ZXh0Og0KPiANCj4g ICAgT24gcmVjZXB0aW9uIG9mIGFueSBjb21wb3VuZCBSVENQIHBhY2tldCBwcmlvciB0byBkaXNw YXRjaGluZyB0aGUNCj4gICAgcmVjZWl2ZWQgaW5mb3JtYXRpb24gYW5kIGRhdGEsIGlmIHRoZXJl IGlzIGFuIFJUQ1AgU0RFUyBwYWNrZXQNCj4gICAgaW5jbHVkZWQgdGhhdCBTSE9VTEQgYmUgcHJv Y2Vzc2VkIGZpcnN0LiAgSWYgdGhhdCBTREVTIHBhY2tldA0KPiAgICBjb250YWlucyBTREVTIE1J RCBlbnRyaWVzLCB0aGlzIGNhbiByZXN1bHRzIGluIHVwZGF0ZXMgYW5kIGFkZGl0aW9ucw0KPiAg ICB0byB0aGUgUlRQIHN0cmVhbSB0byAibT0iIGxpbmUgbWFwcGluZyB0YWJsZS4gIFRodXMgZWFj aCBvZiB0aGUgU0RFUw0KPiAgICBNSUQgaXRlbXMgYXJlIHByb2Nlc3NlZCBhbmQgdGhlIGN1cnJl bnQgdGFibGUgZW50cmllcyBhcmUgY2hlY2tlZCBpZg0KPiAgICB0aGUgY29ycmVzcG9uZGluZyBN SUQgdmFsdWUgbWF0Y2hlcyB0aGUgY3VycmVudCBSVFAgc3RyZWFtIHRvICJtPSINCj4gICAgbGlu ZSBtYXBwaW5nLCBlbHNlIHRoZSBlbnRyeSBpcyB1cGRhdGVkLiAgSWYgdGhlcmUgaXMgbm8gUlRQ IHN0cmVhbQ0KPiAgICB0byAibT0iIGxpbmUgdGFibGUgbWFwcGluZyBlbnRyeSBmb3IgdGhlIHJl Y2VpdmVkIFNERVMgaXRlbSdzIFNTUkMsDQo+ICAgIHN1Y2ggYW4gZW50cnkgaXMgY3JlYXRlZC4g IE5vdGUsIHRoYXQgaW4gdGhlIHByb2Nlc3Mgb2YgdXBkYXRpbmcgdGhlDQo+ICAgIHRhYmxlIGVu dHJpZXMsIHVwZGF0ZSBmbGFwIHN1cHByZXNzaW9uIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQu Mi42DQo+ICAgIG9mIFtSRkM3OTQxXSBzaG91bGQgYmUgY29uc2lkZXJlZC4NCj4gDQo+IElzIGlu c3VmZmljaWVudCBpbiB0aGF0IHJlZ2FyZHMuIElzIGl0IG9ubHkgdGhlIHBsYWNlbWVudCBwcmlv ciB0byB0aGUNCj4gaW5kaXZpZHVhbCBSVENQIHBhY2tldCB0eXBlcyB0aGF0IGlzIHRoZSBpc3N1 ZT8gU2hvdWxkIHdpdGggdGhlDQo+IGV4Y2VwdGlvbiBvZiB0aGUgZmlyc3Qgc2VudGVuY2UgYmUg bW92ZWQgdW5kZXIgdGhlIFNERVMgdGV4dD8NCj4gDQo+PiA1KSBnaXZlbiB0aGlzIHJlbW92ZXMg dGhlIG91dGdvaW5nIFNTUkMgdGFibGUsIG5vdCBjbGVhciBob3cgaXQNCj4+IHJvdXRlcyBSVENQ IHJlcG9ydHMuIEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBjbGFyaWZpZWQuDQo+PiANCj4gDQo+ IE9rYXksIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHRoYXQuIEkgaGF2ZSBhbiBpbXBsaWNpdCBhc3N1 bXB0aW9uIHRoYXQgdGhlDQo+IGltcGxlbWVudGF0aW9uIGtub3dzIGhvdyBpdHMgbG9jYWwgKG91 dGdvaW5nKSBSVFAgU3RyZWFtcyBhcmUgcmVsYXRlZCB0bw0KPiB0aGUgbWVkaWEgc291cmNlcyBh bmQgdGh1cyB0aGUgcmVsYXRlZCBSVFBzZW5kZXIuIEkgY2FuIHVwZGF0ZSB0aGUgdGV4dA0KPiB0 byBhZGRyZXNzIHRoaXMuDQo+IA0KPj4gNikgSSBkb24ndCB0aGluayBtb3N0IGltcGxlbWVudGVy cyBhcmUgZ29pbmcgdG8gaGF2ZSBhIGNsdWUgd2hhdCB0bw0KPj4gZG8gZm9yIHRoZSAiVGhpcmQg UGFydHkgVGFyZ2V0ZWQgUmVwb3J0cyBvciBGZWVkYmFjayIgc2VjdGlvbg0KPj4gDQo+IA0KPiBJ IGNhbiB1bmRlcnN0YW5kIHRoYXQsIGJ1dCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBjYWxs IG91dCB0aGF0IHRoaXMNCj4gYnVja2V0IGRvIGV4aXN0LCBhbmQgaWYgeW91IGRvbid0IGtub3cg d2hhdCB0byBkbyBJIHRoaW5rIGl0IGlzIGZpbmUgdG8NCj4gaWdub3JlIHRoZXNlLg0KPiANCj4+ IEkgd2lsbCB0cnkgYW5kIHRha2UgeW91ciBQUiBhbmQgYnJlYWsgaXQgdXAgaW50byBzb21lIGJp dCBzaXplIHBpZWNlcw0KPj4gc28gd2UgY2FuIHRyeSBhbmQgc2VlIGlmIHdlIGNhbiBnZXQgdGhl IGVhc3kgb25lcyBvdXQgb2YgdGhlIHdheSBhbmQNCj4+IGZvY3VzIG9uIHRoZSBwYXJ0cyB0aGF0 IGFyZSBrZXkgY2hhbmdlcy4NCj4+IA0KPiANCj4gT2ssIEkgaGF2ZSBzZWVuIHRoYXQgeW91IGdl bmVyYXRlZCBhIGxvdCBvZiBpbmRpdmlkdWFsIGlzc3VlcywgSSB3aWxsIGF0dGVtcHQgdG8gbG9v ayB0aHJvdWdoIHRoZW0gYW5kIGNvbW1lbnQgaWYgdGhlcmUgYXJlIHRoaW5ncyB0aGF0IHdhcyB1 bmludGVudGlvbmFsIG9yIHdoZXJlIEkgaGF2ZSBhZGRpdGlvbmFsIGFzcGVjdHMgdG8gYWRkLg0K PiANCj4gSSBpbnRlbmQgdG8gdXBkYXRlIG15IFBSIGJhc2VkIG9uIHRoZSBmZWVkYmFjayBJIHJl Y2VpdmVkLg0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNz c29uIFJlc2VhcmNoIEVBQi9UWE0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAg ICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAg ICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9s bSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCg0K From nobody Thu Feb 16 02:09:16 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4961299FA for ; Thu, 16 Feb 2017 02:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 9_b1xcAC3kpv for ; Thu, 16 Feb 2017 02:09:13 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 EFDE81299F6 for ; Thu, 16 Feb 2017 02:09:12 -0800 (PST) X-AuditID: c1b4fb25-56ffb70000001738-72-58a57a458dfc Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 27.2D.05944.54A75A85; Thu, 16 Feb 2017 11:09:11 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Feb 2017 11:09:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sSynTLwtOcatj+Oj7HXo9SFndHbrebGAAIc0vIstZ90=; b=LoIutifiG7WETUfJEQLuVvb2FdLuPuZc3oIaz53mmp/9GNLgsgN8DBMtLoKJhqEnzHvlALqlJp3LWUDVAfG+4VZvN+LzdxYoO6v3UXwl1YhVYLvNzZpymL41uR81P59nu/F8j3BaxYT36zh86CETPF7IiJPHt3x+pliw8KcgLfk= Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com (10.173.80.145) by VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 10:09:08 +0000 Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com ([10.173.80.145]) by VI1PR0701MB2733.eurprd07.prod.outlook.com ([10.173.80.145]) with mapi id 15.01.0919.013; Thu, 16 Feb 2017 10:09:08 +0000 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" Thread-Topic: Describe parsing of SDP identity, and how multiple identities are handled, in security-architecture Thread-Index: AQHSiDy1avdLHr5FWk+NKFEM22crpw== Date: Thu, 16 Feb 2017 10:09:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stefan.lk.hakansson@ericsson.com; x-originating-ip: [192.176.1.93] x-ms-office365-filtering-correlation-id: 8846edb5-aa11-474f-5854-08d45653d89d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB2736; x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2736; 7:glMDOgbFgMhjw3WRkvf9Td8SOHYbg1so2j6HWaidv0ezEEUs2EBO+IPgv/vmCPZkghamOyki5yug2MJkV9R24eZE8sqLMYCpM0rz5hWC5v+db3mXFb5YnRA808g4XWWNT6ETysIvwdRY+sPGzaPsEa6pEjgiYqzvstzAouxLWSkE7lIaRw1sCleUB6YJJnEiMLrYq0MKUvnSi1N8ybXwJHm2Mb3sl/1MFOgR5ZdgpGU8KXS1O9v42HZEFp+5KNUc1dIYqXVL6TzHqfAlFDbaQOgr36S3gMGH+yQmxggQVwoRILMPSBmesZy8WnuzHTwD9ox3Rg0ke0EotrWITpofSA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:VI1PR0701MB2736; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2736; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(66066001)(105586002)(450100001)(2900100001)(97736004)(106116001)(92566002)(122556002)(6116002)(102836003)(8676002)(389900003)(3846002)(2906002)(8936002)(86362001)(1730700003)(81166006)(81156014)(189998001)(54356999)(50986999)(7736002)(6916009)(7696004)(2351001)(6436002)(99286003)(55016002)(3660700001)(25786008)(6506006)(15650500001)(6306002)(5660300001)(9686003)(5640700003)(3280700002)(106356001)(68736007)(74316002)(101416001)(33656002)(110136004)(38730400002)(77096006)(305945005)(2501003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2736; H:VI1PR0701MB2733.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 10:09:07.9845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2736 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUyM2K7ja571dIIgzP3eC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxry5G5kLZnFWbF/7jbmB8RN7FyMnh4SAicSrDXMZuxi5OIQE 1jFKXF/RygrhnGCUeLPtOBOIwyLQyywx9/BTdojMLCaJDfPXMYH0CwmcYpSYN1UExGYTCJTY um8BG4gtIqAucfnhBbAdwgL5EhNv9rBAxEsk+prboGw9iW87p7GC2CwCqhKzGg4C9XJw8Aok SLQ2CIOEGQXEJL6fWgO2illAXOLWk/lMEGcLSCzZc54ZwhaVePn4HytIK6NAssT0VjcQU0JA QeL+zSiICl+JZ8d/s0KE/SV2vBIBeURCoI9Z4vnKlWwQNfkS095+hbKtJRa0bmKGKJrHJNH/ ZBo0tGQkbuw6zQKReMYqcfz8DEZIMKRKLF/bygjxrpTE3SudULaMxIs7e1kh7teTuDF1ChuE rS2xbOFr5gmM6rOQvDYLSdksJGUgNq+AoMTJmU9YFjCyrGIULU4tTspNNzLWSy3KTC4uzs/T y0st2cQITA8Ht/xW3cF4+Y3jIUYBDkYlHt4POUsihFgTy4orcw8xSnAwK4nwuhcujRDiTUms rEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBkYnHwlO/yOSVzP6l czyuHClZNz1QxMZzg++tZAv/hBdSDIc7DU9WVKla2mQELzGfv1O4/dvFrwmS/DemzLqd2SH1 6MiN2qWb+SfuMH9pKVBSNyO38uIs9vC/J11dfR+osugm/Ondkr3w/xmlhNqW0g4B+/hI3Tf2 q95xGRws5GUNErm+YMEyJZbijERDLeai4kQAG2r45gsDAAA= Archived-At: Subject: [rtcweb] Describe parsing of SDP identity, and how multiple identities are handled, in security-architecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 10:09:15 -0000 Hi,=0A= =0A= after some discussing in in W3C webrtc-pc [1] and JSEP [2][3][4] github =0A= repos it seems the conclusion is that how identity is handled carried in = =0A= the SDP, and how identity in the SDP is parsed, and how multiple =0A= identity attributes (if we are to support that) should be describe in =0A= draft-ietf-rtcweb-security-arch [5].=0A= =0A= Identity in the SDP is currently described in =0A= draft-ietf-rtcweb-security-arch, but only for a single identity =0A= attribute, and parsing is not described, so it needs to be updated.=0A= =0A= I decided to send this to the list as the activity level at the github =0A= repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicating = =0A= the action happens elsewhere).=0A= =0A= Stefan=0A= =0A= =0A= [1] https://github.com/w3c/webrtc-pc/issues/964=0A= [2] https://github.com/rtcweb-wg/jsep/issues/546=0A= [3] =0A= https://github.com/rtcweb-wg/jsep/commit/a40fb5101ae530e97cea2073b507d7b417= df9e49=0A= [4] https://github.com/rtcweb-wg/jsep/issues/601=0A= [5] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch=0A= [6] https://github.com/rtcweb-wg/security-arch=0A= From nobody Thu Feb 16 07:21:05 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A0129D0B for ; Thu, 16 Feb 2017 07:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 V7SQIGMsFpWx for ; Thu, 16 Feb 2017 07:21:01 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D239129D0E for ; Thu, 16 Feb 2017 07:20:57 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id u68so9622440ywg.0 for ; Thu, 16 Feb 2017 07:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JJZoH4RsPorq+dQ/oR/IV9Q8CVadiekkK6BWRd1Ipao=; b=t1YTGAEav8gfMGkoJGRmRnmDMlrWvSxd976AgobiAmOyEgu7tLRGMG5zrpS1ql3MUo bIhjcd9U8t9HqGkl+LFXU7Q/UWVlYDvOlbQPCm5iWFkaqUhVwCS4qjVU0lkUO8Rkhhpj GDRWuPzYjJYAYDBUFRVAiR2bDoeitP1hiKXZxoey8VlHCR9EsLVwdPHtGYfoNKgEppnF 0xaGLw/31xqJJEyGExBGiobApM2UIu1WqVdV9I5/ui3319nBzO1le+QatCGuRQ6WDFDj N1JWvvrQN6GvEG7ghkpLF/njptUNoNe3AxFo180ureSph2kH7uQGkQG6YhT/PZ9vSN52 Fong== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JJZoH4RsPorq+dQ/oR/IV9Q8CVadiekkK6BWRd1Ipao=; b=IBnL9jndqPwkEpwFfvG2K7eGYBsY8SLLkZEx03hGe1vQcG/jQyC7o26Mg95N4Pj09A EAIlrVob+Z50H+dGkJOl/yljJLkxkIZNJfjCcXrUUBnM52ZbT7QPSDgRud3LdJ5sBWsX IL5I2eA9U1fqo9q9EPSNr4MHdInVax4YAnd3vTsdiTBpJXdHGfB+ZbdFP6+i4ysRXH9K kYDVmcHGUqGML8474SYbqxVQ6Mt+/99LySS1rDc3N0A7PgvckV3BUgAO3pV5RQOIjT5M eV6vIwVqg32+yD81F7UO7+O1kDMcRgHoYPlLZ3gzK5Q4/AhAtBJmlUBvWL6iN2eMSbic 3tCQ== X-Gm-Message-State: AMke39nYEEgBcisTgkX7urQC5To96ZpYfLWdoyi5tKL0VQqC06YT5MNMdLwSZ6F7Mu4+OIDzOc26fv7fBcmtcQ== X-Received: by 10.129.132.77 with SMTP id u74mr1889493ywf.125.1487258456597; Thu, 16 Feb 2017 07:20:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.224.131 with HTTP; Thu, 16 Feb 2017 07:20:16 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 16 Feb 2017 07:20:16 -0800 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=001a114f0996fedb7a0548a757d0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Describe parsing of SDP identity, and how multiple identities are handled, in security-architecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:21:03 -0000 --001a114f0996fedb7a0548a757d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 2:09 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > Hi, > > after some discussing in in W3C webrtc-pc [1] and JSEP [2][3][4] github > repos it seems the conclusion is that how identity is handled carried in > the SDP, and how identity in the SDP is parsed, and how multiple > identity attributes (if we are to support that) should be describe in > draft-ietf-rtcweb-security-arch [5]. > > Identity in the SDP is currently described in > draft-ietf-rtcweb-security-arch, but only for a single identity > attribute, and parsing is not described, so it needs to be updated. > > I decided to send this to the list as the activity level at the github > repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicating > the action happens elsewhere). > No, it's just that I'm too busy doing JSEP and TLS to do anything here. -Ekr > > Stefan > > > [1] https://github.com/w3c/webrtc-pc/issues/964 > [2] https://github.com/rtcweb-wg/jsep/issues/546 > [3] > https://github.com/rtcweb-wg/jsep/commit/a40fb5101ae530e97cea2073b507d7 > b417df9e49 > [4] https://github.com/rtcweb-wg/jsep/issues/601 > [5] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch > [6] https://github.com/rtcweb-wg/security-arch > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114f0996fedb7a0548a757d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 2:09 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
Hi,

after some discussing in in W3C webrtc-pc [1] and JSEP [2][3][4] github
repos it seems the conclusion is that how identity is handled carried in the SDP, and how identity in the SDP is parsed, and how multiple
identity attributes (if we are to support that) should be describe in
draft-ietf-rtcweb-security-arch [5].

Identity in the SDP is currently described in
draft-ietf-rtcweb-security-arch, but only for a single identity
attribute, and parsing is not described, so it needs to be updated.

I decided to send this to the list as the activity level at the github
repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicati= ng
the action happens elsewhere).


--001a114f0996fedb7a0548a757d0-- From nobody Thu Feb 16 08:03:02 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49595129ADC for ; Thu, 16 Feb 2017 08:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 7S092U-C41T9 for ; Thu, 16 Feb 2017 08:02:58 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 6248B129D01 for ; Thu, 16 Feb 2017 08:02:58 -0800 (PST) X-AuditID: c1b4fb3a-f72d4980000021e0-6e-58a5cd301edf Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id EE.96.08672.03DC5A85; Thu, 16 Feb 2017 17:02:56 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Feb 2017 17:02:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RdrkkS/Pmt5D8i3XWk5HAvjoH7Mo4/mQ4F1pBiGMrF0=; b=Ck0Vuv6QE4+H1CgV9HlHCbrU1zXDclEFylTOTuH0XfLjnL3Jl6k1qo3CT4ag0HZHcKKeErgr6XhWHudvu3+AinhZVBQpLJehBi1nLkLbklQyYj6UXyk5R7Fxzo4v1Kj1+HktWelrrBjxSo6OCtOfwjOfOe4v9utojkm24ZN37IY= Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com (10.173.80.145) by VI1PR0701MB2733.eurprd07.prod.outlook.com (10.173.80.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 16:02:03 +0000 Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com ([10.173.80.145]) by VI1PR0701MB2733.eurprd07.prod.outlook.com ([10.173.80.145]) with mapi id 15.01.0919.013; Thu, 16 Feb 2017 16:02:03 +0000 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Eric Rescorla Thread-Topic: [rtcweb] Describe parsing of SDP identity, and how multiple identities are handled, in security-architecture Thread-Index: AQHSiGhsRqsKoeLkKkWQIAIZzlnkNw== Date: Thu, 16 Feb 2017 16:02:03 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stefan.lk.hakansson@ericsson.com; x-originating-ip: [192.176.1.93] x-ms-office365-filtering-correlation-id: c7db2687-a39f-43dd-1bb4-08d45685261d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB2733; x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2733; 7:xC/yGQlgNWDDWaJlKmeMilERCPVVOpZfwjMijmYLIiqaUR+/RwjE138T6v4AnDd0hAKCaDEQ5zrg1S5vJrHhQDUCpUWm0Ua0gwbE/4PRiChmtAlCMm8Jnhb+SwLNn4tRmh3T9txoC9unhiQ426yLLXjz8qAFMPLn6zWHxa9qumwX6THa60poaRkDQ+WYOJdiAlPBzeVBuzqwLzNawjSYO0Q88NWmi0Q44mZGbVFwpjn0tHg60FcQnVGIOSUPlJ74VG3TpUdiFFbfazTUTEY3HeD2vmI+ALwYoWW8QW5P72/7fz+hdlOtLa5jBmVo/TWxeBmX26eOMKvilI1VB+PyXA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:VI1PR0701MB2733; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2733; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(189002)(199003)(24454002)(77096006)(105586002)(86362001)(106116001)(6436002)(106356001)(97736004)(2906002)(101416001)(6506006)(4326007)(15650500001)(54356999)(229853002)(3280700002)(3846002)(68736007)(389900003)(102836003)(6116002)(189998001)(50986999)(38730400002)(76176999)(110136004)(6246003)(122556002)(5660300001)(33656002)(81166006)(6916009)(66066001)(3660700001)(25786008)(305945005)(8676002)(8936002)(7696004)(99286003)(9686003)(6306002)(53936002)(55016002)(74316002)(92566002)(81156014)(2900100001)(7736002)(53546005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2733; H:VI1PR0701MB2733.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 16:02:03.4812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2733 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbFdXdfg7NIIg7mzjSxWvD7HbrH2Xzu7 A5PHkiU/mTwmP25jDmCK4rJJSc3JLEst0rdL4MrYvK+dveChUMWnba+ZGxg38HcxcnJICJhI nN64lLmLkYtDSGAdo8TzL/+YQRJCAicYJTZ90QdJsAj0Mku8vvSNDaJqFpPEpsvf2SGcU4wS U9bMAGthEwiU2LpvARuILSKgIPHrzwkWEJtZQF3izuJz7CC2sEC1xL7nk4FsDqCaGonVG1wh yvUktl2aDFbCIqAqseXsEbAxvAIJEgvXbobatZxRYk3Pd7AEo4CYxPdTa5gg5otL3Hoynwni HwGJJXvOM0PYohIvH/9jBdnFKJAsMb3VDcSUADrt/s0oiApfiZtTzjFC2P4Sk5qXgENCQqCP WaJjXzdUIl/i18cTbBC2t8TE6Reh7HlMEnPXFUHYMhI3dp1mgWj+zirxrvEHOyQYUyWWr21l hPhdSuLulU4oW0bixZ29rBMYNWcheQHC1pO4MXUKG4StLbFs4WvmWeCwEJQ4OfMJywJGllWM osWpxcW56UZGeqlFmcnFxfl5enmpJZsYgUnj4JbfVjsYDz53PMQowMGoxMNbsG9phBBrYllx Ze4hRgkOZiUR3oy1QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFk mTg4pRoYoyQeODRdDjbafMGn8PtK92nzJ3q8lLSond94tu36s01/HB90Tdfxf7xxfnvJ/Ck+ KRMlLmza/OiQbiH/ueJfO6bn9T+4G7Ns8/unlaopXLKR77059y0OXLikjbFyr15Dr89+PlUN r/KaN0lxrLmeogZyM/7NLQq8eW1lk97abFfuef/OCZ/fqsRSnJFoqMVcVJwIAB97Y+UWAwAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Describe parsing of SDP identity, and how multiple identities are handled, in security-architecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:03:00 -0000 Thanks Ekr, I'll create a github Issue then.=0A= =0A= On 16/02/17 16:22, Eric Rescorla wrote:=0A= >=0A= >=0A= > On Thu, Feb 16, 2017 at 2:09 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > Hi,=0A= >=0A= > after some discussing in in W3C webrtc-pc [1] and JSEP [2][3][4] gith= ub=0A= > repos it seems the conclusion is that how identity is handled carried= in=0A= > the SDP, and how identity in the SDP is parsed, and how multiple=0A= > identity attributes (if we are to support that) should be describe in= =0A= > draft-ietf-rtcweb-security-arch [5].=0A= >=0A= > Identity in the SDP is currently described in=0A= > draft-ietf-rtcweb-security-arch, but only for a single identity=0A= > attribute, and parsing is not described, so it needs to be updated.= =0A= >=0A= > I decided to send this to the list as the activity level at the githu= b=0A= > repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicat= ing=0A= > the action happens elsewhere).=0A= >=0A= >=0A= > No, it's just that I'm too busy doing JSEP and TLS to do anything here.= =0A= >=0A= > -Ekr=0A= >=0A= >=0A= >=0A= > Stefan=0A= >=0A= >=0A= > [1] https://github.com/w3c/webrtc-pc/issues/964=0A= > =0A= > [2] https://github.com/rtcweb-wg/jsep/issues/546=0A= > =0A= > [3]=0A= > https://github.com/rtcweb-wg/jsep/commit/a40fb5101ae530e97cea2073b507= d7b417df9e49=0A= > =0A= > [4] https://github.com/rtcweb-wg/jsep/issues/601=0A= > =0A= > [5] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch=0A= > =0A= > [6] https://github.com/rtcweb-wg/security-arch=0A= > =0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= > =0A= >=0A= >=0A= =0A= From nobody Fri Feb 17 03:04:42 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02548129998; Fri, 17 Feb 2017 03:04:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148732947900.19956.15739414442610855397.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2017 03:04:39 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 11:04:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-17.txt Pages : 23 Date : 2017-02-17 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-overview-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 21 06:38:52 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D441129493 for ; Tue, 21 Feb 2017 06:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 j7QPlBYmyKt2 for ; Tue, 21 Feb 2017 06:38:50 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE5C129478 for ; Tue, 21 Feb 2017 06:38:50 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id p22so123608413qka.0 for ; Tue, 21 Feb 2017 06:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=mZQnw4tUIlr19w/bBPJvmRkCzH1U18jfCpySbmyJvdE=; b=IboVsZhF32WKLiIQjoXkbXe7WzwRD8eoDPswXeQGQzaDN53WCFF0ER0+HSqgGxePU2 Z8s7Tlq0Ihz3a/RuVWBTYyvoROvKS50xEOpTQBXxHvxmE1PTOTDFGu+/CS9Lq977xQDG wFuPqMHenHGLsuWSn8f/cAckmIysX8IFm2WyM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=mZQnw4tUIlr19w/bBPJvmRkCzH1U18jfCpySbmyJvdE=; b=Czl9XC7mx6eft4+Q+P2Xl+akJAitRllVXxOTGnoE5VQgobhhOwIIL6Pnp+3nx8gt7X QRvLP7zHUiwKvlV5oY+iQDCThLOZlkDzj832wOZ1LRt6hf4xTIOlpzFfbiM7WsqY1bZd cVgzOBvjFmMruYjYbkz2IPFUHpRuiuUspjQPp5KtpLhbQ1QWlQcixeor8LrmjrWnnAO3 6/dNo6WrAJeOBGx25N6vDKkgzgw6rnFgjcjz2DdDH9lxkX0OtXzqaAS2PsMgMpoBGJVm Ze065qW3cTsQReCU5lXEcwWobE17Bsoi2RybTmcNUamfnYFUHwr5FQ9KU/8NEAKyPzeb V0ug== X-Gm-Message-State: AMke39mUM6nCogM0D2O8yurwvurLflUWP4jaew0vYY7bDaF6KcbLIe16I52xyODiHDSzOw== X-Received: by 10.55.56.204 with SMTP id f195mr9585719qka.49.1487687928654; Tue, 21 Feb 2017 06:38:48 -0800 (PST) Received: from [172.16.0.18] ([96.231.229.68]) by smtp.gmail.com with ESMTPSA id c19sm14098703qtc.29.2017.02.21.06.38.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 06:38:47 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <89E21B20-5318-4F87-A5B5-BC4425EF8182@sn3rd.com> Date: Tue, 21 Feb 2017 09:38:45 -0500 To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [rtcweb] PRs for draft-ietf-rtcweb-overview-17 ID-nits X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:38:51 -0000 I submitted PRs to address the ID-nits uncovered during my Shepherd = review of -17: - https://github.com/rtcweb-wg/rtcweb-overview/pull/11 - https://github.com/rtcweb-wg/rtcweb-overview/pull/10 spt= From nobody Tue Feb 21 14:01:38 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFD129D27 for ; Tue, 21 Feb 2017 14:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 c5XXcur9GCP4 for ; Tue, 21 Feb 2017 14:01:34 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEF6129D22 for ; Tue, 21 Feb 2017 14:01:34 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s186so135833401qkb.1 for ; Tue, 21 Feb 2017 14:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4Wng/nzZcM5huC0wX0F2et6U1OWvNMH90xMCYM5Gr0g=; b=d1NrcPFGQMTEmjQLxXpKkoV0z4qLGCjhtLFAvpwpEIeXNcdTVtrA4v0ud75yC0QvMe 5TdkzezHR90l6V61LmrjrZ5iQh0/fd9yVf4CDyQqVqSX+3ymhC4rwqD0K+u/SnljlX7f 3cjgdEEWzcsW3ipVN4y8soFazIPg+r0VZby74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4Wng/nzZcM5huC0wX0F2et6U1OWvNMH90xMCYM5Gr0g=; b=gJJmF+aASKkwlem2EIc1fzQR7BlYYrn7aYEz7bm8qyFq3eT6VKjxMSmT+valOM39Bi abimyYwHKme1XkEG5IJbLBeOsi/BeKTlInx2Vi1L2a6sXvWK6QEluELiDS6lpc6H0Zn7 SE3NcTujzD/ZnYCACVNkKJeLkNFriPG/zhzawKeWIvyMzrCLPrwM/eMuz5czsog+t0Ka K6mMHFvdLWwUvxrvSUMgatiwUKMjXZ2mfRPLh0Kv6fMP4kKbY05YeRM5hPOnAoCnL0Oe 2Tja07C+ahz+ucUIihfLBA2sAQ88Z16wETpgjC8PtCtseTnak0Yvw8zf8CusxVbbiR8x 0sbg== X-Gm-Message-State: AMke39lyMH54ZQKUKDn3FA+XBLbc7dODaeNdegB+C3zIRTHdvoGLtONGuVyTiDZNTEe+TA== X-Received: by 10.55.178.132 with SMTP id b126mr25371422qkf.225.1487714493080; Tue, 21 Feb 2017 14:01:33 -0800 (PST) Received: from [172.16.0.92] ([96.231.229.68]) by smtp.gmail.com with ESMTPSA id v2sm7509376qte.61.2017.02.21.14.01.31 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Feb 2017 14:01:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <89E21B20-5318-4F87-A5B5-BC4425EF8182@sn3rd.com> Date: Tue, 21 Feb 2017 17:01:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <70737458-9E03-4E8E-AE85-AC4BA650ECF4@sn3rd.com> References: <89E21B20-5318-4F87-A5B5-BC4425EF8182@sn3rd.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] forwarding overview to our AD (was Re: PRs for draft-ietf-rtcweb-overview-17 ID-nits) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 22:01:36 -0000 Note that after consultation with Alissa, I=E2=80=99m going to go ahead = and push this draft to her plate. spt > On Feb 21, 2017, at 09:38, Sean Turner wrote: >=20 > I submitted PRs to address the ID-nits uncovered during my Shepherd = review of -17: > - https://github.com/rtcweb-wg/rtcweb-overview/pull/11 > - https://github.com/rtcweb-wg/rtcweb-overview/pull/10 >=20 > spt From nobody Wed Feb 22 13:15:02 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C05C129B50 for ; Wed, 22 Feb 2017 13:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=B90bBW7j; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=I5Uey8Rs 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 3ojxnYasCghv for ; Wed, 22 Feb 2017 13:14:56 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F448129B5E for ; Wed, 22 Feb 2017 13:14:56 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EF4AA21BDA for ; Wed, 22 Feb 2017 16:14:55 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 22 Feb 2017 16:14:55 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=UTMQe9rkN4inGbCi5EdZI7oSBRQ=; b=B90bBW 7jjKf/hJc+5vpon6Zk2LH7BoN7Sxb/SgTJmP9gVp6Si07ifYQPhJ3QCUx7x6142o 4/LPu+JTzRjJ29lDRMus0GXLPQTRyomcbwtm2A15fVonpKvwkHEuC0cP4zvk5q/+ HM5o41vmAH7eWIBX69UXCLU9AFNV4qO7uKLHM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=UTMQe9rkN4inGb Ci5EdZI7oSBRQ=; b=I5Uey8RsrBFSTJEPXDcwXjWnihM8NNQcQ3XMkTeiA+X26/ 5XIJaDr9LIEQNGjPNrOHq0/Og7BKZPXB2UVMo6OQjg/XAegump9FnKB0K8x9Z5sl 5jddG6CEot+pI0uLBC5dZbnWsN29izUhULCVgTsRWK4o0FJjZegxo89NyEnVk= X-ME-Sender: X-Sasl-enc: j+pGCDi+F3lomTC6+IT+4KxqaiFm7xMioKqs3o8ezeHa 1487798095 Received: from dhcp-10-150-9-191.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id BA0CE7E53B for ; Wed, 22 Feb 2017 16:14:55 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 22 Feb 2017 16:14:55 -0500 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-overview-17 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:14:58 -0000 I have reviewed this document in preparation for IETF last call. While = the document content appears mostly ready, I don't think it makes sense = to send this document out for IETF LC while the security documents are = expired. For community review and IESG evaluation I think those doing = the reviewing need at a minimum to feel like the normative dependencies = in this document are in roughly the shape they will be in when those = dependency documents get published. So at a minimum I think revisions of = the security documents need to be published before IETF LC for this = document makes sense. Otherwise I have one substantive comment below and some nits to be = resolved together with Sean=E2=80=99s PRs. Substantive comment: =3D Section 9 =3D "Certain parts of the system SHOULD conform to certain properties, for instance: o Echo cancellation should be good enough to achieve the suppression of acoustical feedback loops below a perceptually noticeable level. o Privacy concerns MUST be satisfied; for instance, if remote control of camera is offered, the APIs should be available to let the local participant figure out who's controlling the camera, and possibly decide to revoke the permission for camera usage. o Automatic gain control, if present, should normalize a speaking voice into a reasonable dB range." I think there are some problematic uses of normative language here. = Saying systems SHOULD conform to "certain properties" but not listing = what all of those properties are and not defining them precisely seems = problematic since implementers aren't being given clear directives. = Likewise, the second bullet's MUST is quite vague and again just gives = examples of how to comply rather than specifying precisely how. It's = also confusing to use normative SHOULD in the heading but non-normative = "should" in the bullets. My suggestion would be to not use normative language in this part at = all, since these aren't really hard requirements anyway. E.g.,=20 "Ideally certain parts of the system would conform to certain = properties, for instance: o Echo cancellation needs to be good enough to achieve the = suppression of acoustical feedback loops below a perceptually noticeable level.=20 =20 o Privacy concerns need to be satisfied; for instance, if remote control of camera is offered, the APIs should be available to let the local participant figure out who's controlling the camera, and possibly decide to revoke the permission for camera usage. o Automatic gain control, if present, needs to normalize a speaking voice into a reasonable dB range." If you really want to use normative language here, I would suggest that = the "shoulds" in the bullets become SHOULDs and the middle bullet = provide precise guidance about what is required. Nits to be resolved together with Sean's PRs: =3D Section 2.2 =3D Would be good to cite the protocol spec in the bulleted list at the top. s/Javascript API defined above/Javascript API cited above/ =3D Section 2.4 =3D A citation for Jingle should be included. I don't really understand why this text is included or what it means: "NOTE: Where common definitions exist for these terms, those definitions should be used to the greatest extent possible." =3D Section 7 =3D It would be good to include citations for Bundle, RTCP-mux and Trickle = ICE.