From karl.stahl@intertex.se Wed May 1 04:12:41 2013 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 6696B21F8AD1 for ; Wed, 1 May 2013 04:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxXZsMBG0iKa for ; Wed, 1 May 2013 04:12:36 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6521F89A6 for ; Wed, 1 May 2013 04:12:34 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id MQN15219; Wed, 01 May 2013 13:12:19 +0200 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'Harald Alvestrand'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> In-Reply-To: Date: Wed, 1 May 2013 13:12:19 +0200 Message-ID: <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHORiot3hT0toA1x0SAjJDE87njG5jv9reg Content-Language: sv X-Spam-IndexStatus: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] =?iso-8859-1?q?Network_times_=2E_was_SDP_Security_Descri?= =?iso-8859-1?q?ptions_=28RFC_4568=29_and_RTCWeb?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:12:41 -0000 Regarding delays... Today, packets over the Internet reach any point on the earth within 250 = ms as Cullen found - There are simply nowhere packet are stored/buffered in = any amount to give higher delays (Where would Gbps be stored for a second?). Routers drop packets at congestion, they don't store them (and light = takes 140 ms for a turn around the earth, somewhat slower in a fiber). So, the problem with voice/video quality (if overall bandwidth for the RTP/UDP is sufficient and up) is only dropped packets, which "only" = happens at congestion points where the pipe gets filled by TCP data (surf, = email, file transfer), when TCP end-points regulate down to share the pipe in = their hunger for infinite transfer speed. Then both TCP and RTP/UPD packets = are dropped as a consequence of intense TCP-flows initiation. (The static situation is ok - no packets are dropped) Second long packet delays must come from retransmission of lost packets. = If DTLS, it must be a higher level retransmission, I believe.=20 Questions: 1) Does DTLS take long time to set up in itself in the browser (Aren't = self signed certificate generated and exchanged?) while SRTP/DES is less CPU intense with ready certificate over the signaling path (I think)? But is this significant on let's say a 1 GHz smartphone which would be the = lowest CPU power to consider? 2) Are packet drops during TLS-setup more likely over the UDP channel between browsers (as for DTLS) than over the signaling channel (for SRTP/DES). And are there more packets that safely need to arrive with = DTLS setup? 3) SRTP/DES setup rely on TCP retransmission if packets are lost = (correct me if I am wrong), while DTLS must rely on some other higher level retransmission mechanisms. Are there longer timers involved then? I = think this may be the real explanation for reports of slow DTLS setup, isn't = it? The only cure against dropped UPD packets is IP-level QoS, such as = traffic shaping in firewalls/routers (but they need to be aware of traffic type) = and diffserv or reservation over the transport network- but that is = (currently) not enabled over the Internet, where all traffic is best effort class. /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Cullen Jennings (fluffy) Skickat: den 1 maj 2013 07:10 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C4mne: [rtcweb] Network times =85 was SDP Security Descriptions (RFC = 4568) and RTCWeb On Apr 29, 2013, at 2:29 AM, Harald Alvestrand = wrote: > Would it be possible to get real data on 1) and 2) here, so that we = can stop talking about "slow" and instead talk about "N milliseconds"? >=20 I did try and round up a bunch of data for ping times from India to Singapore as some people were suggesting these were 1500ms.=20 I got measurements from both home DSL and more business class from a = range of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than = 250 ms one way. If someone has an actually link that is getting 1500 ms out = of India, I'd love to get the info so I can see what I can learn (the = buffer bloat folks want to hear about this :-) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Wed May 1 04:41:54 2013 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 42CDD21F8606 for ; Wed, 1 May 2013 04:41:54 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNb0PPyqSbgf for ; Wed, 1 May 2013 04:41:46 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id CC24C21F84F9 for ; Wed, 1 May 2013 04:41:45 -0700 (PDT) Received: (qmail 64666 invoked from network); 1 May 2013 11:41:44 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 1 May 2013 11:41:44 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BF63118A0520; Wed, 1 May 2013 12:41:44 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9A6D118A0313; Wed, 1 May 2013 12:41:44 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> Date: Wed, 1 May 2013 12:41:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1283) Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:41:54 -0000 >=20 > 2) Are packet drops during TLS-setup more likely over the UDP channel > between browsers (as for DTLS) than over the signaling channel (for > SRTP/DES). And are there more packets that safely need to arrive with = DTLS > setup? >=20 > 3) SRTP/DES setup rely on TCP retransmission if packets are lost = (correct me > if I am wrong), while DTLS must rely on some other higher level > retransmission mechanisms. Are there longer timers involved then? I = think > this may be the real explanation for reports of slow DTLS setup, isn't = it? >=20 > The only cure against dropped UPD packets is IP-level QoS, such as = traffic > shaping in firewalls/routers (but they need to be aware of traffic = type) and > diffserv or reservation over the transport network- but that is = (currently) > not enabled over the Internet, where all traffic is best effort class. If we are seeing variability in DTLS setup times that don't seem to be = justified=20 by ping times it may be due to MTU issues. DTLS has some rules (which I don't yet clearly understand) about how = much one can stuff into a packet based on an assumed/derived/calculated MTU.=20= Guess too high and your packet will be dropped - forcing a retry with = the data broken over multiple packets.=20 I suspect we may have a little learning to do in the implementations to = select an optimum MTU for the wild internet. In these cases I'm sure packet captures set to the implementors would be = most welcome. Tim. From radhika.r.roy.civ@mail.mil Wed May 1 04:46:49 2013 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 39B7321F8506 for ; Wed, 1 May 2013 04:46:49 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZylpAmneLl4B for ; Wed, 1 May 2013 04:46:43 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id AEE6621F8512 for ; Wed, 1 May 2013 04:46:42 -0700 (PDT) Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 1 May 2013 11:46:32 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.82]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.03.0123.003; Wed, 1 May 2013 11:46:32 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Karl Stahl , "'Cullen Jennings (fluffy)'" , 'Harald Alvestrand' Thread-Topic: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) Thread-Index: AQHORiot3hT0toA1x0SAjJDE87njG5jv9reggAA9LSA= Date: Wed, 1 May 2013 11:46:31 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> In-Reply-To: <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CE463F.FD36BCF0" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:46:49 -0000 ------=_NextPart_000_0000_01CE463F.FD36BCF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Caveats: NONE Folks: I am responding only on a part of this email about retransmissions of = audio or video packets. Let us not consider the retransmission of audio or video packets. Let us consider audio or video packets are sent only over UDP. Let MOS/QoS of = audio or video are considered in a way that retransmissions do not take place. Then the question comes only about "data" traffic retransmissions. Data traffic can tolerate much higher delays than that of audio or video. = Data has only QoS (and no MOS). Let us divide the performance problems in two different parts. In this case, we can have more focused solutions related to = (Audio/Video) MOS/QoS or (Data) QoS as explained above. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Karl Stahl Sent: Wednesday, May 01, 2013 7:12 AM To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb Regarding delays... Today, packets over the Internet reach any point on the earth within 250 = ms as Cullen found - There are simply nowhere packet are stored/buffered in = any amount to give higher delays (Where would Gbps be stored for a second?). Routers drop packets at congestion, they don't store them (and light = takes 140 ms for a turn around the earth, somewhat slower in a fiber). So, the problem with voice/video quality (if overall bandwidth for the RTP/UDP is sufficient and up) is only dropped packets, which "only" = happens at congestion points where the pipe gets filled by TCP data (surf, = email, file transfer), when TCP end-points regulate down to share the pipe in = their hunger for infinite transfer speed. Then both TCP and RTP/UPD packets = are dropped as a consequence of intense TCP-flows initiation. (The static situation is ok - no packets are dropped) Second long packet delays must come from retransmission of lost packets. = If DTLS, it must be a higher level retransmission, I believe.=20 Questions: 1) Does DTLS take long time to set up in itself in the browser (Aren't = self signed certificate generated and exchanged?) while SRTP/DES is less CPU intense with ready certificate over the signaling path (I think)? But is this significant on let's say a 1 GHz smartphone which would be the = lowest CPU power to consider? 2) Are packet drops during TLS-setup more likely over the UDP channel between browsers (as for DTLS) than over the signaling channel (for SRTP/DES). And are there more packets that safely need to arrive with = DTLS setup? 3) SRTP/DES setup rely on TCP retransmission if packets are lost = (correct me if I am wrong), while DTLS must rely on some other higher level retransmission mechanisms. Are there longer timers involved then? I = think this may be the real explanation for reports of slow DTLS setup, isn't = it? The only cure against dropped UPD packets is IP-level QoS, such as = traffic shaping in firewalls/routers (but they need to be aware of traffic type) = and diffserv or reservation over the transport network- but that is = (currently) not enabled over the Internet, where all traffic is best effort class. /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Cullen Jennings (fluffy) Skickat: den 1 maj 2013 07:10 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C4mne: [rtcweb] Network times =85 was SDP Security Descriptions (RFC = 4568) and RTCWeb On Apr 29, 2013, at 2:29 AM, Harald Alvestrand = wrote: > Would it be possible to get real data on 1) and 2) here, so that we=20 > can stop talking about "slow" and instead talk about "N milliseconds"? >=20 I did try and round up a bunch of data for ping times from India to Singapore as some people were suggesting these were 1500ms.=20 I got measurements from both home DSL and more business class from a = range of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than = 250 ms one way. If someone has an actually link that is getting 1500 ms out = of India, I'd love to get the info so I can see what I can learn (the = buffer bloat folks want to hear about this :-) Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0000_01CE463F.FD36BCF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA1MDExMTQ2MjhaMCMGCSqGSIb3DQEJBDEWBBQtc7AxnUTyci2SyV98aD1I 2xJeYzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAMG65qqrezLfz+I6/FYN81o9t1UuMHj81NkCMCqPcC0cAPAXRUAVVlia+qQdpuXUeZLS XU2imH/1K6KHpphzakndbc8l5bZBlxLHdyQZ5uWhooorGkMPnPc9cKDjSvuBIftdy/1svCPDPvX1 UWWaBbJdNV2kJtMkgtQxyHfgUTyGF+s6aj04EZXsWZfsPvS6eEW0/qcnwj2rzv6iy1z3lkTNwBmN sAYGmt6QSNTtXhibjsbIUYVNrkhSfppdGZF/Jay5AZyEWSnV6AZdVTbx6P8fj0fHF+76IjD/1QTu EGsMlRsHH8NwRgLXPN+X6ZTnR7ILYeLTNDaHkTScHtoMd/MAAAAAAAA= ------=_NextPart_000_0000_01CE463F.FD36BCF0-- From stefan.lk.hakansson@ericsson.com Wed May 1 05:20:20 2013 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 BB8E421F9195 for ; Wed, 1 May 2013 05:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvIdN2nM2OtX for ; Wed, 1 May 2013 05:20:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C864F21F90B9 for ; Wed, 1 May 2013 05:20:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-13-51810877aa1a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 34.91.10459.77801815; Wed, 1 May 2013 14:20:07 +0200 (CEST) Received: from Ericssons-MacBook-Pro-StefanH.local (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 1 May 2013 14:20:07 +0200 Message-ID: <5181087A.3090305@ericsson.com> Date: Wed, 1 May 2013 14:20:10 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <066.3120a55540cacaa74ee5fda0b5273a48@trac.tools.ietf.org> <5174C8D2.40504@matthew.at> <5177F7EE.1010909@matthew.at> <5179A362.2000309@jesup.org> <517A86CB.5020305@matthew.at> <517ABB06.5070807@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3BB9C130@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3BB9C130@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+JvrW45R2OgwYzFlhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+DtfYwFR+oq1t47x9LAuCW1i5GTQ0LARKLj3S5mCFtM4sK9 9WxdjFwcQgKnGCXa/s5kgnD2MUp0NU5mAaniFdCWaNn1HqyDRUBF4syOC2A2m4CNxNruKUAN HByiAskSExeXQ5QLSpyc+QSsVURAWGLrq14mEFtYwFJizbxXrBDzW1gknv6aAFbEKRArcX7X erAiZgFbiQtzrrNA2NoSyxa+BtslJKAr8e71PdYJjAKzkOyYhaRlFpKWBYzMqxjZcxMzc9LL DTcxAgPt4JbfujsYT50TOcQozcGiJM6rx94YKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR trL47V8Np5eh3jdcP+dcX7Zk+vPkrbM/rNikeLHR49nTfRyla1/5LUppKXnQ47nb9qjxLf9j zrxKLIE/6nTNd/Kt8+4v9i+UuuEYVvMmSez83jff2HZmXNp9QP/j7nUnk+v27EmYPf2Q95UP vapWX/OyTpzXkMybfzzW6EzW9S2B/9c9DdD4ocRSnJFoqMVcVJwIAOeH9f0CAgAA Subject: Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:20:20 -0000 I've also been silent during this discussion, but I have a different view= =2E We've seen arguments about that OPEN "only" has a value for the=20 application. But isn't the main target for the rtcweb work web=20 applications? Randell has shown that OPEN has a big value for the web=20 application, and, furthermore, the OPEN conveys information that is=20 needed for the API that has been designed over at the W3C side. And I have not really seen any arguments on why we should omit OPEN=20 (only the view that it is not needed). I think we should move on. Let's detail out how we treat data before=20 OPEN has been received. And that design may not have to be perfect day=20 one, we could tweak it based on experience from real world usage (there=20 have been discussion on how (un-)likely it is that you could get a lot=20 of data over but not OPEN). If we don't change the API the applications=20 won't break. Stefan On 4/29/13 4:11 PM, Ejzak, Richard P (Richard) wrote: > After remaining neutral during most of this discussion about the need f= or OPEN, I've finally come to the conclusion that Matthew is right. The = only thing the OPEN provides is the label, which is just an opaque string= with no meaning to the browser or any intermediaries. It only has appli= cation significance. If this is the case, why not just use stream id? W= hat can you possibly do with label that you can't do with pre-assigned st= ream ids (this is a serious question to Randell since it is fundamental t= o whether we need OPEN)? Since label only has meaning when both browsers= run the same application, what does it matter if you agree on a set of o= paque strings to correspond to various functions or just agree on a set o= f stream ids for these functions? It doesn't change the complexity of th= e code and it doesn't even change the readability of the code if you just= enumerate the reserved stream ids and "label" them in the code. > > You can even reserve stream ids in odd/even pairs so that either end ca= n initiate them. You can reserve blocks of stream ids if you want multip= le instances of the same type of DC. I don't see any significant limitat= ion here. > > Getting rid of OPEN eliminates any issues around their handling in the = unordered case. > > Getting rid of OPEN does not preclude use of new subprotocols as needed= and does not preclude use of any other signaling to negotiate use of Dat= aChannels between heterogeneous applications. OPEN does not help in this= case anyway. > > >> On 4/25/2013 12:36 PM, Randell Jesup wrote: >> On 4/26/2013 9:53 AM, Matthew Kaufman wrote: >>> On 4/25/2013 2:42 PM, Randell Jesup wrote: >>>> On 4/25/2013 5:10 PM, Cullen Jennings (fluffy) wrote: >>>>> So with my co-chair hat on here... >>>>> >>>>> It seems we have been around the need for OPEN several times and >>>>> have come to consensus on it in the past. Can someone please: >>>>> >>>>> 1) summarize the arguments that in the past that lead us to think >> we >>>>> need OPEN >>>> The Open message has some important and useful properties: >>>> >>>> 1) It's easier to work with. JS isn't an ideal language for writing= >>>> network protocols, especially for non-network-programmers (i.e. a >>>> large portion of the expected developer community). Open makes it >>>> really easy for a developer to get the type of bidirectional stream >>>> them want with little fuss, and in a manner that maps easily to APIs= >>>> they're already used to (e.g. WebSockets). In many cases the label >>>> field will avoid the JS programmer having to build their own >>>> mini-protocol to identify their channels (and this is especially >>>> painful for them if it's an unreliable channel). >>> Easier how? The initiating side needs to create their object without >>> the benefit of the contents of an open message. If a JS developer >>> isn't smart enough to set up the channel parameters they want at the >>> initiating end, then there's nothing we can do for them. There's then= >>> several ways forward after that, including "the other side does the >>> same thing to create their end" (my preference) and "the parameters >>> are transported using the existing SDP O/A mechanism to the far end" >>> (generally how the WG solves this kind of problem). >>> >>> As far as I can tell, the one useful thing in the OPEN message is the= >>> label (as I pointed out in my very first inquiry about why anyone >>> thought it was needed), and yet the label is allowed to be null, so >> in >>> that case how can it be helpful? >> It's helpful if you need it (if you're opening a number of channels, >> such as one per participant in a conference). Protocol is also helpfu= l >> (note it's in the dictionary and is also optional); both for cross- >> application channels and for within an app to indicate what handling >> logic the channel should feed. >> >> // pseudo-codey: >> function called_from_ondatachanne(event) { >> channel =3D event.channel; >> if (channel.protocol =3D=3D "file transfer") { channel.onmessage =3D= >> handle_incoming_file; } >> else if (channel.protocol =3D=3D "chat") {chat =3D new >> chat_instance(channel.label); channel.onmessage =3D chat.incoming; } }= >> >>>> 2) It makes it possible to have different applications exchange >> data, >>>> by having an IANA-registered protocol name, like WebSockets (and >>>> there was strong agreement on it's being needed for that at >>>> Atlanta.) With external-negotiation-only, it would be very hard for= >>>> different apps to interoperate, since they'd need to agree on >>>> negotiation protocols as well, which are likely to be highly >>>> divergent between apps. >>> If we went with "negotiated via the SDP O/A mechanism" then we could >>> go to our favorite SDP-defining WG and have a negotiation protocol >>> that is standardized, so not divergent at all between apps. >> We also don't have one that's divergent by using Open (and we leave th= e >> option of externally negotiating or pre-defining channels). And SDP is= >> at least one signaling-RTT to complete, plus a bunch of logic to handl= e >> matching everything up (what if channels disappear in the offer or >> answer, or in an offer or answer they change properties? What if the >> signaling channel is slow or unavailable any more (server rebooted, >> server has network issues, etc)? >> >> I'm not saying there aren't answers/solutions to all these. But those= >> answers and solutions would need to be speced out or at least >> understood, and the code to handle all of them is likely to be similar= >> in scope (though quite different in detail). And the less done in SDP= , >> the better IMHO; I have no wish to increase our reliance on SDP. >> >>>> 3) The Open message, being in-channel, reliable and in-order, makes >>>> the issue that was the genesis of this thread (what to do with data >>>> that arrives unexpectedly) simpler. >>> I disagree. It increases the number of possible states... there's >>> cases where the OPEN message arrives but the application doesn't want= >>> to be receiving that data, and the cases where the OPEN message >>> doesn't arrive but the application does want the data that is already= >>> arriving. Both of those states don't exist if there's no OPEN >> message. >> >> My point was you need to decide what to do with that data regardless o= f >> if the channel gets created with a delayed OPEN or with a delayed >> external negotiation. And with OPEN, those cases don't even arise for= >> ordered channels. >> >>>> With Open, only degenerate cases can cause more than a relatively >>>> small amount of data to be buffered. >>> Sure, but those degenerate cases occur many times per day on the real= >>> Internet. >> I doubt that. The degenerate cases for Open require that all the open= >> packets get lost, while a sizable amount of non-open packets get >> through >> - and after a time, SCTP will fail the entire association if reliable >> data isn't getting through. Plus, as I indicated, we can also have >> limits on time and/or amount of data buffered. >> >> Also: nothing *requires* that an application send data immediately on >> onopen. An application can institute it's own handshake trivially: >> function my_ondatachannel(event) { >> event.channel.send(ok_to_start_sending); ... } >> >>>> With external notification, the external negotiation channel can >> fail >>>> (or be very slow), or the app can have a bug and fail to install the= >>>> negotiated values, leading to larger or unbounded buffering >>>> requirements - or you punt the problem to the application by >>>> delivering the data, but the application is facing the same >> conundrum >>>> of buffer it or throw it away. >>>> >>>>> 2) sketch out the range of possible solutions to deal with >>>>> unexpected data before the OPEN >>>> >>>> The issue exists regardless of whether Open is used or external >>>> negotiation (and in fact is much simpler for Open). >>>> >>>> *tl;dr: *I'm ok with any setting of maximum sizes and/or times that >>>> would not adversely impact temporary buffering for normal cases with= >>>> Open of unordered channels. This is option C below. I also would be= >>>> ok with B, but I realize others may not be. >>>> >>>> Regardless of supporting Open or not, any external negotiation of >>>> dynamic channels must use one of these: >>>> >>>> A) a 2-or-3-way handshake so the sender knows the receiver is ready >>>> to receive the data on the specified channel before sending it, or >>>> >>>> B) unbounded buffering of data if the external negotiation messages >>>> are delayed (again, what we're discussing in this thread), or >>>> >>>> C) bounded buffering of data (bounded by time, size or both), with >>>> data being dropped and the channel closed if the limits are >> exceeded, or >>>> D) deliver unexpected data to the application, which will do .... I >>>> don't know what with it. >>>> >>>> For (D), the application will likely drop it on the floor (leading >> to >>>> hard-to-test-for problems if the channel is later configured by Open= >>>> or external negotiation), or buffer it waiting for the channel to >> open. >>>> Supporting Open or not has little bearing on these scenarios >>> So if that's true, then why do we need it? >> This was a discussion of "what to do with data that arrives >> unexpectedly >> (i.e. before Open, or before the application installed the result of a= n >> external negotiation); this was the original point of the thread befor= e >> you decided to question the selection of Open as a message. >> >> The caveat at the top was "external negotiation of dynamic channels >> must >> do one of these" regardless of whether Open is supported. The options= >> for use with Open are the same, but the amount of data that can be >> buffered is smaller (since with external negotiation there are no >> limits >> on the amount that could attempt to be queued -- the same applies SDP >> if >> you allow the sender to send data before the negotiation is complete; >> SDP is effectively a form of external negotiation). >> >>>> -- and in fact, since Open is in-channel, reliable, and ordered, it >>>> reduces the problem set (when Open is used) to only unordered >>>> channels (in ordered channels Open will always be first). >>>> >>>> Buffering unexpected data on channels (options B or C) is useful. It= >>>> means that in the external negotiation case, one side asking for a >>>> new channel to open by some private means doesn't need to wait to >>>> start sending data on that channel. >>> Of course this is different from the TCP model, where the buffering >>> happens at the *sender* until the handshake is complete. >> Ok, but this isn't TCP. And handshakes (and the resultant delay befor= e >> onopen fired) were eliminated in order to respond to the requests of >> multiple people, giving us a 0-RTT declarative protocol where you can >> send immediately, which will help apps that need to exchange data >> quickly at the start of a connection. >> >>> The problem here is that we have an existing mechanism inside of SCTP= >>> and then we're adding another layer on top of that which is neither >>> inside SCTP (where it probably belongs) or under the application >>> developer's control (where I'd like to see it, if the data transport >>> protocol can't have it), and this layer conflicts with what both of >>> those might be doing. >> If you're referring to Open, you can totally ignore Open and not use i= t >> in your datachannels, and use all external negotiation or pre-defined >> channels. If you want, you can just pre-define N open channels that >> the >> other side can then use to send data to you, and nothing will ever be >> buffered, and you can handle it all yourself. >> >>>> Note that with external negotiation (possibly on a non p2p path, >> like >>>> via signaling), the receiver might not know what to install for a >>>> short while, especially if there's a routing issue or server issue >>>> (not a problem that happens with Open). >>> Which is fine if the sender doesn't start sending (like TCP). Or if >>> the transport protocol itself handles the delivery of the channel >>> metadata. (Which is what SCTP, or whatever transport we choose for >>> RTCWEB, should do) then you just handle the label and whatever other >>> metadata the receiver would like to know at that layer. >> I.e. data streams from RTMFP, I take it? ;-) >> >>>> Since normal Open cases have very little chance of triggering this >>>> problem (triggering buffering), some arbitrary size limit seems >>>> reasonable (option C). Often in network protocols there are small >>>> buffers (4, 16, 64KB). I prefer a larger value of say 256KB so that= >>>> apps using external negotiation can just send largish data >>>> immediately - and note: actually buffering data is still an unlikely= >>>> occurrence even in most external negotiation cases. If people want >>>> to bikeshed on the buffersize or timeout, that's fine. ;-) >>>> >>>> Also, external negotiation is the only case where more than a >> trivial >>>> amount of data can "pile up" in the buffer waiting for the receiving= >>>> side to finish it's side of the negotiation (i.e. if your external >>>> negotiation channel fails or the app has a brain fart). >>>> >>>> >>> Another great argument for having this negotiation happen within the >>> transport itself. >> If you want to argue for replacing SCTP as the base layer - we made >> that >> decision a good long while ago. And there's a good, maintained, >> BSD-licensed implementation - and the authors of that are working with= >> us here in designing a DataChannel protocol to ride on top of it. If >> you want to argue that the layer on top of SCTP should be handshaked >> once again (as it was until people objected) that's up to you to make >> the case for. >> >> IMO: >> I'd like to avoid continuing to circle through the range of all >> possible >> protocols one at a time, repeating every few months. I'll assert we >> can >> bikeshed on this until we all retire, and we'll never have something >> that makes everyone entirely happy (unless most people get tired and >> stop caring). All solutions have tradeoffs; none is perfect for all >> use-cases and users. We arrived at a proposal that had general >> agreement in the room to move forward with per the consensus call, and= >> I'm preparing a WG draft in response to that. Some may like it more >> and >> some less, but there was agreement that people could work with it. >> >> -- >> Randell Jesup >> randell-ietf@jesup.org >> >> _______________________________________________ >> 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 fluffy@cisco.com Wed May 1 06:39:18 2013 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 E1B5621F9EAE for ; Wed, 1 May 2013 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8rTENTka6D2 for ; Wed, 1 May 2013 06:39:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8E21F9EC4 for ; Wed, 1 May 2013 06:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=566; q=dns/txt; s=iport; t=1367415553; x=1368625153; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OJjKbhvxAzSkMQi32qNaj4DoOt4p31315JAVTBN3/SQ=; b=gNTkgCD/xFsKFzxh+3BgXZj4W+dzT2D+Z06/WgpQCIJHUtKmAToGlcEZ fqW8w7NFSYKQpePT2vNRBK5/sNUKmslcU0QPWe84vMwnOSxmnjwabq+EC XG6b0CYiTe8+4QJLZFtSE4WFV2hws42AAs9QmhBs7RFyoVKZJepWNXiaX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFANUagVGtJXG+/2dsb2JhbABSgweDJrwnfRZ0gh8BAQEDATozDAULAgEIIhQQMiUCBA4FCId+Br8QjmYCMQeCb2EDqFOBVYE4gic X-IronPort-AV: E=Sophos;i="4.87,589,1363132800"; d="scan'208";a="205190496" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 01 May 2013 13:39:05 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r41Dd4ZK004757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 May 2013 13:39:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 1 May 2013 08:39:04 -0500 From: "Cullen Jennings (fluffy)" To: Tim Panton Thread-Topic: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb Thread-Index: AQHORiot3hT0toA1x0SAjJDE87njG5jv9reggACSf4CAACDDgA== Date: Wed, 1 May 2013 13:39:03 +0000 Message-ID: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <3661887C8348B348923544EC7B94DE41@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:39:19 -0000 On May 1, 2013, at 5:41 AM, Tim Panton wrote: > DTLS has some rules (which I don't yet clearly understand) about how much > one can stuff into a packet based on an assumed/derived/calculated MTU.=20 > Guess too high and your packet will be dropped - forcing a retry with the= data > broken over multiple packets.=20 >=20 > I suspect we may have a little learning to do in the implementations to s= elect > an optimum MTU for the wild internet. How are you doing the MTU stuff? Just the openssl default or something else= ? From juberti@google.com Wed May 1 08:44:21 2013 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 2763121F9A51 for ; Wed, 1 May 2013 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55K1cao2hidU for ; Wed, 1 May 2013 08:44:17 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id A440E21F9A47 for ; Wed, 1 May 2013 08:44:06 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id w7so958605qeb.17 for ; Wed, 01 May 2013 08:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=l/LcIgin8M74otkfbwEWxRaimtNGGpI2ZV+ZZb7OayQ=; b=cJYufE3D5MduMVZGxvcMPzwOkk2hy7KS5Ynon5+WYNXPDVljT99JGdzwb+VQN4LPPv Z02SffS9lV4TXYo5yYt5iiGaWxAo406ZmXRnMvKoJYr9PobAdahw2qmj4Sy93A/TLt// oXBDWmiom7pRF37LM0AEhquW6vPg4mFPh9RFUK9KPGhyzH78xr3X8TFdNZjuDcvBAhmX 8eHg4me7wwd3gGS9TlO7aynl3eSm8YBdulrwMh2lEZ+Ocx+HKpQnNDMpoGDYehM2I4X/ qAqwj/YJh7fi77gfXw59YnN3PienD4T4zAPPK0e10Zk0cuio5GH+8XFNrweuiRky3iJV 1J1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=l/LcIgin8M74otkfbwEWxRaimtNGGpI2ZV+ZZb7OayQ=; b=Nz4USVRZdCRFgt8f6z/x+mMIezByxhXaC0TnBQir8zPomyFTukgfABePRoEJTanhCz HAtFXQw2OEpBDrIkupw0GwBMZSV8IiJ4PiM8SK8Ch7Ho1OsQcq7SuPUMBe60N+tmqCFG 15AFtI4v6ZAConGOsKR+6LTHp47e1XGx9XMw6n6aJAoAWXAYOeKbvqtfhqgOpeKC50Of DRn2QGxrrUS/dZORgUCH/eh+h9PgGQpjCRxOWqgMigfq8+uafz6yRBVlfFUuv0qCyrLy DHIyw5/qVh5JfZrtbBNmJZEoOGnOJ1hPS1P/f4NE5gUbB3F3wntQtwiajlWm8x/zyh7k mUCA== X-Received: by 10.49.35.72 with SMTP id f8mr3992113qej.4.1367423045840; Wed, 01 May 2013 08:44:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.28 with HTTP; Wed, 1 May 2013 08:43:44 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 1 May 2013 08:43:44 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b6776eae7fb7b04dba9fc6b X-Gm-Message-State: ALoCoQncb5FnC6KBWAuuXFu4ibra0qWspO08fIj92ajYKa7lisOf0F+J3AwelSCCB0KhbJl4y5KVpyB8a/BMWoeS5emp4UXW+8jbVXSRfmzfNaR3ax1hvwhqqNItGbOX38IagWfkygiGPnbIyqxGutsXPtHesq7CJmeGTVYJPnmfgcLtPRWUwOG46iHKu+/4QEmDPsLTmqGf Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] My SDP doesn't interoperate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:44:21 -0000 --047d7b6776eae7fb7b04dba9fc6b Content-Type: text/plain; charset=UTF-8 The one SDP issue mentioned in that document has been fixed; that document is now outdated by events. Regarding the "100 lines", that code promoted Opus to be the preferred codec, as well as disabling CN. This munging is also no longer needed; we have now added support for the VoiceActivityDetection constraint to control use of CN. On Fri, Apr 26, 2013 at 12:00 PM, Martin Thomson wrote: > (was Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb) > > On 26 April 2013 11:07, Cullen Jennings (fluffy) wrote: > > > > On Apr 26, 2013, at 7:47 AM, Tim Panton wrote: > > > >> If anyone still thinks that SDP is just a blob not an API surface, take > a look at the 'reference implementation' of browser to browser interop. > >> > https://code.google.com/p/webrtc-samples/source/browse/trunk/apprtc/index.html > >> > >> I count around 100 lines of javascript munging the SDP. > > > > Could you just summarize what the 100 lines do and which theses would be > needed for browsers that implemented the drat standards? I'm trying to dig > into what we need to fix. > > http://www.webrtc.org/interop > > That's probably out of date, but you get the idea. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b6776eae7fb7b04dba9fc6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The one SDP issue mentioned in that document has been fixe= d; that document is now outdated by events.

Regard= ing the "100 lines", that code promoted Opus to be the preferred = codec, as well as disabling CN. This munging is also no longer needed; we h= ave now added support for the VoiceActivityDetection constraint to control = use of CN.


On Fri,= Apr 26, 2013 at 12:00 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
(was Re: [rtcweb] SDP Security Descriptions = (RFC 4568) and RTCWeb)

On 26 April 2013 11:07, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> On Apr 26, 2013, at 7:47 AM, Tim Panton <tim@phonefromhere.com> wrote:
>
>> If anyone still thinks that SDP is just a blob not an API surface,= take a look at the 'reference implementation' of browser to browse= r interop.
>> https://code.google.com/p/webrtc= -samples/source/browse/trunk/apprtc/index.html
>>
>> I count around 100 lines of javascript munging the SDP.
>
> Could you just summarize what the 100 lines do and which theses would = be needed for browsers that implemented the drat standards? I'm trying = to dig into what we need to fix.

http://www.webr= tc.org/interop

That's probably out of date, but you get the idea.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b6776eae7fb7b04dba9fc6b-- From juberti@google.com Wed May 1 09:01:51 2013 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 C408221F936F for ; Wed, 1 May 2013 09:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5R83E-9Eu2H for ; Wed, 1 May 2013 09:01:47 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 676DF21F9361 for ; Wed, 1 May 2013 09:01:47 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id x7so962862qeu.20 for ; Wed, 01 May 2013 09:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ayQ8CeAPxl3BdGFCqsADTrUxCyZyQEB0LzWkSd9V4yI=; b=hq/5AlA+NjI/WG1CjUomG47ffCgK671T4YW8S16pjKb/C/BK2rmbNNuariAvX0nNbP MSKYbo5b+shMn0IbVrKQepA7rbSNcYNKBr7w0ZGIsjZamwVe+/sm0n/u7gcR3K+aa149 Gn4GABOhLTTf9YwQjqZokPSG+K5cNrI1RfS4KXLjjZCKDJ8bYY9I6Jr3l1mxIpUeW7J+ wOWGtyAtCLiLVqFFswsgE88+LG9I6/6BbHTe7d0zILkArLxmtKWLZwPUfWBBpW3AGEN9 c8KcKT2+LkFJa3SMdvesJxHg5f/3DCZFhctlfX0IJhtmlzuPRJ1x8RZrKdfK5qLa3OQJ UVPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ayQ8CeAPxl3BdGFCqsADTrUxCyZyQEB0LzWkSd9V4yI=; b=P8Oi3tbkfHqBKbPBSxvQ4QQrUwUpXMFAvV4xPj8J/Y80VYDDbRmrJOBGehrFEMfSy9 w8Hrshu3VIdsC+QTAehjuidePGfOruvWQp24u9ysfJduy6bgTCM9HFfFRakRne3NtlkP c9j2CLB/Vu7wDyhe+35RAUUVSWlD1lTKgFqRdIcv+MW7dc4ifh2G/IYi9OqGq1zFMRRr t3m/Rroeb+NfHvCDQVVZOHWw2KU/QFuVcJheJrtxJrYrRcpc2pMDEmFzw6luJcx7HcSK ZpT9cskvLGieNAtJu1DWwu2LExvd466cJ/jCPSvv2ldLTf0D/d/Y7B1sMjwUdLACzwtQ Ue0w== X-Received: by 10.49.35.72 with SMTP id f8mr4090893qej.4.1367424106731; Wed, 01 May 2013 09:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.28 with HTTP; Wed, 1 May 2013 09:01:25 -0700 (PDT) In-Reply-To: <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Wed, 1 May 2013 09:01:25 -0700 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=047d7b6776ea23b75f04dbaa3c79 X-Gm-Message-State: ALoCoQkk+edNeMonKc865F+Fzwv1aC6kofg4QemXLTHzXYhWZmOktasZah3S+MJKuw2nX5ck9cJDP5y0zlcQCTW9XkD/iVUhxZU/h3Ro0n7Oa+rU2J+lMrnZicfylfrUwxzGZ75YTVDPx58Ai9ax79kt90ZS4HpA5znEDAEeY35/najqRZzwZg40/Ug6J+z5o3kDAI+EB8ki Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:01:52 -0000 --047d7b6776ea23b75f04dbaa3c79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This doesn't match what we are seeing. I pulled some Chrome stats on average RTT seen across various network connections; on 3G, close to half of users had RTTs > 250 ms. 4G is somewhat better. 2G is considerably worse= . India continues to be especially bad, partially because of the above, partially because of use of satellite links, which due to physics incur 500 ms RTTs. On Wed, May 1, 2013 at 4:12 AM, Karl Stahl wrote: > Regarding delays... > > Today, packets over the Internet reach any point on the earth within 250 = ms > as Cullen found - There are simply nowhere packet are stored/buffered in > any > amount to give higher delays (Where would Gbps be stored for a second?). > Routers drop packets at congestion, they don't store them (and light take= s > 140 ms for a turn around the earth, somewhat slower in a fiber). > > So, the problem with voice/video quality (if overall bandwidth for the > RTP/UDP is sufficient and up) is only dropped packets, which "only" happe= ns > at congestion points where the pipe gets filled by TCP data (surf, email, > file transfer), when TCP end-points regulate down to share the pipe in > their > hunger for infinite transfer speed. Then both TCP and RTP/UPD packets are > dropped as a consequence of intense TCP-flows initiation. (The static > situation is ok - no packets are dropped) > > Second long packet delays must come from retransmission of lost packets. = If > DTLS, it must be a higher level retransmission, I believe. > > Questions: > > 1) Does DTLS take long time to set up in itself in the browser (Aren't se= lf > signed certificate generated and exchanged?) while SRTP/DES is less CPU > intense with ready certificate over the signaling path (I think)? But is > this significant on let's say a 1 GHz smartphone which would be the lowes= t > CPU power to consider? > > 2) Are packet drops during TLS-setup more likely over the UDP channel > between browsers (as for DTLS) than over the signaling channel (for > SRTP/DES). And are there more packets that safely need to arrive with DTL= S > setup? > > 3) SRTP/DES setup rely on TCP retransmission if packets are lost (correct > me > if I am wrong), while DTLS must rely on some other higher level > retransmission mechanisms. Are there longer timers involved then? I think > this may be the real explanation for reports of slow DTLS setup, isn't it= ? > > The only cure against dropped UPD packets is IP-level QoS, such as traffi= c > shaping in firewalls/routers (but they need to be aware of traffic type) > and > diffserv or reservation over the transport network- but that is (currentl= y) > not enabled over the Internet, where all traffic is best effort class. > > /Karl > > > > -----Ursprungligt meddelande----- > Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3= =B6r Cullen > Jennings (fluffy) > Skickat: den 1 maj 2013 07:10 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > =C3=84mne: [rtcweb] Network times =E2=80=A6 was SDP Security Descriptions= (RFC 4568) and > RTCWeb > > > On Apr 29, 2013, at 2:29 AM, Harald Alvestrand > wrote: > > > Would it be possible to get real data on 1) and 2) here, so that we can > stop talking about "slow" and instead talk about "N milliseconds"? > > > > I did try and round up a bunch of data for ping times from India to > Singapore as some people were suggesting these were 1500ms. > > I got measurements from both home DSL and more business class from a rang= e > of sources in India. It seems that anywhere one could run video, you can > ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than > 250 > ms one way. If someone has an actually link that is getting 1500 ms out o= f > India, I'd love to get the info so I can see what I can learn (the buffer > bloat folks want to hear about this :-) > > > > > > > _______________________________________________ > 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 > --047d7b6776ea23b75f04dbaa3c79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This doesn't match what we are seeing. I pulled some C= hrome stats on average RTT seen across various network connections; on 3G, = close to half of users had RTTs > 250 ms. 4G is somewhat better. 2G is c= onsiderably worse.

India continues to be especially bad, partially becaus= e of the above, partially because of use of satellite links, which due to p= hysics incur 500 ms RTTs.


On Wed, May 1, 2013 at 4:12 AM, Karl Stahl <karl.stahl@intertex.se> wrote:
Regarding delays...

Today, packets over the Internet reach any point on the earth within 250 ms=
as Cullen found - There are simply nowhere packet are stored/buffered in an= y
amount to give higher delays (Where would Gbps be stored for a second?). Routers drop packets at congestion, they don't store them (and light ta= kes
140 ms for a turn around the earth, somewhat slower in a fiber).

So, the problem with voice/video quality (if overall bandwidth for the
RTP/UDP is sufficient and up) is only dropped packets, which "only&quo= t; happens
at congestion points where the pipe gets filled by TCP data (surf, email, file transfer), when TCP end-points regulate down to share the pipe in thei= r
hunger for infinite transfer speed. Then both TCP and RTP/UPD packets are dropped as a consequence of intense TCP-flows initiation. (The static
situation is ok - no packets are dropped)

Second long packet delays must come from retransmission of lost packets. If=
DTLS, it must be a higher level retransmission, I believe.

Questions:

1) Does DTLS take long time to set up in itself in the browser (Aren't = self
signed certificate generated and exchanged?) while SRTP/DES is less CPU
intense with ready certificate over the signaling path (I think)? But is this significant on let's say a 1 GHz smartphone which would be the low= est
CPU power to consider?

2) Are packet drops during TLS-setup more likely over the UDP channel
between browsers (as for DTLS) than over the signaling channel (for
SRTP/DES). And are there more packets that safely need to arrive with DTLS<= br> setup?

3) SRTP/DES setup rely on TCP retransmission if packets are lost (correct m= e
if I am wrong), while DTLS must rely on some other higher level
retransmission mechanisms. Are there longer timers involved then? I think this may be the real explanation for reports of slow DTLS setup, isn't = it?

The only cure against dropped UPD packets is IP-level QoS, such as traffic<= br> shaping in firewalls/routers (but they need to be aware of traffic type) an= d
diffserv or reservation over the transport network- but that is (currently)=
not enabled over the Internet, where all traffic is best effort class.

/Karl



-----Ursprungligt meddelande-----
Fr=C3=A5n: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] F=C3=B6r Cullen
Jennings (fluffy)
Skickat: den 1 maj 2013 07:10
Till: Harald Alvestrand
Kopia: rtcweb@ietf.org
=C3=84mne: [rtcweb] Network times =E2=80=A6 was SDP Security Descriptions (= RFC 4568) and
RTCWeb


On Apr 29, 2013, at 2:29 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> Would it be possible to get real data on 1) and 2) here, so that we ca= n
stop talking about "slow" and instead talk about "N millisec= onds"?
>

I did try and round up a bunch of data for ping times from India to
Singapore as some people were suggesting these were 1500ms.

I got measurements from both home DSL and more business class from a range<= br> of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than 25= 0
ms one way. If someone has an actually link that is getting 1500 ms out of<= br> India, I'd love to get the info so I can see what I can learn (the buff= er
bloat folks want to hear about this :-)






_______________________________________________
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

--047d7b6776ea23b75f04dbaa3c79-- From Michael.Tuexen@lurchi.franken.de Wed May 1 09:18:18 2013 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 C43C821F9A30 for ; Wed, 1 May 2013 09:18:18 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzjQtrX-1vZS for ; Wed, 1 May 2013 09:18:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7A43F21F9A2F for ; Wed, 1 May 2013 09:18:17 -0700 (PDT) Received: from [192.168.1.200] (174.Red-2-139-184.staticIP.rima-tde.net [2.139.184.174]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 23A2E1C103E5A; Wed, 1 May 2013 18:18:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> Date: Wed, 1 May 2013 18:18:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <053FBB50-842E-4530-8C21-9B8D78632B48@lurchi.franken.de> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1283) Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:18:18 -0000 On May 1, 2013, at 1:12 PM, Karl Stahl wrote: > Regarding delays... >=20 > Today, packets over the Internet reach any point on the earth within = 250 ms > as Cullen found - There are simply nowhere packet are stored/buffered = in any > amount to give higher delays (Where would Gbps be stored for a = second?). > Routers drop packets at congestion, they don't store them (and light = takes > 140 ms for a turn around the earth, somewhat slower in a fiber). >=20 > So, the problem with voice/video quality (if overall bandwidth for the > RTP/UDP is sufficient and up) is only dropped packets, which "only" = happens > at congestion points where the pipe gets filled by TCP data (surf, = email, > file transfer), when TCP end-points regulate down to share the pipe in = their > hunger for infinite transfer speed. Then both TCP and RTP/UPD packets = are > dropped as a consequence of intense TCP-flows initiation. (The static > situation is ok - no packets are dropped) >=20 > Second long packet delays must come from retransmission of lost = packets. If > DTLS, it must be a higher level retransmission, I believe.=20 >=20 > Questions: >=20 > 1) Does DTLS take long time to set up in itself in the browser (Aren't = self > signed certificate generated and exchanged?) while SRTP/DES is less = CPU > intense with ready certificate over the signaling path (I think)? But = is > this significant on let's say a 1 GHz smartphone which would be the = lowest > CPU power to consider? >=20 > 2) Are packet drops during TLS-setup more likely over the UDP channel > between browsers (as for DTLS) than over the signaling channel (for > SRTP/DES). And are there more packets that safely need to arrive with = DTLS > setup? >=20 > 3) SRTP/DES setup rely on TCP retransmission if packets are lost = (correct me > if I am wrong), while DTLS must rely on some other higher level > retransmission mechanisms. Are there longer timers involved then? I = think > this may be the real explanation for reports of slow DTLS setup, isn't = it? In case of message loss of DTLS handshake messages, DTLS retransmits = them. Similar to what TCP would do timer based. Best regards Michael >=20 > The only cure against dropped UPD packets is IP-level QoS, such as = traffic > shaping in firewalls/routers (but they need to be aware of traffic = type) and > diffserv or reservation over the transport network- but that is = (currently) > not enabled over the Internet, where all traffic is best effort class. >=20 > /Karl >=20 >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Cullen > Jennings (fluffy) > Skickat: den 1 maj 2013 07:10 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > =C4mne: [rtcweb] Network times =85 was SDP Security Descriptions (RFC = 4568) and > RTCWeb >=20 >=20 > On Apr 29, 2013, at 2:29 AM, Harald Alvestrand = wrote: >=20 >> Would it be possible to get real data on 1) and 2) here, so that we = can > stop talking about "slow" and instead talk about "N milliseconds"? >>=20 >=20 > I did try and round up a bunch of data for ping times from India to > Singapore as some people were suggesting these were 1500ms.=20 >=20 > I got measurements from both home DSL and more business class from a = range > of sources in India. It seems that anywhere one could run video, you = can > ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less = than 250 > ms one way. If someone has an actually link that is getting 1500 ms = out of > India, I'd love to get the info so I can see what I can learn (the = buffer > bloat folks want to hear about this :-) >=20 >=20 >=20 >=20 >=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 From bernard_aboba@hotmail.com Wed May 1 10:46:09 2013 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 6FE4621F9AB9 for ; Wed, 1 May 2013 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bttEBOegUSe for ; Wed, 1 May 2013 10:46:05 -0700 (PDT) Received: from blu0-omc1-s11.blu0.hotmail.com (blu0-omc1-s11.blu0.hotmail.com [65.55.116.22]) by ietfa.amsl.com (Postfix) with ESMTP id E1FCF21F98F1 for ; Wed, 1 May 2013 10:46:04 -0700 (PDT) Received: from BLU169-W73 ([65.55.116.8]) by blu0-omc1-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 May 2013 10:46:00 -0700 X-EIP: [61mNPdU/h5jT8dH46oxTHieovKm0cBHX] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_851b3757-e20a-42c8-aca4-61e639ac25cc_" From: Bernard Aboba To: Justin Uberti Date: Wed, 1 May 2013 10:46:00 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2013 17:46:00.0835 (UTC) FILETIME=[BE5EE530:01CE4693] Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] My SDP doesn't interoperate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:46:09 -0000 --_851b3757-e20a-42c8-aca4-61e639ac25cc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From what I could tell=2C most of the interop issues addressed in the most = recent sample app were not SDP-related=2C but dealt with differences in API= implementations=2C quite a few of which should be expected to disappear wh= en the API spec is finalized. =20 Of course=2C the sample app is not attempting to address legacy interop=2C = which is where I am expecting the narliest interop issues to arise (particu= larly video). And as we get more WebRTC browser implementations=2C the amo= unt of interop code will undoubtedly grow. =20 From: juberti@google.com Date: Wed=2C 1 May 2013 08:43:44 -0700 To: martin.thomson@gmail.com CC: fluffy@cisco.com=3B rtcweb@ietf.org Subject: Re: [rtcweb] My SDP doesn't interoperate The one SDP issue mentioned in that document has been fixed=3B that documen= t is now outdated by events. Regarding the "100 lines"=2C that code promoted Opus to be the preferred co= dec=2C as well as disabling CN. This munging is also no longer needed=3B we= have now added support for the VoiceActivityDetection constraint to contro= l use of CN.=0A= =0A= On Fri=2C Apr 26=2C 2013 at 12:00 PM=2C Martin Thomson wrote: =0A= =0A= (was Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb) =0A= =0A= On 26 April 2013 11:07=2C Cullen Jennings (fluffy) wrote= : =0A= > =0A= > On Apr 26=2C 2013=2C at 7:47 AM=2C Tim Panton wro= te: =0A= > =0A= >> If anyone still thinks that SDP is just a blob not an API surface=2C tak= e a look at the 'reference implementation' of browser to browser interop. =0A= >> https://code.google.com/p/webrtc-samples/source/browse/trunk/apprtc/inde= x.html =0A= >> =0A= >> I count around 100 lines of javascript munging the SDP. =0A= > =0A= > Could you just summarize what the 100 lines do and which theses would be = needed for browsers that implemented the drat standards? I'm trying to dig = into what we need to fix. =0A= =0A= http://www.webrtc.org/interop =0A= =0A= That's probably out of date=2C but you get the idea. =0A= _______________________________________________ =0A= rtcweb mailing list =0A= rtcweb@ietf.org =0A= https://www.ietf.org/mailman/listinfo/rtcweb =0A= =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb = --_851b3757-e20a-42c8-aca4-61e639ac25cc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From what I could tell=2C most o= f the interop issues addressed in the most recent sample app were not SDP-r= elated=2C but dealt with differences in API implementations=2C quite a few = of which should be expected to disappear when the API spec is finalized.&nb= sp=3B

Of course=2C the sample app is not attempting to address lega= cy interop=2C which is where I am expecting the narliest interop issues to = arise (particularly video). =3B And as we get more WebRTC browser imple= mentations=2C the amount of interop code will undoubtedly grow. =3B
Fro= m: juberti@google.com
Date: Wed=2C 1 May 2013 08:43:44 -0700
To: mart= in.thomson@gmail.com
CC: fluffy@cisco.com=3B rtcweb@ietf.org
Subject:= Re: [rtcweb] My SDP doesn't interoperate

The one S= DP issue mentioned in that document has been fixed=3B that document is now = outdated by events.

Regarding the "100 lines"=2C that co= de promoted Opus to be the preferred codec=2C as well as disabling CN. This= munging is also no longer needed=3B we have now added support for the Voic= eActivityDetection constraint to control use of CN.
=0A= =0A=


O= n Fri=2C Apr 26=2C 2013 at 12:00 PM=2C Martin Thomson <= =3Bmartin.tho= mson@gmail.com>=3B wrote:
=0A= =0A=
(was Re: [rtcweb] SDP Security Descriptions (RFC 4568)= and RTCWeb)
=0A=
=0A= On 26 April 2013 11:07=2C Cullen Jennings (fluffy) <=3Bfluffy@cisco.com>=3B wrote:
=0A= >=3B
=0A= >=3B On Apr 26=2C 2013=2C at 7:47 AM=2C Tim Panton <=3Btim@phonefromhere.com>=3B wrote:
=0A= >=3B
=0A= >=3B>=3B If anyone still thinks that SDP is just a blob not an API surf= ace=2C take a look at the 'reference implementation' of browser to browser = interop.
=0A= >=3B>=3B https://code.google.com/p/we= brtc-samples/source/browse/trunk/apprtc/index.html
=0A= >=3B>=3B
=0A= >=3B>=3B I count around 100 lines of javascript munging the SDP.
=0A= >=3B
=0A= >=3B Could you just summarize what the 100 lines do and which theses woul= d be needed for browsers that implemented the drat standards? I'm trying to= dig into what we need to fix.
=0A=
=0A= http://www.webr= tc.org/interop
=0A=
=0A= That's probably out of date=2C but you get the idea.
=0A= _______________________________________________
=0A= rtcweb mailing list
=0A= rtcweb@ietf.org
=0A= = https://www.ietf.org/mailman/listinfo/rtcweb
=0A=

=0A=
_______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb
= --_851b3757-e20a-42c8-aca4-61e639ac25cc_-- From karl.stahl@intertex.se Wed May 1 11:10:29 2013 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 611C821F9AB9 for ; Wed, 1 May 2013 11:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCEfF4JiMW4i for ; Wed, 1 May 2013 11:10:23 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 063A221F9918 for ; Wed, 1 May 2013 11:10:21 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id MXL30806; Wed, 01 May 2013 20:10:06 +0200 From: "Karl Stahl" To: "'Roy, Radhika R CIV USARMY \(US\)'" , "'Cullen Jennings \(fluffy\)'" , "'Harald Alvestrand'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> Date: Wed, 1 May 2013 20:10:06 +0200 Message-ID: <033701ce4697$1c545d20$54fd1760$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHORiot3hT0toA1x0SAjJDE87njG5jv9reggAA9LSCAAG1MQA== Content-Language: sv X-Spam-IndexStatus: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:10:29 -0000 Just to clarify: DTLS setup/key exchange goes over the UDP "voice/video channel". /Karl=20 -----Ursprungligt meddelande----- Fr=E5n: Roy, Radhika R CIV USARMY (US) = [mailto:radhika.r.roy.civ@mail.mil]=20 Skickat: den 1 maj 2013 13:47 Till: Karl Stahl; 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' Kopia: rtcweb@ietf.org =C4mne: RE: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Folks: I am responding only on a part of this email about retransmissions of = audio or video packets. Let us not consider the retransmission of audio or video packets. Let us consider audio or video packets are sent only over UDP. Let MOS/QoS of = audio or video are considered in a way that retransmissions do not take place. Then the question comes only about "data" traffic retransmissions. Data traffic can tolerate much higher delays than that of audio or video. = Data has only QoS (and no MOS). Let us divide the performance problems in two different parts. In this case, we can have more focused solutions related to = (Audio/Video) MOS/QoS or (Data) QoS as explained above. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Karl Stahl Sent: Wednesday, May 01, 2013 7:12 AM To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb Regarding delays... Today, packets over the Internet reach any point on the earth within 250 = ms as Cullen found - There are simply nowhere packet are stored/buffered in = any amount to give higher delays (Where would Gbps be stored for a second?). Routers drop packets at congestion, they don't store them (and light = takes 140 ms for a turn around the earth, somewhat slower in a fiber). So, the problem with voice/video quality (if overall bandwidth for the RTP/UDP is sufficient and up) is only dropped packets, which "only" = happens at congestion points where the pipe gets filled by TCP data (surf, = email, file transfer), when TCP end-points regulate down to share the pipe in = their hunger for infinite transfer speed. Then both TCP and RTP/UPD packets = are dropped as a consequence of intense TCP-flows initiation. (The static situation is ok - no packets are dropped) Second long packet delays must come from retransmission of lost packets. = If DTLS, it must be a higher level retransmission, I believe.=20 Questions: 1) Does DTLS take long time to set up in itself in the browser (Aren't = self signed certificate generated and exchanged?) while SRTP/DES is less CPU intense with ready certificate over the signaling path (I think)? But is this significant on let's say a 1 GHz smartphone which would be the = lowest CPU power to consider? 2) Are packet drops during TLS-setup more likely over the UDP channel between browsers (as for DTLS) than over the signaling channel (for SRTP/DES). And are there more packets that safely need to arrive with = DTLS setup? 3) SRTP/DES setup rely on TCP retransmission if packets are lost = (correct me if I am wrong), while DTLS must rely on some other higher level retransmission mechanisms. Are there longer timers involved then? I = think this may be the real explanation for reports of slow DTLS setup, isn't = it? The only cure against dropped UPD packets is IP-level QoS, such as = traffic shaping in firewalls/routers (but they need to be aware of traffic type) = and diffserv or reservation over the transport network- but that is = (currently) not enabled over the Internet, where all traffic is best effort class. /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Cullen Jennings (fluffy) Skickat: den 1 maj 2013 07:10 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C4mne: [rtcweb] Network times =85 was SDP Security Descriptions (RFC = 4568) and RTCWeb On Apr 29, 2013, at 2:29 AM, Harald Alvestrand = wrote: > Would it be possible to get real data on 1) and 2) here, so that we=20 > can stop talking about "slow" and instead talk about "N milliseconds"? >=20 I did try and round up a bunch of data for ping times from India to Singapore as some people were suggesting these were 1500ms.=20 I got measurements from both home DSL and more business class from a = range of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than = 250 ms one way. If someone has an actually link that is getting 1500 ms out = of India, I'd love to get the info so I can see what I can learn (the = buffer bloat folks want to hear about this :-) Classification: UNCLASSIFIED Caveats: NONE From karl.stahl@intertex.se Wed May 1 11:13:54 2013 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 DD72B21F99B6 for ; Wed, 1 May 2013 11:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoSxPPx28dYc for ; Wed, 1 May 2013 11:13:50 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD9921F9735 for ; Wed, 1 May 2013 11:13:49 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id MXO63634; Wed, 01 May 2013 20:13:34 +0200 From: "Karl Stahl" To: "'Justin Uberti'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Wed, 1 May 2013 20:13:34 +0200 Message-ID: <033801ce4697$988126d0$c9837470$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0339_01CE46A8.5C09F6D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5GhS7LbCaBsqoGQXuoFMNzAOVJVwAEfv2g Content-Language: sv X-Spam-IndexStatus: 0 Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:13:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0339_01CE46A8.5C09F6D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RTT is round trip time, isn=E2=80=99t it? Our 250 ms was just one way = =E2=80=93 so same finding. =20 Satellite links do certainly add lots of delay =E2=80=93 speed of light = again. =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 1 maj 2013 18:01 Till: Karl Stahl Kopia: Cullen Jennings (fluffy); Harald Alvestrand; rtcweb@ietf.org =C3=84mne: Re: [rtcweb] Network times . was SDP Security Descriptions = (RFC 4568) and RTCWeb =20 This doesn't match what we are seeing. I pulled some Chrome stats on = average RTT seen across various network connections; on 3G, close to = half of users had RTTs > 250 ms. 4G is somewhat better. 2G is = considerably worse. =20 India continues to be especially bad, partially because of the above, = partially because of use of satellite links, which due to physics incur = 500 ms RTTs. =20 On Wed, May 1, 2013 at 4:12 AM, Karl Stahl = wrote: Regarding delays... Today, packets over the Internet reach any point on the earth within 250 = ms as Cullen found - There are simply nowhere packet are stored/buffered in = any amount to give higher delays (Where would Gbps be stored for a second?). Routers drop packets at congestion, they don't store them (and light = takes 140 ms for a turn around the earth, somewhat slower in a fiber). So, the problem with voice/video quality (if overall bandwidth for the RTP/UDP is sufficient and up) is only dropped packets, which "only" = happens at congestion points where the pipe gets filled by TCP data (surf, = email, file transfer), when TCP end-points regulate down to share the pipe in = their hunger for infinite transfer speed. Then both TCP and RTP/UPD packets = are dropped as a consequence of intense TCP-flows initiation. (The static situation is ok - no packets are dropped) Second long packet delays must come from retransmission of lost packets. = If DTLS, it must be a higher level retransmission, I believe. Questions: 1) Does DTLS take long time to set up in itself in the browser (Aren't = self signed certificate generated and exchanged?) while SRTP/DES is less CPU intense with ready certificate over the signaling path (I think)? But is this significant on let's say a 1 GHz smartphone which would be the = lowest CPU power to consider? 2) Are packet drops during TLS-setup more likely over the UDP channel between browsers (as for DTLS) than over the signaling channel (for SRTP/DES). And are there more packets that safely need to arrive with = DTLS setup? 3) SRTP/DES setup rely on TCP retransmission if packets are lost = (correct me if I am wrong), while DTLS must rely on some other higher level retransmission mechanisms. Are there longer timers involved then? I = think this may be the real explanation for reports of slow DTLS setup, isn't = it? The only cure against dropped UPD packets is IP-level QoS, such as = traffic shaping in firewalls/routers (but they need to be aware of traffic type) = and diffserv or reservation over the transport network- but that is = (currently) not enabled over the Internet, where all traffic is best effort class. /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] = F=C3=B6r Cullen Jennings (fluffy) Skickat: den 1 maj 2013 07:10 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C3=84mne: [rtcweb] Network times =E2=80=A6 was SDP Security = Descriptions (RFC 4568) and RTCWeb On Apr 29, 2013, at 2:29 AM, Harald Alvestrand = wrote: > Would it be possible to get real data on 1) and 2) here, so that we = can stop talking about "slow" and instead talk about "N milliseconds"? > I did try and round up a bunch of data for ping times from India to Singapore as some people were suggesting these were 1500ms. I got measurements from both home DSL and more business class from a = range of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than = 250 ms one way. If someone has an actually link that is getting 1500 ms out = of India, I'd love to get the info so I can see what I can learn (the = buffer bloat folks want to hear about this :-) _______________________________________________ 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 =20 ------=_NextPart_000_0339_01CE46A8.5C09F6D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

RT= T is round trip time, isn=E2=80=99t it? Our 250 ms was just one way = =E2=80=93 so same finding.

 

Sa= tellite links do certainly add lots of delay =E2=80=93 speed of light = again.

 

/K= arl

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 1 maj 2013 = 18:01
Till: Karl Stahl
Kopia: Cullen Jennings = (fluffy); Harald Alvestrand; rtcweb@ietf.org
=C3=84mne: Re: = [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and = RTCWeb

 

This = doesn't match what we are seeing. I pulled some Chrome stats on average = RTT seen across various network connections; on 3G, close to half of = users had RTTs > 250 ms. 4G is somewhat better. 2G is considerably = worse.

 

India continues to be especially bad, partially = because of the above, partially because of use of satellite links, which = due to physics incur 500 ms RTTs.

 

On Wed, May 1, 2013 at 4:12 AM, Karl Stahl <karl.stahl@intertex.se> wrote:

Regarding delays...

Today, packets over the = Internet reach any point on the earth within 250 ms
as Cullen found - = There are simply nowhere packet are stored/buffered in any
amount to = give higher delays (Where would Gbps be stored for a = second?).
Routers drop packets at congestion, they don't store them = (and light takes
140 ms for a turn around the earth, somewhat slower = in a fiber).

So, the problem with voice/video quality (if overall = bandwidth for the
RTP/UDP is sufficient and up) is only dropped = packets, which "only" happens
at congestion points where = the pipe gets filled by TCP data (surf, email,
file transfer), when = TCP end-points regulate down to share the pipe in their
hunger for = infinite transfer speed. Then both TCP and RTP/UPD packets = are
dropped as a consequence of intense TCP-flows initiation. (The = static
situation is ok - no packets are dropped)

Second long = packet delays must come from retransmission of lost packets. If
DTLS, = it must be a higher level retransmission, I = believe.

Questions:

1) Does DTLS take long time to set up = in itself in the browser (Aren't self
signed certificate generated = and exchanged?) while SRTP/DES is less CPU
intense with ready = certificate over the signaling path (I think)? But is
this = significant on let's say a 1 GHz smartphone which would be the = lowest
CPU power to consider?

2) Are packet drops during = TLS-setup more likely over the UDP channel
between browsers (as for = DTLS) than over the signaling channel (for
SRTP/DES). And are there = more packets that safely need to arrive with DTLS
setup?

3) = SRTP/DES setup rely on TCP retransmission if packets are lost (correct = me
if I am wrong), while DTLS must rely on some other higher = level
retransmission mechanisms. Are there longer timers involved = then? I think
this may be the real explanation for reports of slow = DTLS setup, isn't it?

The only cure against dropped UPD packets = is IP-level QoS, such as traffic
shaping in firewalls/routers (but = they need to be aware of traffic type) and
diffserv or reservation = over the transport network- but that is (currently)
not enabled over = the Internet, where all traffic is best effort = class.

/Karl



-----Ursprungligt = meddelande-----
Fr=C3=A5n: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] = F=C3=B6r Cullen
Jennings (fluffy)
Skickat: den 1 maj 2013 = 07:10
Till: Harald Alvestrand
Kopia: rtcweb@ietf.org
=C3=84mne: = [rtcweb] Network times =E2=80=A6 was SDP Security Descriptions (RFC = 4568) and
RTCWeb


On Apr 29, 2013, at 2:29 AM, Harald = Alvestrand <harald@alvestrand.no> = wrote:

> Would it be possible to get real data on 1) and 2) = here, so that we can
stop talking about "slow" and instead = talk about "N milliseconds"?
>

I did try and = round up a bunch of data for ping times from India to
Singapore as = some people were suggesting these were 1500ms.

I got measurements = from both home DSL and more business class from a range
of sources in = India. It seems that anywhere one could run video, you can
ping any = of Singapore, Tokyo, Boston, Palo Alto, and London in less than = 250
ms one way. If someone has an actually link that is getting 1500 = ms out of
India, I'd love to get the info so I can see what I can = learn (the buffer
bloat folks want to hear about this = :-)






__________________________________________= _____
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

 

------=_NextPart_000_0339_01CE46A8.5C09F6D0-- From randell-ietf@jesup.org Wed May 1 11:18:38 2013 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 D3C3E21F98E5 for ; Wed, 1 May 2013 11:18:38 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23KkK8NNg3hN for ; Wed, 1 May 2013 11:18:33 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EC5AC21F98E8 for ; Wed, 1 May 2013 11:18:32 -0700 (PDT) Received: from [216.239.55.195] (port=58001 helo=[192.168.48.35]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXbbs-000A7N-80 for rtcweb@ietf.org; Wed, 01 May 2013 13:18:32 -0500 Message-ID: <51815C78.4010403@jesup.org> Date: Wed, 01 May 2013 11:18:32 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:18:39 -0000 On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote: > I am responding only on a part of this email about retransmissions of audio > or video packets. > > Let us not consider the retransmission of audio or video packets. Let us > consider audio or video packets are sent only over UDP. Let MOS/QoS of audio > or video are considered in a way that retransmissions do not take place. > > Then the question comes only about "data" traffic retransmissions. Data > traffic can tolerate much higher delays than that of audio or video. Data > has only QoS (and no MOS). It may not have MOS per-se, but unreliable data channels have equivalent issues - think of a first-person realtime game - unreliable position/state updates of the user and the world mean that what data is lost (and how much data is delayed but received) has a very strong impact on the user's perception of the world. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Wed May 1 11:30:33 2013 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 7182821F9AEB for ; Wed, 1 May 2013 11:30:33 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uluKsiHQc6K for ; Wed, 1 May 2013 11:30:27 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A124621F9AE6 for ; Wed, 1 May 2013 11:30:27 -0700 (PDT) Received: from [216.239.55.195] (port=59361 helo=[192.168.48.35]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXbnP-000DXv-6c for rtcweb@ietf.org; Wed, 01 May 2013 13:30:27 -0500 Message-ID: <51815F43.7090505@jesup.org> Date: Wed, 01 May 2013 11:30:27 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:30:33 -0000 On 5/1/2013 9:01 AM, Justin Uberti wrote: > This doesn't match what we are seeing. I pulled some Chrome stats on > average RTT seen across various network connections; on 3G, close to > half of users had RTTs > 250 ms. 4G is somewhat better. 2G is > considerably worse. > > India continues to be especially bad, partially because of the above, > partially because of use of satellite links, which due to physics > incur 500 ms RTTs. Those are all RTT measurements, so One Way Delay's of roughly half of that? speed-of-light for a one-way satellite link would be around 280ms in theory - and of course that's just for that one physical link. -- Randell Jesup randell-ietf@jesup.org From radhika.r.roy.civ@mail.mil Wed May 1 12:03:03 2013 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 E205921F9B67 for ; Wed, 1 May 2013 12:03:03 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5-UwAL16Tij for ; Wed, 1 May 2013 12:02:57 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCDC21F9885 for ; Wed, 1 May 2013 12:02:31 -0700 (PDT) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 1 May 2013 19:02:23 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.82]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.03.0123.003; Wed, 1 May 2013 19:02:23 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) Thread-Index: AQHORiot3hT0toA1x0SAjJDE87njG5jv9reggAA9LSCAAHBaAIAAC5Hg Date: Wed, 1 May 2013 19:02:22 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <51815C78.4010403@jesup.org> In-Reply-To: <51815C78.4010403@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0049_01CE467C.E0D57E60" MIME-Version: 1.0 Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:03:04 -0000 ------=_NextPart_000_0049_01CE467C.E0D57E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Inline [RRR] -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup Sent: Wednesday, May 01, 2013 2:19 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote: > I am responding only on a part of this email about retransmissions of > audio or video packets. > > Let us not consider the retransmission of audio or video packets. Let > us consider audio or video packets are sent only over UDP. Let MOS/QoS > of audio or video are considered in a way that retransmissions do not take place. > > Then the question comes only about "data" traffic retransmissions. > Data traffic can tolerate much higher delays than that of audio or > video. Data has only QoS (and no MOS). It may not have MOS per-se, but unreliable data channels have equivalent issues - think of a first-person realtime game - unreliable position/state updates of the user and the world mean that what data is lost (and how much data is delayed but received) has a very strong impact on the user's perception of the world. [RRR] Yes, we need to have NEW threshold of delays (RTT) for data performance. -- Randell Jesup randell-ietf@jesup.org Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0049_01CE467C.E0D57E60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA1MDExOTAyMjBaMCMGCSqGSIb3DQEJBDEWBBQ3swAo8S2SGjb4cyiS2uJ8 T+vSsDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBADLqWMhF/U9SGYv9D3pN4/h9Rx8CnL87bIIbBfL4CjxKuq2pTucQhNziTUyvcQrnFclC A3zwetT6PG6oCR7wwVB5f2W+3nxjxDonV7PP60mugyACYBORG9O0eJinsh/ODB+R3nnAoImpiksP O2lMCboL2qCZRwhucbqMLM/Wu+HvC+UA/Ai6Z/yhxWLVC/RdKw8yJa0LqRHCgEv+MNSjNgq9zcGQ MKy/j+hZSbxBOzXyYadKrQ31tSwbuxVMPsZlyacRCJWV6gSdsHwQPhnYcmyryObbFeznWZl8DkD1 fCW0LuYdq9IgquQo0CZ5JRTKlCiwd4UWs2FUg3u7/zcojZEAAAAAAAA= ------=_NextPart_000_0049_01CE467C.E0D57E60-- From juberti@google.com Wed May 1 13:36:03 2013 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 E63A121F9ACD for ; Wed, 1 May 2013 13:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9PdJUhy-9LL for ; Wed, 1 May 2013 13:36:03 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B7DA221F97E0 for ; Wed, 1 May 2013 13:36:00 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id d42so881630qca.1 for ; Wed, 01 May 2013 13:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UKIchlXOxHd1Dt68BC+bdJgtcOa674gZVIeTAUQumK0=; b=UcUQM34Qw8N7HJ540lndsEf9SQOqFJzNvrOZGgr+f9KCmyw0A5bKb1l9jvFx41wrr3 x9MdkmePN1eTnXwTrCFdGEuhPselc2sBmpkeUdBJ52vpy1YE8rIkW6b40dInY68G5O14 /B0vhFWCsNPBu9RIT2aDUm/Z6pllbxQi49fmFfynZaHIKnHVVzvHSUf/gepLiq1E8lWV wrv4HF9p3xZjUfmjTcyOvk9HSqN6yxuyXik9zOZ4+NZ+i97Myzl/JL96uzCB/Bf8Kg1L RGM+EcOkjN+GrQU89O+ITZmt8pgyaIAwlhV0VOx+f8gMP/FSPMqcx8N6VeJGMt1MLCXr QZwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=UKIchlXOxHd1Dt68BC+bdJgtcOa674gZVIeTAUQumK0=; b=lXjbol1tyz++/7CCAxTeaDcoEhh2gq8PnZTj2V7f4zUJnJXlsk8dGxeOt4eElJc3V5 09Si4ekwACRSZYDEbPIbVywzkyCkG4RZq0sDhRm/5j6HVUuN0kmAZh6ocWyhjF2bBVIB EUPi6C7MfiP4H71cKEzqxkIiBvCjgbmwmQQMgyuvl69+Z/gZmbjP9m8bxZSgytCFI2n+ XaOxIUO9asUhSv60jlWvJD7Bhiccfv+VoN6YS/OyjgiF+W32KPZxdY989ptTOqmRSFu6 bHofsCZubweMeHVf4lkhtXoCjjbjfHsp1eHcMIKCzrLrs2BH42xc6cIWHx3qhP3f+6D0 9K2Q== X-Received: by 10.49.50.162 with SMTP id d2mr5182724qeo.17.1367440560161; Wed, 01 May 2013 13:36:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.28 with HTTP; Wed, 1 May 2013 13:35:40 -0700 (PDT) In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> From: Justin Uberti Date: Wed, 1 May 2013 13:35:40 -0700 Message-ID: To: "Roy, Radhika R CIV USARMY (US)" Content-Type: multipart/alternative; boundary=047d7bb05082d71da104dbae102d X-Gm-Message-State: ALoCoQlulauHb5ZW7iCfKeHBjDxvTannlemyJgrbU6iUidK8VNNVRYjputHfYC5pxwk2/laojjahWJnX0PvtxgHJPixNHrwrnTU6UDEf9jQ/w+Q+N+I25jlOLC849emicfH+Jk6RwP9t04RsnB1eIYY8ru2UgIzxEqfGqcgDyuFhXZ7I9GMW+wvkyZ9TuAFCdbQ+fBc1ALBo Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:36:04 -0000 --047d7bb05082d71da104dbae102d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are several scenarios where retransmission of video, and possibly audio, makes a lot of sense. If you have a low RTT to a server that can retransmit a packet for you, this is by far the most efficient way to repair a packet loss in a video stream. The same can also be true for audio, especially in a LAN scenario (e.g. AirPlay). This does not mean it's appropriate for every situation, but we need to provide retransmission as one of the tools to handle these situations. On Wed, May 1, 2013 at 4:46 AM, Roy, Radhika R CIV USARMY (US) < radhika.r.roy.civ@mail.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Folks: > > I am responding only on a part of this email about retransmissions of aud= io > or video packets. > > Let us not consider the retransmission of audio or video packets. Let us > consider audio or video packets are sent only over UDP. Let MOS/QoS of > audio > or video are considered in a way that retransmissions do not take place. > > Then the question comes only about "data" traffic retransmissions. Data > traffic can tolerate much higher delays than that of audio or video. Data > has only QoS (and no MOS). > > Let us divide the performance problems in two different parts. > > In this case, we can have more focused solutions related to (Audio/Video) > MOS/QoS or (Data) QoS as explained above. > > BR/Radhika > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of > Karl Stahl > Sent: Wednesday, May 01, 2013 7:12 AM > To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC > 4568) and RTCWeb > > Regarding delays... > > Today, packets over the Internet reach any point on the earth within 250 = ms > as Cullen found - There are simply nowhere packet are stored/buffered in > any > amount to give higher delays (Where would Gbps be stored for a second?). > Routers drop packets at congestion, they don't store them (and light take= s > 140 ms for a turn around the earth, somewhat slower in a fiber). > > So, the problem with voice/video quality (if overall bandwidth for the > RTP/UDP is sufficient and up) is only dropped packets, which "only" happe= ns > at congestion points where the pipe gets filled by TCP data (surf, email, > file transfer), when TCP end-points regulate down to share the pipe in > their > hunger for infinite transfer speed. Then both TCP and RTP/UPD packets are > dropped as a consequence of intense TCP-flows initiation. (The static > situation is ok - no packets are dropped) > > Second long packet delays must come from retransmission of lost packets. = If > DTLS, it must be a higher level retransmission, I believe. > > Questions: > > 1) Does DTLS take long time to set up in itself in the browser (Aren't se= lf > signed certificate generated and exchanged?) while SRTP/DES is less CPU > intense with ready certificate over the signaling path (I think)? But is > this significant on let's say a 1 GHz smartphone which would be the lowes= t > CPU power to consider? > > 2) Are packet drops during TLS-setup more likely over the UDP channel > between browsers (as for DTLS) than over the signaling channel (for > SRTP/DES). And are there more packets that safely need to arrive with DTL= S > setup? > > 3) SRTP/DES setup rely on TCP retransmission if packets are lost (correct > me > if I am wrong), while DTLS must rely on some other higher level > retransmission mechanisms. Are there longer timers involved then? I think > this may be the real explanation for reports of slow DTLS setup, isn't it= ? > > The only cure against dropped UPD packets is IP-level QoS, such as traffi= c > shaping in firewalls/routers (but they need to be aware of traffic type) > and > diffserv or reservation over the transport network- but that is (currentl= y) > not enabled over the Internet, where all traffic is best effort class. > > /Karl > > > > -----Ursprungligt meddelande----- > Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3= =B6r Cullen > Jennings (fluffy) > Skickat: den 1 maj 2013 07:10 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > =C3=84mne: [rtcweb] Network times =E2=80=A6 was SDP Security Descriptions= (RFC 4568) and > RTCWeb > > > On Apr 29, 2013, at 2:29 AM, Harald Alvestrand > wrote: > > > Would it be possible to get real data on 1) and 2) here, so that we > > can > stop talking about "slow" and instead talk about "N milliseconds"? > > > > I did try and round up a bunch of data for ping times from India to > Singapore as some people were suggesting these were 1500ms. > > I got measurements from both home DSL and more business class from a rang= e > of sources in India. It seems that anywhere one could run video, you can > ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than > 250 > ms one way. If someone has an actually link that is getting 1500 ms out o= f > India, I'd love to get the info so I can see what I can learn (the buffer > bloat folks want to hear about this :-) > > > > > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bb05082d71da104dbae102d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are several scenarios where retransmission of video,= and possibly audio, makes a lot of sense. If you have a low RTT to a serve= r that can retransmit a packet for you, this is by far the most efficient w= ay to repair a packet loss in a video stream.

The same can also be true for audio, especially in a LAN sce= nario (e.g. AirPlay).

This does not mean it&= #39;s appropriate for every situation, but we need to provide retransmissio= n as one of the tools to handle these situations.


On Wed,= May 1, 2013 at 4:46 AM, Roy, Radhika R CIV USARMY (US) &= lt;radhika.= r.roy.civ@mail.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE

Folks:

I am responding only on a part of this email about retransmissions of audio=
or video packets.

Let us not consider the retransmission of audio or video packets. Let us consider audio or video packets are sent only over UDP. Let MOS/QoS of audi= o
or video are considered in a way that retransmissions do not take place.
Then the question comes only about "data" traffic retransmissions= . Data
traffic can tolerate much higher delays than that of audio or video. Data has only QoS (and no MOS).

Let us divide the performance problems in two different parts.

In this case, we can have more focused solutions related to (Audio/Video) MOS/QoS or (Data) QoS as explained above.

BR/Radhika

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of
Karl Stahl
Sent: Wednesday, May 01, 2013 7:12 AM
To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand'
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb

Regarding delays...

Today, packets over the Internet reach any point on the earth within 250 ms=
as Cullen found - There are simply nowhere packet are stored/buffered in an= y
amount to give higher delays (Where would Gbps be stored for a second?). Routers drop packets at congestion, they don't store them (and light ta= kes
140 ms for a turn around the earth, somewhat slower in a fiber).

So, the problem with voice/video quality (if overall bandwidth for the
RTP/UDP is sufficient and up) is only dropped packets, which "only&quo= t; happens
at congestion points where the pipe gets filled by TCP data (surf, email, file transfer), when TCP end-points regulate down to share the pipe in thei= r
hunger for infinite transfer speed. Then both TCP and RTP/UPD packets are dropped as a consequence of intense TCP-flows initiation. (The static
situation is ok - no packets are dropped)

Second long packet delays must come from retransmission of lost packets. If=
DTLS, it must be a higher level retransmission, I believe.

Questions:

1) Does DTLS take long time to set up in itself in the browser (Aren't = self
signed certificate generated and exchanged?) while SRTP/DES is less CPU
intense with ready certificate over the signaling path (I think)? But is this significant on let's say a 1 GHz smartphone which would be the low= est
CPU power to consider?

2) Are packet drops during TLS-setup more likely over the UDP channel
between browsers (as for DTLS) than over the signaling channel (for
SRTP/DES). And are there more packets that safely need to arrive with DTLS<= br> setup?

3) SRTP/DES setup rely on TCP retransmission if packets are lost (correct m= e
if I am wrong), while DTLS must rely on some other higher level
retransmission mechanisms. Are there longer timers involved then? I think this may be the real explanation for reports of slow DTLS setup, isn't = it?

The only cure against dropped UPD packets is IP-level QoS, such as traffic<= br> shaping in firewalls/routers (but they need to be aware of traffic type) an= d
diffserv or reservation over the transport network- but that is (currently)=
not enabled over the Internet, where all traffic is best effort class.

/Karl



-----Ursprungligt meddelande-----
Fr=C3=A5n: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] F=C3=B6r Cullen
Jennings (fluffy)
Skickat: den 1 maj 2013 07:10
Till: Harald Alvestrand
Kopia: rtcweb@ietf.org
=C3=84mne: [rtcweb] Network times =E2=80=A6 was SDP Security Descriptions (= RFC 4568) and
RTCWeb


On Apr 29, 2013, at 2:29 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> Would it be possible to get real data on 1) and 2) here, so that we > can
stop talking about "slow" and instead talk about "N millisec= onds"?
>

I did try and round up a bunch of data for ping times from India to
Singapore as some people were suggesting these were 1500ms.

I got measurements from both home DSL and more business class from a range<= br> of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than 25= 0
ms one way. If someone has an actually link that is getting 1500 ms out of<= br> India, I'd love to get the info so I can see what I can learn (the buff= er
bloat folks want to hear about this :-)








Classification: UNCLASSIFIED
Caveats: NONE


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


--047d7bb05082d71da104dbae102d-- From karl.stahl@intertex.se Wed May 1 14:29:12 2013 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 A9F0321F899E for ; Wed, 1 May 2013 14:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv8rMC4Z0wVc for ; Wed, 1 May 2013 14:29:08 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B021F8648 for ; Wed, 1 May 2013 14:29:03 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id MAD48048; Wed, 01 May 2013 23:28:48 +0200 From: "Karl Stahl" To: "'Randell Jesup'" , References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815F43.709050 5@jesup.org> In-Reply-To: <51815F43.7090505@jesup.org> Date: Wed, 1 May 2013 23:28:48 +0200 Message-ID: <036401ce46b2$de8e6500$9bab2f00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5GmfquJx7HLAbSTySFsb3/wt5p+AAFHleg Content-Language: sv X-Spam-IndexStatus: 0 Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:29:12 -0000 Correct, a geostationary satellite link adds minimum 240 ms of delay. = That would add 500 ms roundtrip which is bad for RTC (i.e. two way communication). I would call it an Internet data-only access (which of course is fine for streaming video though, that is one way, and can retransmit using TCP and where a small extra delay doesn't matter). We should not confuse. RTC is two way, and more than 500 ms round trip = delay or so, must be considered "not an RTC Internet access". Narrow band access also adds delay. A 250 kbps 2G, 3G, or ADSL upstream takes 50 ms to get a 1.5 kbyte Ethernet packet through. With a few = packets queued up, your voice packet may get 200 ms added if not prioritized in = that queue (which it is not over best-effort Internet). So there are delays - and all accesses are not good enough for RTC. =20 Then we have packet loss is addition. There are tolerance in audio = packet loss (better with some codecs) and telephony 3.5 kHz voice is not hard = to be better than. But WebRTC in itself allows teleprecense HD quality! Do we need = loss-less RTP transfer to utilize that over data crowded Internet access? We = cannot retransmit due to delay - Only IP-QoS, level 3 traffic shaping in = congestion points and diffserv or reservation gives loss-less RTP. (A deviation from the DTLS delay question it started with, but interesting...) /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Randell Jesup Skickat: den 1 maj 2013 20:30 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb On 5/1/2013 9:01 AM, Justin Uberti wrote: > This doesn't match what we are seeing. I pulled some Chrome stats on=20 > average RTT seen across various network connections; on 3G, close to=20 > half of users had RTTs > 250 ms. 4G is somewhat better. 2G is=20 > considerably worse. > > India continues to be especially bad, partially because of the above,=20 > partially because of use of satellite links, which due to physics=20 > incur 500 ms RTTs. Those are all RTT measurements, so One Way Delay's of roughly half of = that? speed-of-light for a one-way satellite link would be around 280ms in = theory - and of course that's just for that one physical link. -- Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bo.burman@ericsson.com Thu May 2 01:18:40 2013 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 4024521F9943 for ; Thu, 2 May 2013 01:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGowXViUSgr2 for ; Thu, 2 May 2013 01:18:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40ABC21F9938 for ; Thu, 2 May 2013 01:18:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-22-5182215764df Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.AA.28165.75122815; Thu, 2 May 2013 10:18:31 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.138]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Thu, 2 May 2013 10:18:30 +0200 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) Thread-Index: AQHORmGTaplvTvopXk+1qJQquLiHHZjwgkgAgAAMPwCAAPyd8A== Date: Thu, 2 May 2013 08:18:29 +0000 Message-ID: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <51815C78.4010403@jesup.org> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW64YlOgweMOEYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMevYT5aCduGKub19LA2My/i7GDk5JARMJA7ceMMOYYtJXLi3 nq2LkYtDSOAwo8TvzuVQzmJGif7vdxlBqtgENCTm74CwRQTUJS4/vADUzcEhLJAlsfuWF0Q4 W+L8qc1MELaTxM5ty8AWsAioSPzo/cwMYvMK+Epc/zKDFWL+IQ6JnZM/sYLM4RQIknjzXgqk hlFAVuL+93ssIDazgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtRov1pAyNEvY7Egt2f2CBs bYllC19D7RWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBIb9wS2/dXcw njoncohRmoNFSZw3iasxUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjxb5ZxUaHl/2NZbS4 PPWAo+m3l5ImoXlMhtPKhbof1e65eI5TiDV38jOHFNsf/1mO7Q4/K9C9268v/bmGZvPvhAe/ 2W2/h0/5qHPhhZKl6uRzot8tA6O27NjNmsLTufSvW1SL65J9U1YZuNy1TxGVaje7t+nLHPfa o46TizaUlOuUKEjo7l6kxFKckWioxVxUnAgA628S+0kCAAA= Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:18:40 -0000 I agree that delay-limited retransmission can be an appropriate functionali= ty also for media. Definitely for video, but maybe also for audio. I expect= that actual loss and delay requirements will depend on how media (WebRTC) = is used in the specific application use case, making it hard to set one sin= gle delay requirement. For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a good st= art, especially since you can set a maximum feasible (re-)transmission dela= y limit on a per-call and per-media basis in the SDP? /Bo B > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Roy, Radhika R CIV USARMY (US) > Sent: den 1 maj 2013 21:02 > To: Randell Jesup; rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb (UNCLASSIFIED) >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Inline [RRR] >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Randell Jesup > Sent: Wednesday, May 01, 2013 2:19 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC > 4568) and RTCWeb (UNCLASSIFIED) >=20 > On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote: > > I am responding only on a part of this email about retransmissions of > > audio or video packets. > > > > Let us not consider the retransmission of audio or video packets. Let > > us consider audio or video packets are sent only over UDP. Let MOS/QoS > > of audio or video are considered in a way that retransmissions do not > > take > place. > > > > Then the question comes only about "data" traffic retransmissions. > > Data traffic can tolerate much higher delays than that of audio or > > video. Data has only QoS (and no MOS). >=20 > It may not have MOS per-se, but unreliable data channels have equivalent = issues - think of a first-person realtime game - > unreliable position/state updates of the user and the world mean that wha= t data is lost (and how much data is delayed > but received) has a very strong impact on the user's perception of the wo= rld. >=20 > [RRR] Yes, we need to have NEW threshold of delays (RTT) for data perform= ance. > -- > Randell Jesup > randell-ietf@jesup.org >=20 >=20 >=20 >=20 > Classification: UNCLASSIFIED > Caveats: NONE From karl.stahl@intertex.se Thu May 2 01:42:21 2013 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 B0FE421F9959 for ; Thu, 2 May 2013 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqRGT5W+eiRM for ; Thu, 2 May 2013 01:42:17 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8926521F9957 for ; Thu, 2 May 2013 01:42:15 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NNR80957; Thu, 02 May 2013 10:41:57 +0200 From: "Karl Stahl" To: "'Bo Burman'" , References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <51815C78.4010403@jesup.org> < 8486C8728176924BAF5BDB 2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil> In-Reply-To: Date: Thu, 2 May 2013 10:41:56 +0200 Message-ID: <03f001ce4710$e79e1970$b6da4c50$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHORmGTaplvTvopXk+1qJQquLiHHZjwgkgAgAAMPwCAAPyd8IAACDrA Content-Language: sv X-Spam-IndexStatus: 0 Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:42:21 -0000 If we discuss two-way communication as with RTC, retransmission of media = is not a way forward! We are already at around 500 ms round trip delay, which is close to the tolerable limit for a conversation. If you are thinking of streaming one-way media, that can (and do) use = TCP since a few seconds delay is no problem. That is not RTC. /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Bo Burman Skickat: den 2 maj 2013 10:18 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb (UNCLASSIFIED) I agree that delay-limited retransmission can be an appropriate functionality also for media. Definitely for video, but maybe also for audio. I expect that actual loss and delay requirements will depend on = how media (WebRTC) is used in the specific application use case, making it = hard to set one single delay requirement. For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a good start, especially since you can set a maximum feasible (re-)transmission delay limit on a per-call and per-media basis in the SDP? /Bo B > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Roy, Radhika R CIV USARMY (US) > Sent: den 1 maj 2013 21:02 > To: Randell Jesup; rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20 > (RFC 4568) and RTCWeb (UNCLASSIFIED) >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Inline [RRR] >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Randell Jesup > Sent: Wednesday, May 01, 2013 2:19 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20 > (RFC > 4568) and RTCWeb (UNCLASSIFIED) >=20 > On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote: > > I am responding only on a part of this email about retransmissions=20 > > of audio or video packets. > > > > Let us not consider the retransmission of audio or video packets.=20 > > Let us consider audio or video packets are sent only over UDP. Let=20 > > MOS/QoS of audio or video are considered in a way that=20 > > retransmissions do not take > place. > > > > Then the question comes only about "data" traffic retransmissions. > > Data traffic can tolerate much higher delays than that of audio or=20 > > video. Data has only QoS (and no MOS). >=20 > It may not have MOS per-se, but unreliable data channels have=20 > equivalent issues - think of a first-person realtime game - unreliable = > position/state updates of the user and the world mean that what data = is lost (and how much data is delayed but received) has a very strong = impact on the user's perception of the world. >=20 > [RRR] Yes, we need to have NEW threshold of delays (RTT) for data performance. > -- > Randell Jesup > randell-ietf@jesup.org >=20 >=20 >=20 >=20 > Classification: UNCLASSIFIED > Caveats: NONE _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Thu May 2 01:45:28 2013 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 DD34F21F995A for ; Thu, 2 May 2013 01:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzEIJJYOHF30 for ; Thu, 2 May 2013 01:45:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0A21F9957 for ; Thu, 2 May 2013 01:45:27 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id 797D193C1AF; Thu, 2 May 2013 08:45:26 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <03f001ce4710$e79e1970$b6da4c50$@stahl@intertex.se> Date: Thu, 2 May 2013 10:45:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <51815C78.4010403@jesup.org> < 8486C8728176924BAF5BDB 2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil> <03f001ce4710$e79e1970$b6da4c50$@stahl@intertex.se> To: "Karl Stahl" X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:45:29 -0000 2 maj 2013 kl. 10:41 skrev "Karl Stahl" : > If we discuss two-way communication as with RTC, retransmission of = media is > not a way forward! When discussion retransmission of media you have to separate audio, video and other types of media. For audio, it doesn't really help. For = video it might prevent a full frame update request, which is a good thing. /O > We are already at around 500 ms round trip delay, which is close to = the > tolerable limit for a conversation. >=20 > If you are thinking of streaming one-way media, that can (and do) use = TCP > since a few seconds delay is no problem. That is not RTC. >=20 > /Karl >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Bo Burman > Skickat: den 2 maj 2013 10:18 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions = (RFC 4568) > and RTCWeb (UNCLASSIFIED) >=20 > I agree that delay-limited retransmission can be an appropriate > functionality also for media. Definitely for video, but maybe also for > audio. I expect that actual loss and delay requirements will depend on = how > media (WebRTC) is used in the specific application use case, making it = hard > to set one single delay requirement. >=20 > For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a = good > start, especially since you can set a maximum feasible = (re-)transmission > delay limit on a per-call and per-media basis in the SDP? >=20 > /Bo B >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Roy, Radhika R CIV USARMY (US) >> Sent: den 1 maj 2013 21:02 >> To: Randell Jesup; rtcweb@ietf.org >> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20= >> (RFC 4568) and RTCWeb (UNCLASSIFIED) >>=20 >> Classification: UNCLASSIFIED >> Caveats: NONE >>=20 >> Inline [RRR] >>=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Randell Jesup >> Sent: Wednesday, May 01, 2013 2:19 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20= >> (RFC >> 4568) and RTCWeb (UNCLASSIFIED) >>=20 >> On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote: >>> I am responding only on a part of this email about retransmissions=20= >>> of audio or video packets. >>>=20 >>> Let us not consider the retransmission of audio or video packets.=20 >>> Let us consider audio or video packets are sent only over UDP. Let=20= >>> MOS/QoS of audio or video are considered in a way that=20 >>> retransmissions do not take >> place. >>>=20 >>> Then the question comes only about "data" traffic retransmissions. >>> Data traffic can tolerate much higher delays than that of audio or=20= >>> video. Data has only QoS (and no MOS). >>=20 >> It may not have MOS per-se, but unreliable data channels have=20 >> equivalent issues - think of a first-person realtime game - = unreliable=20 >> position/state updates of the user and the world mean that what data = is > lost (and how much data is delayed but received) has a very strong = impact on > the user's perception of the world. >>=20 >> [RRR] Yes, we need to have NEW threshold of delays (RTT) for data > performance. >> -- >> Randell Jesup >> randell-ietf@jesup.org >>=20 >>=20 >>=20 >>=20 >> Classification: UNCLASSIFIED >> Caveats: NONE >=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 karl.stahl@intertex.se Thu May 2 01:57:01 2013 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 ED9B321F994D for ; Thu, 2 May 2013 01:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP1Ruc8Y2Y+X for ; Thu, 2 May 2013 01:56:57 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id CF88F21F9803 for ; Thu, 2 May 2013 01:56:20 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NNF06946; Thu, 02 May 2013 10:55:46 +0200 From: "Karl Stahl" To: "'Olle E. Johansson'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <51815C78.4010403@jesup.org> < 8486C8728176924BAF5B DB 2F7D7EEDDF49AC5D19@ucolhp9b.easf.csd.disa.mil> <03f001ce4710$e79e1970$b6da4c50$@stahl@intertex.se> In-Reply-To: Date: Thu, 2 May 2013 10:55:45 +0200 Message-ID: <040101ce4712$d54cd9d0$7fe68d70$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HEWS2pnNGeEL6RNCnOqyzJRyHJwAAT26g Content-Language: sv X-Spam-IndexStatus: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:57:02 -0000 -----Ursprungligt meddelande----- Fr=E5n: Olle E. Johansson [mailto:oej@edvina.net]=20 Skickat: den 2 maj 2013 10:45 Till: Karl Stahl Kopia: Olle E. Johansson; 'Bo Burman'; rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb (UNCLASSIFIED) 2 maj 2013 kl. 10:41 skrev "Karl Stahl" : > If we discuss two-way communication as with RTC, retransmission of=20 > media is not a way forward! When discussion retransmission of media you have to separate audio, = video and other types of media. For audio, it doesn't really help. For video = it might prevent a full frame update request, which is a good thing. [KS] Having video out of sync with voice, a bit later you mean? /O > We are already at around 500 ms round trip delay, which is close to=20 > the tolerable limit for a conversation. >=20 > If you are thinking of streaming one-way media, that can (and do) use=20 > TCP since a few seconds delay is no problem. That is not RTC. >=20 > /Karl >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Bo=20 > Burman > Skickat: den 2 maj 2013 10:18 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions = (RFC=20 > 4568) and RTCWeb (UNCLASSIFIED) >=20 > I agree that delay-limited retransmission can be an appropriate=20 > functionality also for media. Definitely for video, but maybe also for = > audio. I expect that actual loss and delay requirements will depend on = > how media (WebRTC) is used in the specific application use case,=20 > making it hard to set one single delay requirement. >=20 > For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a=20 > good start, especially since you can set a maximum feasible=20 > (re-)transmission delay limit on a per-call and per-media basis in the SDP? >=20 > /Bo B >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Roy, Radhika R CIV USARMY (US) >> Sent: den 1 maj 2013 21:02 >> To: Randell Jesup; rtcweb@ietf.org >> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20 >> (RFC 4568) and RTCWeb (UNCLASSIFIED) >>=20 >> Classification: UNCLASSIFIED >> Caveats: NONE >>=20 >> Inline [RRR] >>=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Randell Jesup >> Sent: Wednesday, May 01, 2013 2:19 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20 >> (RFC >> 4568) and RTCWeb (UNCLASSIFIED) >>=20 >> On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote: >>> I am responding only on a part of this email about retransmissions=20 >>> of audio or video packets. >>>=20 >>> Let us not consider the retransmission of audio or video packets.=20 >>> Let us consider audio or video packets are sent only over UDP. Let=20 >>> MOS/QoS of audio or video are considered in a way that=20 >>> retransmissions do not take >> place. >>>=20 >>> Then the question comes only about "data" traffic retransmissions. >>> Data traffic can tolerate much higher delays than that of audio or=20 >>> video. Data has only QoS (and no MOS). >>=20 >> It may not have MOS per-se, but unreliable data channels have=20 >> equivalent issues - think of a first-person realtime game -=20 >> unreliable position/state updates of the user and the world mean that = >> what data is > lost (and how much data is delayed but received) has a very strong=20 > impact on the user's perception of the world. >>=20 >> [RRR] Yes, we need to have NEW threshold of delays (RTT) for data > performance. >> -- >> Randell Jesup >> randell-ietf@jesup.org >>=20 >>=20 >>=20 >>=20 >> Classification: UNCLASSIFIED >> Caveats: NONE >=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 miconda@gmail.com Thu May 2 02:42:51 2013 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 5235621F9957 for ; Thu, 2 May 2013 02:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PralVo2W7xtT for ; Thu, 2 May 2013 02:42:49 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A65B921F992E for ; Thu, 2 May 2013 02:42:36 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id d10so168195eaj.18 for ; Thu, 02 May 2013 02:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=25+y/NOmkbwG7rKd3Nn4JBnUDRk2aa8NgLf3UdaKd3k=; b=TUBVSNTOeqHRnFdULtG7rK/xC+lMS+xCJRFxOCZTj0WSX8rKbEq1hp9+g+sbldo4Bu fFIhQ43RVRe3c05D2yK+KxVo2gXSS+G/QAfSkjfhdS8RpFiBzCmtF67oVDpQfWw6ZfKg f4KSsseJp5y+epaLeQDqvnhEQS9lH3AhnLl5q0S9weTiuu8Kh8OtQoK/FHtUbDsheFlN zXD1rOCQZqGtigpNt9RT7XngsbCbRTNgiyxMOrd8HduMX07l520BXZm2JmgZwryuKz2W 0l2TrWEaVZH9J0Cj2Qw9qLhyCCxj0gmymrfhy95r58t8vv24zDn78CaRjkX7Eql0gZ5x DMQQ== X-Received: by 10.14.111.5 with SMTP id v5mr4714386eeg.27.1367487755719; Thu, 02 May 2013 02:42:35 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id bj12sm8509523eeb.8.2013.05.02.02.42.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 02:42:34 -0700 (PDT) Message-ID: <51823508.8090305@gmail.com> Date: Thu, 02 May 2013 11:42:32 +0200 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Karl Stahl , 'Justin Uberti' References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com > In-Reply-To: <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: multipart/alternative; boundary="------------040509050102010003090907" Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com 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 May 2013 09:42:51 -0000 This is a multi-part message in MIME format. --------------040509050102010003090907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/1/13 8:13 PM, Karl Stahl wrote: > > RTT is round trip time, isn't it? Our 250 ms was just one way -- so > same finding. > Were these measurements involving rtp relays, or just point to point transmissions? Considering the amount of symmetric nat firewalls, even with ICE, a relevant number of RTC sessions will require a public relay, TURN server or similar (unless everyone will be on IPv6 at the time of production WebRTC deployments, which seems to have a chance looking at some debates or issues/patents related to several WebRTC decisions :-) ). As a new technology cannot satisfy everyone, but if it does not work good enough for majority, it will end up in a series of patches that will complicate everything (remember sip-nat relation). It is easier to digest and sell improvements brought by future extensions (e.g., alternative session setup mechanism for better security) than specifications doing actually downgrades. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * --------------040509050102010003090907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/1/13 8:13 PM, Karl Stahl wrote:

RTT is round trip time, isn’t it? Our 250 ms was just one way – so same finding.

Were these measurements involving rtp relays, or just point to point transmissions?

Considering the amount of symmetric nat firewalls, even with ICE, a relevant number of RTC sessions will require a public relay, TURN server or similar (unless everyone will be on IPv6 at the time of production WebRTC deployments, which seems to have a chance looking at some debates or issues/patents related to several WebRTC decisions :-) ).

As a new technology cannot satisfy everyone, but if it does not work good enough for majority, it will end up in a series of patches that will complicate everything (remember sip-nat relation). It is easier to digest and sell improvements brought by future extensions (e.g., alternative session setup mechanism for better security) than specifications doing actually downgrades.

Cheers,
Daniel
-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
  * http://asipto.com/u/katu *
--------------040509050102010003090907-- From karl.stahl@intertex.se Thu May 2 05:10:32 2013 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 811A121F99B3 for ; Thu, 2 May 2013 05:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+B3sUDDDphz for ; Thu, 2 May 2013 05:10:28 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7203F21F99B2 for ; Thu, 2 May 2013 05:10:26 -0700 (PDT) Received: from ([79.136.100.83]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NRC44548; Thu, 02 May 2013 14:00:48 +0200 From: "Karl Stahl" To: , "'Justin Uberti'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com > <51823508.8090305@gm ail.com> In-Reply-To: <51823508.8090305@gmail.com> Date: Thu, 2 May 2013 14:00:50 +0200 Message-ID: <005101ce472c$b0d2ef30$1278cd90$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01CE473D.745BBF30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HGWCO3BNTEN6eQkuH5ONCf5bdxAAEcuhg Content-Language: sv X-Spam-IndexStatus: 0 Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:10:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0052_01CE473D.745BBF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rtp relays are fast routing devices that should not add even 1 ms to the delay.=20 At least our (Ingates) SBCs add no significant delay when carrying SIP media. =20 But if there is a TURN server on the other side of the earth, you can = get additional delays of course. =20 The 250 ms were Cullen=92s pings, not RTP measurements, but the delay = should be about the same. =20 /Karl =20 Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 Skickat: den 2 maj 2013 11:43 Till: Karl Stahl; 'Justin Uberti' Kopia: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb =20 =20 On 5/1/13 8:13 PM, Karl Stahl wrote: RTT is round trip time, isn=92t it? Our 250 ms was just one way =96 so = same finding. Were these measurements involving rtp relays, or just point to point transmissions? Considering the amount of symmetric nat firewalls, even with ICE, a = relevant number of RTC sessions will require a public relay, TURN server or = similar (unless everyone will be on IPv6 at the time of production WebRTC deployments, which seems to have a chance looking at some debates or issues/patents related to several WebRTC decisions :-) ). As a new technology cannot satisfy everyone, but if it does not work = good enough for majority, it will end up in a series of patches that will complicate everything (remember sip-nat relation). It is easier to = digest and sell improvements brought by future extensions (e.g., alternative session setup mechanism for better security) than specifications doing actually downgrades. Cheers, Daniel --=20 Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * ------=_NextPart_000_0052_01CE473D.745BBF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Rt= p relays are fast routing devices that should not add even 1 ms to the = delay.

At= least our (Ingates) SBCs add no significant delay when carrying SIP = media.

 

Bu= t if there is a TURN server on the other side of the earth, you can get = additional delays of course.

 

Th= e 250 ms were Cullen’s pings, not RTP measurements, but the delay = should be about the same.

 

/K= arl

 

Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com] =
Skickat: den 2 maj 2013 11:43
Till: Karl Stahl; = 'Justin Uberti'
Kopia: 'Cullen Jennings (fluffy)'; = rtcweb@ietf.org
=C4mne: Re: [rtcweb] Network times . was SDP = Security Descriptions (RFC 4568) and = RTCWeb

 

 

On = 5/1/13 8:13 PM, Karl Stahl wrote:

RT= T is round trip time, isn’t it? Our 250 ms was just one way = – so same finding.

Were these measurements involving rtp relays, or just = point to point transmissions?

Considering the amount of symmetric = nat firewalls, even with ICE, a relevant number of RTC sessions will = require a public relay, TURN server or similar (unless everyone will be = on IPv6 at the time of production WebRTC deployments, which seems to = have a chance looking at some debates or issues/patents related to = several WebRTC decisions :-) ).

As a new technology cannot = satisfy everyone, but if it does not work good enough for majority, it = will end up in a series of patches that will complicate everything = (remember sip-nat relation). It is easier to digest and sell = improvements brought by future extensions (e.g., alternative session = setup mechanism for better security) than specifications doing actually = downgrades.

Cheers,
Daniel

-- =

Daniel-Constantin Mierla - http://www.asipto.com
= 
http://twitter.com/#!/miconda =
- http://www.linkedin.com/in/mi=
conda
Kamailio Advanced Training, San =
Francisco, USA - June 24-27, 2013
=A0 * http://asipto.com/u/katu =
*
------=_NextPart_000_0052_01CE473D.745BBF30-- From karl.stahl@intertex.se Thu May 2 05:12:35 2013 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 0C51521F99DF for ; Thu, 2 May 2013 05:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ52xUKEFmyq for ; Thu, 2 May 2013 05:12:31 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4414321F99B3 for ; Thu, 2 May 2013 05:12:30 -0700 (PDT) Received: from ([79.136.100.83]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NRE81824; Thu, 02 May 2013 14:02:24 +0200 From: "Karl Stahl" To: , "'Justin Uberti'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com > <51823508.8090305@gm ail.com> In-Reply-To: <51823508.8090305@gmail.com> Date: Thu, 2 May 2013 14:02:27 +0200 Message-ID: <005601ce472c$ea41ff90$bec5feb0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01CE473D.ADCACF90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HGWCO3BNTEN6eQkuH5ONCf5bdxAAEcuhg Content-Language: sv X-Spam-IndexStatus: 0 Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:12:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0057_01CE473D.ADCACF90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rtp relays are fast routing devices that should not add even 1 ms to the delay.=20 At least our (Ingates) SBCs add no significant delay when carrying SIP media. =20 But if there is a TURN server on the other side of the earth, you can = get additional delays of course. =20 The 250 ms were Cullen=92s pings, not RTP measurements, but the delay = should be about the same. =20 /Karl =20 Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 Skickat: den 2 maj 2013 11:43 Till: Karl Stahl; 'Justin Uberti' Kopia: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb =20 =20 On 5/1/13 8:13 PM, Karl Stahl wrote: RTT is round trip time, isn=92t it? Our 250 ms was just one way =96 so = same finding. Were these measurements involving rtp relays, or just point to point transmissions? Considering the amount of symmetric nat firewalls, even with ICE, a = relevant number of RTC sessions will require a public relay, TURN server or = similar (unless everyone will be on IPv6 at the time of production WebRTC deployments, which seems to have a chance looking at some debates or issues/patents related to several WebRTC decisions :-) ). As a new technology cannot satisfy everyone, but if it does not work = good enough for majority, it will end up in a series of patches that will complicate everything (remember sip-nat relation). It is easier to = digest and sell improvements brought by future extensions (e.g., alternative session setup mechanism for better security) than specifications doing actually downgrades. Cheers, Daniel --=20 Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * ------=_NextPart_000_0057_01CE473D.ADCACF90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Rt= p relays are fast routing devices that should not add even 1 ms to the = delay.

At= least our (Ingates) SBCs add no significant delay when carrying SIP = media.

 

Bu= t if there is a TURN server on the other side of the earth, you can get = additional delays of course.

 

Th= e 250 ms were Cullen’s pings, not RTP measurements, but the delay = should be about the same.

 

/K= arl

 

Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com] =
Skickat: den 2 maj 2013 11:43
Till: Karl Stahl; = 'Justin Uberti'
Kopia: 'Cullen Jennings (fluffy)'; = rtcweb@ietf.org
=C4mne: Re: [rtcweb] Network times . was SDP = Security Descriptions (RFC 4568) and = RTCWeb

 

 

On = 5/1/13 8:13 PM, Karl Stahl wrote:

RT= T is round trip time, isn’t it? Our 250 ms was just one way = – so same finding.

Were these measurements involving rtp relays, or just = point to point transmissions?

Considering the amount of symmetric = nat firewalls, even with ICE, a relevant number of RTC sessions will = require a public relay, TURN server or similar (unless everyone will be = on IPv6 at the time of production WebRTC deployments, which seems to = have a chance looking at some debates or issues/patents related to = several WebRTC decisions :-) ).

As a new technology cannot = satisfy everyone, but if it does not work good enough for majority, it = will end up in a series of patches that will complicate everything = (remember sip-nat relation). It is easier to digest and sell = improvements brought by future extensions (e.g., alternative session = setup mechanism for better security) than specifications doing actually = downgrades.

Cheers,
Daniel

-- =

Daniel-Constantin Mierla - http://www.asipto.com
= 
http://twitter.com/#!/miconda =
- http://www.linkedin.com/in/mi=
conda
Kamailio Advanced Training, San =
Francisco, USA - June 24-27, 2013
=A0 * http://asipto.com/u/katu =
*
------=_NextPart_000_0057_01CE473D.ADCACF90-- From karl.stahl@intertex.se Thu May 2 05:14:00 2013 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 DFC4821F992E for ; Thu, 2 May 2013 05:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU3E9g7Y8QkY for ; Thu, 2 May 2013 05:13:56 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1B04121F9928 for ; Thu, 2 May 2013 05:13:54 -0700 (PDT) Received: from ([79.136.100.83]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NRF00037; Thu, 02 May 2013 14:03:37 +0200 From: "Karl Stahl" To: , "'Justin Uberti'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com > <51823508.8090305@gm ail.com> In-Reply-To: <51823508.8090305@gmail.com> Date: Thu, 2 May 2013 14:03:39 +0200 Message-ID: <006001ce472d$154a14c0$3fde3e40$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CE473D.D8D2E4C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HGWCO3BNTEN6eQkuH5ONCf5bdxAAEcuhg Content-Language: sv X-Spam-IndexStatus: 0 Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:14:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0061_01CE473D.D8D2E4C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rtp relays are fast routing devices that should not add even 1 ms to the delay.=20 At least our (Ingates) SBCs add no significant delay when carrying SIP media. =20 But if there is a TURN server on the other side of the earth, you can = get additional delays of course. =20 The 250 ms were Cullen=92s pings, not RTP measurements, but the delay = should be about the same. =20 /Karl =20 Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 Skickat: den 2 maj 2013 11:43 Till: Karl Stahl; 'Justin Uberti' Kopia: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb =20 =20 On 5/1/13 8:13 PM, Karl Stahl wrote: RTT is round trip time, isn=92t it? Our 250 ms was just one way =96 so = same finding. Were these measurements involving rtp relays, or just point to point transmissions? Considering the amount of symmetric nat firewalls, even with ICE, a = relevant number of RTC sessions will require a public relay, TURN server or = similar (unless everyone will be on IPv6 at the time of production WebRTC deployments, which seems to have a chance looking at some debates or issues/patents related to several WebRTC decisions :-) ). As a new technology cannot satisfy everyone, but if it does not work = good enough for majority, it will end up in a series of patches that will complicate everything (remember sip-nat relation). It is easier to = digest and sell improvements brought by future extensions (e.g., alternative session setup mechanism for better security) than specifications doing actually downgrades. Cheers, Daniel --=20 Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * ------=_NextPart_000_0061_01CE473D.D8D2E4C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Rt= p relays are fast routing devices that should not add even 1 ms to the = delay.

At= least our (Ingates) SBCs add no significant delay when carrying SIP = media.

 

Bu= t if there is a TURN server on the other side of the earth, you can get = additional delays of course.

 

Th= e 250 ms were Cullen’s pings, not RTP measurements, but the delay = should be about the same.

 

/K= arl

 

Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com] =
Skickat: den 2 maj 2013 11:43
Till: Karl Stahl; = 'Justin Uberti'
Kopia: 'Cullen Jennings (fluffy)'; = rtcweb@ietf.org
=C4mne: Re: [rtcweb] Network times . was SDP = Security Descriptions (RFC 4568) and = RTCWeb

 

 

On = 5/1/13 8:13 PM, Karl Stahl wrote:

RT= T is round trip time, isn’t it? Our 250 ms was just one way = – so same finding.

Were these measurements involving rtp relays, or just = point to point transmissions?

Considering the amount of symmetric = nat firewalls, even with ICE, a relevant number of RTC sessions will = require a public relay, TURN server or similar (unless everyone will be = on IPv6 at the time of production WebRTC deployments, which seems to = have a chance looking at some debates or issues/patents related to = several WebRTC decisions :-) ).

As a new technology cannot = satisfy everyone, but if it does not work good enough for majority, it = will end up in a series of patches that will complicate everything = (remember sip-nat relation). It is easier to digest and sell = improvements brought by future extensions (e.g., alternative session = setup mechanism for better security) than specifications doing actually = downgrades.

Cheers,
Daniel

-- =

Daniel-Constantin Mierla - http://www.asipto.com
= 
http://twitter.com/#!/miconda =
- http://www.linkedin.com/in/mi=
conda
Kamailio Advanced Training, San =
Francisco, USA - June 24-27, 2013
=A0 * http://asipto.com/u/katu =
*
------=_NextPart_000_0061_01CE473D.D8D2E4C0-- From karl.stahl@intertex.se Thu May 2 05:55:16 2013 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 7E89B21F96C5 for ; Thu, 2 May 2013 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O8KmZ7B3pps for ; Thu, 2 May 2013 05:55:12 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id BADD121F9666 for ; Thu, 2 May 2013 05:55:10 -0700 (PDT) Received: from ([79.136.100.83]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NRW40551; Thu, 02 May 2013 14:46:51 +0200 From: "Karl Stahl" To: , "'Justin Uberti'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com > <51823508.8090305@gm ail.com> In-Reply-To: <51823508.8090305@gmail.com> Date: Thu, 2 May 2013 14:45:29 +0200 Message-ID: <00cc01ce4733$1ffa61d0$5fef2570$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01CE4743.E38331D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HGWCO3BNTEN6eQkuH5ONCf5bdxAAEcuhg Content-Language: sv X-Spam-IndexStatus: 0 Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:55:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01CE4743.E38331D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rtp relays are fast routing devices that should not add even 1 ms to the delay.=20 At least our (Ingates) SBCs add no significant delay when carrying SIP media. =20 But if there is a TURN server on the other side of the earth, you can = get additional delays of course. =20 The 250 ms were Cullen=92s pings, not RTP measurements, but the delay = should be about the same. =20 /Karl =20 Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 Skickat: den 2 maj 2013 11:43 Till: Karl Stahl; 'Justin Uberti' Kopia: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb =20 =20 On 5/1/13 8:13 PM, Karl Stahl wrote: RTT is round trip time, isn=92t it? Our 250 ms was just one way =96 so = same finding. Were these measurements involving rtp relays, or just point to point transmissions? Considering the amount of symmetric nat firewalls, even with ICE, a = relevant number of RTC sessions will require a public relay, TURN server or = similar (unless everyone will be on IPv6 at the time of production WebRTC deployments, which seems to have a chance looking at some debates or issues/patents related to several WebRTC decisions :-) ). As a new technology cannot satisfy everyone, but if it does not work = good enough for majority, it will end up in a series of patches that will complicate everything (remember sip-nat relation). It is easier to = digest and sell improvements brought by future extensions (e.g., alternative session setup mechanism for better security) than specifications doing actually downgrades. Cheers, Daniel --=20 Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * ------=_NextPart_000_00CD_01CE4743.E38331D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Rt= p relays are fast routing devices that should not add even 1 ms to the = delay.

At= least our (Ingates) SBCs add no significant delay when carrying SIP = media.

 

Bu= t if there is a TURN server on the other side of the earth, you can get = additional delays of course.

 

Th= e 250 ms were Cullen’s pings, not RTP measurements, but the delay = should be about the same.

 

/K= arl

 

Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com] =
Skickat: den 2 maj 2013 11:43
Till: Karl Stahl; = 'Justin Uberti'
Kopia: 'Cullen Jennings (fluffy)'; = rtcweb@ietf.org
=C4mne: Re: [rtcweb] Network times . was SDP = Security Descriptions (RFC 4568) and = RTCWeb

 

 

On = 5/1/13 8:13 PM, Karl Stahl wrote:

RT= T is round trip time, isn’t it? Our 250 ms was just one way = – so same finding.

Were these measurements involving rtp relays, or just = point to point transmissions?

Considering the amount of symmetric = nat firewalls, even with ICE, a relevant number of RTC sessions will = require a public relay, TURN server or similar (unless everyone will be = on IPv6 at the time of production WebRTC deployments, which seems to = have a chance looking at some debates or issues/patents related to = several WebRTC decisions :-) ).

As a new technology cannot = satisfy everyone, but if it does not work good enough for majority, it = will end up in a series of patches that will complicate everything = (remember sip-nat relation). It is easier to digest and sell = improvements brought by future extensions (e.g., alternative session = setup mechanism for better security) than specifications doing actually = downgrades.

Cheers,
Daniel

-- =

Daniel-Constantin Mierla - http://www.asipto.com
= 
http://twitter.com/#!/miconda =
- http://www.linkedin.com/in/mi=
conda
Kamailio Advanced Training, San =
Francisco, USA - June 24-27, 2013
=A0 * http://asipto.com/u/katu =
*
------=_NextPart_000_00CD_01CE4743.E38331D0-- From harald@alvestrand.no Thu May 2 06:54:27 2013 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 7482621F8AC2 for ; Thu, 2 May 2013 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT3As9I7rmqU for ; Thu, 2 May 2013 06:54:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2660421F89FF for ; Thu, 2 May 2013 06:54:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21ED339E127 for ; Thu, 2 May 2013 15:54:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oopfHA73T7I for ; Thu, 2 May 2013 15:54:17 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5A22C39E057 for ; Thu, 2 May 2013 15:54:17 +0200 (CEST) Message-ID: <51827008.4080901@alvestrand.no> Date: Thu, 02 May 2013 15:54:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------060809000002030206000509" Subject: [rtcweb] VP8: Sublicensing terms for the Google/MPEG-LA agreement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:54:27 -0000 This is a multi-part message in MIME format. --------------060809000002030206000509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This should be of interest to some people who've engaged in the codec discussions: http://www.webmproject.org/cross-license/ It includes Google's proposed terms for the royalty free sublicense of the IPR involved in the Google/MPEG-LA agreement, as well as the names of the licensors in that agreement. Harald --------------060809000002030206000509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This should be of interest to some people who've engaged in the codec discussions:

http://www.webmproject.org/cross-license/

It includes Google's proposed terms for the royalty free sublicense of the IPR involved in the Google/MPEG-LA agreement, as well as the names of the licensors in that agreement.

       Harald

--------------060809000002030206000509-- From harald@alvestrand.no Thu May 2 07:12:58 2013 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 6BCB021F8B9C for ; Thu, 2 May 2013 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+b7yb0DWLwu for ; Thu, 2 May 2013 07:12:53 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE921F8B3A for ; Thu, 2 May 2013 07:12:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13CE739E127; Thu, 2 May 2013 16:12:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h6COUO1NMWh; Thu, 2 May 2013 16:12:48 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7945D39E057; Thu, 2 May 2013 16:12:48 +0200 (CEST) Message-ID: <5182745F.4080508@alvestrand.no> Date: Thu, 02 May 2013 16:12:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Karl Stahl References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <033701ce4697$1c545d20$54fd1760$@stahl@intertex.se> In-Reply-To: <033701ce4697$1c545d20$54fd1760$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 14:12:58 -0000 On 05/01/2013 08:10 PM, Karl Stahl wrote: > Just to clarify: > DTLS setup/key exchange goes over the UDP "voice/video channel". Now you've gotten me confused. DTLS setup/key exchange goes via UDP packets. These UDP packets are not sent over RTP (but I do expect them to use the same source and destination port numbers as the RTP streams). I've always used "voice/video channel" (if I've ever used it) to mean RTP. > /Karl > > -----Ursprungligt meddelande----- > Från: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil] > Skickat: den 1 maj 2013 13:47 > Till: Karl Stahl; 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' > Kopia: rtcweb@ietf.org > Ämne: RE: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) > and RTCWeb (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > Folks: > > I am responding only on a part of this email about retransmissions of audio > or video packets. > > Let us not consider the retransmission of audio or video packets. Let us > consider audio or video packets are sent only over UDP. Let MOS/QoS of audio > or video are considered in a way that retransmissions do not take place. > > Then the question comes only about "data" traffic retransmissions. Data > traffic can tolerate much higher delays than that of audio or video. Data > has only QoS (and no MOS). > > Let us divide the performance problems in two different parts. > > In this case, we can have more focused solutions related to (Audio/Video) > MOS/QoS or (Data) QoS as explained above. > > BR/Radhika > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Karl Stahl > Sent: Wednesday, May 01, 2013 7:12 AM > To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC > 4568) and RTCWeb > > Regarding delays... > > Today, packets over the Internet reach any point on the earth within 250 ms > as Cullen found - There are simply nowhere packet are stored/buffered in any > amount to give higher delays (Where would Gbps be stored for a second?). > Routers drop packets at congestion, they don't store them (and light takes > 140 ms for a turn around the earth, somewhat slower in a fiber). > > So, the problem with voice/video quality (if overall bandwidth for the > RTP/UDP is sufficient and up) is only dropped packets, which "only" happens > at congestion points where the pipe gets filled by TCP data (surf, email, > file transfer), when TCP end-points regulate down to share the pipe in their > hunger for infinite transfer speed. Then both TCP and RTP/UPD packets are > dropped as a consequence of intense TCP-flows initiation. (The static > situation is ok - no packets are dropped) > > Second long packet delays must come from retransmission of lost packets. If > DTLS, it must be a higher level retransmission, I believe. > > Questions: > > 1) Does DTLS take long time to set up in itself in the browser (Aren't self > signed certificate generated and exchanged?) while SRTP/DES is less CPU > intense with ready certificate over the signaling path (I think)? But is > this significant on let's say a 1 GHz smartphone which would be the lowest > CPU power to consider? > > 2) Are packet drops during TLS-setup more likely over the UDP channel > between browsers (as for DTLS) than over the signaling channel (for > SRTP/DES). And are there more packets that safely need to arrive with DTLS > setup? > > 3) SRTP/DES setup rely on TCP retransmission if packets are lost (correct me > if I am wrong), while DTLS must rely on some other higher level > retransmission mechanisms. Are there longer timers involved then? I think > this may be the real explanation for reports of slow DTLS setup, isn't it? > > The only cure against dropped UPD packets is IP-level QoS, such as traffic > shaping in firewalls/routers (but they need to be aware of traffic type) and > diffserv or reservation over the transport network- but that is (currently) > not enabled over the Internet, where all traffic is best effort class. > > /Karl > > > > -----Ursprungligt meddelande----- > Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Cullen > Jennings (fluffy) > Skickat: den 1 maj 2013 07:10 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > Ämne: [rtcweb] Network times … was SDP Security Descriptions (RFC 4568) and > RTCWeb > > > On Apr 29, 2013, at 2:29 AM, Harald Alvestrand wrote: > >> Would it be possible to get real data on 1) and 2) here, so that we >> can > stop talking about "slow" and instead talk about "N milliseconds"? > I did try and round up a bunch of data for ping times from India to > Singapore as some people were suggesting these were 1500ms. > > I got measurements from both home DSL and more business class from a range > of sources in India. It seems that anywhere one could run video, you can > ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than 250 > ms one way. If someone has an actually link that is getting 1500 ms out of > India, I'd love to get the info so I can see what I can learn (the buffer > bloat folks want to hear about this :-) > > > > > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > From ekr@rtfm.com Thu May 2 07:30:51 2013 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 B64A821F8AA6 for ; Thu, 2 May 2013 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.701 X-Spam-Level: X-Spam-Status: No, score=-101.701 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui-WtQyF2DFY for ; Thu, 2 May 2013 07:30:46 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id CCFF221F8A08 for ; Thu, 2 May 2013 07:30:45 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id kw10so523616vcb.37 for ; Thu, 02 May 2013 07:30:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=SmmHrDeti+WppilxCZ6ICP+VuzfrKaZ4xpbj1b61wPM=; b=PWRCwlSPwoWjpcwrAvADZpl96bGU7LWVAR1WGQo8+hGsBVS2H8019+PWh3SJ/X/5Zp YY/Vf7VqD17GzvdoAE7hJhEQFJZYyk5Gex/lVP0nNZzgdsOOwH7cpTIBmljUlTrHiX/C UgPCDHhR4Ktd/EfHFiZj0Enwo2XhLoKIQlYsty5vqgnh1YHD7VajGQgWkMFGhTUaJRgt k6gWjLuu9isgkMhUvvxaiyrIV8FcY02TW0ck6sZTqPY4SfwuhNpaPJcWW8zoktFsCWIX iIHd7LLG7ay7RxT5pEbJwCFRCJ8c8eqAoU69wkkeyZdn4K1Z0P0SO2AmVmC+WImJKY3r +bzw== X-Received: by 10.52.170.204 with SMTP id ao12mr1909864vdc.83.1367505045161; Thu, 02 May 2013 07:30:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.161 with HTTP; Thu, 2 May 2013 07:30:05 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <5182745F.4080508@alvestrand.no> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <5182745F.4080508@alvestrand.no> From: Eric Rescorla Date: Thu, 2 May 2013 07:30:05 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b86f2da724a0a04dbbd144d X-Gm-Message-State: ALoCoQk17Wl0s6wwCUgD3bdgWL1U7hDGxNY29ex9yoQCakSkMH16P9yu2z+lWn6z5DXamu74J3Ic Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 14:30:51 -0000 --047d7b86f2da724a0a04dbbd144d Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 2, 2013 at 7:12 AM, Harald Alvestrand wrote: > On 05/01/2013 08:10 PM, Karl Stahl wrote: > >> Just to clarify: >> DTLS setup/key exchange goes over the UDP "voice/video channel". >> > > Now you've gotten me confused. > > DTLS setup/key exchange goes via UDP packets. > These UDP packets are not sent over RTP (but I do expect them to use the > same source and destination port numbers as the RTP streams). > > I've always used "voice/video channel" (if I've ever used it) to mean RTP. > Just for maximum clarity, DTLS records go over UDP datagrams on the same 5-tuple as the RTP and STUN packets (at least those corresponding to the eventual RTP channel). -Ekr --047d7b86f2da724a0a04dbbd144d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 2, 2013 at 7:12 AM, Harald Alvestrand <harald@alvestrand.no= > wrote:
On 05/01/2013 08:10 PM, Karl Stahl wrote:
Just to clarify:
DTLS setup/key exchange goes over the UDP "voice/video channel".<= br>

Now you've gotten me confused.

DTLS setup/key exchange goes via UDP packets.
These UDP packets are not sent over RTP (but I do expect them to use the sa= me source and destination port numbers as the RTP streams).

I've always used "voice/video channel" (if I've ever used= it) to mean RTP.

Just for maximum clar= ity, DTLS records go over UDP datagrams on the
same 5-tuple as th= e RTP and STUN packets (at least those corresponding
to the eventual RTP channel).

-Ekr
= =A0
--047d7b86f2da724a0a04dbbd144d-- From miconda@gmail.com Thu May 2 07:48:19 2013 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 77A4221F8A0B for ; Thu, 2 May 2013 07:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh3T0l0T9yXU for ; Thu, 2 May 2013 07:48:18 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8C621F89E2 for ; Thu, 2 May 2013 07:48:18 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a11so310422eae.12 for ; Thu, 02 May 2013 07:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=C7WeXNAyhlkLLurUBulUp6lWEsrotXzUouxRJjXZpy8=; b=zhrhgrBLFpM/Huw3p/xd+0vdXULMgzsA+nI7hrvmpPJ5avHDj6UoTXzZbzzztpHeEh rcom1zHZ+um36Uxj+BfuGeQBZyR81HRFUlvM+cLuWHHOLn0JreWjwojadWl0eldDpyQg GPuA9x7lIfIjQj8JLX6cLHawajM4wjxtRrixKmW5jxzoJ3ApLmEkSTQs1f+weLcAjcvG UFnZ/s5RXxlzAcX2OnFFG8qsP/USc2FHuV/O7TY0u/d9lQQu0skFbAboh9D1RGqdBORa q1gXh9svxuKwZkLVLw2OOOfl3g4n7u8khuUDhuuMOZpbrO4InhBBfW7CsTgIPRKXaO57 OTxQ== X-Received: by 10.15.41.2 with SMTP id r2mr20409881eev.23.1367506097410; Thu, 02 May 2013 07:48:17 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id k43sm10222499een.2.2013.05.02.07.48.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 07:48:16 -0700 (PDT) Message-ID: <51827CAD.3000600@gmail.com> Date: Thu, 02 May 2013 16:48:13 +0200 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Karl Stahl , 'Justin Uberti' References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com> <51823508.8090305@gm ail.com> <5182622e.2a78980a.697f.ffffb5e9SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <5182622e.2a78980a.697f.ffffb5e9SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: multipart/alternative; boundary="------------070400020306050906050502" Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com 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 May 2013 14:48:19 -0000 This is a multi-part message in MIME format. --------------070400020306050906050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/2/13 2:45 PM, Karl Stahl wrote: > > Rtp relays are fast routing devices that should not add even 1 ms to > the delay. > By the 'routing device' do you mean some hardware based packet forwarding (e.g, done in the ethernet card) or an application doing the forwarding in user space? > At least our (Ingates) SBCs add no significant delay when carrying SIP > media. > > But if there is a TURN server on the other side of the earth, you can > get additional delays of course. > The point I wanted to make was that any new technology should not be designed for ideal cases, also not for worst cases, but to satisfy the majority of the possible users. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * --------------070400020306050906050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/2/13 2:45 PM, Karl Stahl wrote:

Rtp relays are fast routing devices that should not add even 1 ms to the delay.


By the 'routing device' do you mean some hardware based packet forwarding (e.g, done in the ethernet card) or an application doing the forwarding in user space?

At least our (Ingates) SBCs add no significant delay when carrying SIP media.

 

But if there is a TURN server on the other side of the earth, you can get additional delays of course.

The point I wanted to make was that any new technology should not be designed for ideal cases, also not for worst cases, but to satisfy the majority of the possible users.

Daniel


-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
  * http://asipto.com/u/katu *
--------------070400020306050906050502-- From fluffy@iii.ca Thu May 2 09:41:35 2013 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 94C8921F90F3 for ; Thu, 2 May 2013 09:41:35 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yRZS5Mz+M7g for ; Thu, 2 May 2013 09:41:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9521F8FE8 for ; Thu, 2 May 2013 09:41:18 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D85C4509B8; Thu, 2 May 2013 12:41:17 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 2 May 2013 10:41:16 -0600 Message-Id: <9680955B-EC9D-4B9D-8416-06678A34335D@iii.ca> To: "rtcweb@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [rtcweb] Doodle Poll for RTCWeb Virtual Interim Time X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:41:35 -0000 We are trying to pick a time to have an Virtual Interim meeting for the = IETF RTCWeb WG on the topic of SDP Security Descriptions (RFC 4568 aka = SDES) Please fill out the poll at=20 http://doodle.com/7eu5ddsveb8dfber to indicate which times you can make. The proposed length of the meeting = is 3 hours.=20 Thanks, The Chairs=20 From mary.ietf.barnes@gmail.com Thu May 2 10:12:12 2013 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 50E1221F8FC6 for ; Thu, 2 May 2013 10:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ectT-bfMI0qG for ; Thu, 2 May 2013 10:12:11 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id AFF8021F8FA5 for ; Thu, 2 May 2013 10:12:11 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar20so912986iec.39 for ; Thu, 02 May 2013 10:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xj7AyHkFJGzY7sK+CiKVvSiKs/9wjTmElKslBNrdksM=; b=Si/IiFPjpKCzocTvl9EgUc5xm+987dQ33vaVkDTgv7Cpmd4KBkAMsmui1zQbickQh5 KVrpS4JzkDtgB46VzUxxULEaANcb6HzqtkXsKx/Hg3R7hu6rq+1KGOEjPDOvSZo7GkGl o0B0PdRFJ/Um3fN6tQNy7MbdN3DpZ3NPJKoMTpsKZ9JmsMacnZWq9PJDJUlhwjQsdkox PSFawhhp/fFfPb0Qm4RbIZG3aNQigNPpLv8pD+0bxSmNPn3LrgN53cDSajWHbgKtg5e4 TKSDBy04tLNc84ZPUp2NgqG3vYn2rsfejNy0gqbn8XPfEOxf6s8r4jpwL/4uvQoRwvVb 0bZw== MIME-Version: 1.0 X-Received: by 10.50.50.8 with SMTP id y8mr4207969ign.55.1367514731331; Thu, 02 May 2013 10:12:11 -0700 (PDT) Received: by 10.42.156.68 with HTTP; Thu, 2 May 2013 10:12:11 -0700 (PDT) In-Reply-To: <9680955B-EC9D-4B9D-8416-06678A34335D@iii.ca> References: <9680955B-EC9D-4B9D-8416-06678A34335D@iii.ca> Date: Thu, 2 May 2013 12:12:11 -0500 Message-ID: From: Mary Barnes To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle Poll for RTCWeb Virtual Interim Time X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:12:12 -0000 It would be nice if you could include the Maybe option in the poll. Some of us may be able to re-arrange schedules if the optimal time for others conflicts with something we already have scheduled. Thanks, Mary. On Thu, May 2, 2013 at 11:41 AM, Cullen Jennings wrote: > > We are trying to pick a time to have an Virtual Interim meeting for the IETF RTCWeb WG on the topic of SDP Security Descriptions (RFC 4568 aka SDES) > > Please fill out the poll at > > http://doodle.com/7eu5ddsveb8dfber > > to indicate which times you can make. The proposed length of the meeting is 3 hours. > > Thanks, The Chairs > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu May 2 10:17:57 2013 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 F41C921F8FD6 for ; Thu, 2 May 2013 10:17:56 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDep4dfGQDMO for ; Thu, 2 May 2013 10:17:56 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 517D121F8FB8 for ; Thu, 2 May 2013 10:17:56 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hq12so864210wib.3 for ; Thu, 02 May 2013 10:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jY2zDYuEKFH+R0TLVsq4Z1ObQ51uMMNTiCcDd+whBqA=; b=FNvK7Iu65b7SokSzGrF74GGT6+SwJMHm4R0o+qD7nXSbFPoJzkckOwwBtos3omHVj5 Zc5eBC5aFWYUQflMVOUyIV9hvfoZuwyZZPs7QNkfnvGlaVcCLLaGwNwN8VealkBZFuTY mtnPNX4gqswFILgqQXqEWFuhe3WUgYNftyQrZ3ASNte2KNURMX6LoCmmIW8TJW2eps8i 8f29Y2YMGBVuMZVAL/5A0a8J3ThqQL4EISPqlzi0t7AIQ0Bggvh90xLsPPSEzW7wYDHl sip/Td/DuKcClkxcgMfnnx8FlRo/WRtrGrGGEcLwyyOhSYNrakIbVRX+WHK7iR986ht4 9xDA== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr10723298wic.32.1367515075340; Thu, 02 May 2013 10:17:55 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 2 May 2013 10:17:55 -0700 (PDT) In-Reply-To: <9680955B-EC9D-4B9D-8416-06678A34335D@iii.ca> References: <9680955B-EC9D-4B9D-8416-06678A34335D@iii.ca> Date: Thu, 2 May 2013 10:17:55 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle Poll for RTCWeb Virtual Interim Time X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:17:57 -0000 On 2 May 2013 09:41, Cullen Jennings wrote: > > We are trying to pick a time to have an Virtual Interim meeting for the IETF RTCWeb WG on the topic of SDP Security Descriptions (RFC 4568 aka SDES) Is the intent of this interim to discuss various positions on the topic (similar to the recent thread), or do you intend to (try to) close the issue? My experience with virtual interims is that it is very difficult to assess consensus, mainly because it's impossible to get a word in edgewise and only a noisy few end up speaking. Much as I'd like to see this closed, I don't see much point in discussing this topic on a phone call. It's not quite as contentious as the codec issue, but it's clear from the list discussion that there are some strongly held views. Those cannot be resolved in a call. I could be convinced to change my mind if you could clearly identify specific topics that need more exploration. The only topic that needs more exploration is EKT, which seems to be very poorly understood. That alone doesn't justify an interim. From karl.stahl@intertex.se Thu May 2 10:55:46 2013 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 B6B9521F8EB7 for ; Thu, 2 May 2013 10:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38aGLdfoZAHg for ; Thu, 2 May 2013 10:55:40 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5125721F8E76 for ; Thu, 2 May 2013 10:55:34 -0700 (PDT) Received: from ([79.136.100.83]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NWF80219; Thu, 02 May 2013 19:55:19 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <02d001ce465c$bf00f690$3d02e3b0$@stahl@intertex.se> <8486C8728176924BAF5BDB2F7D7EEDDF49AC5673@ucolhp9b.easf.csd.disa.mil> <033701ce4697$1c545d20$54fd1760$@stahl@intertex.se> <5182745F.4080508@alves trand.no> In-Reply-To: <5182745F.4080508@alvestrand.no> Date: Thu, 2 May 2013 19:55:22 +0200 Message-ID: <01b801ce475e$37f2a5b0$a7d7f110$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HPyRtcW0I7pJuQg+/d4GiweqGrwAHemaw Content-Language: sv Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:55:46 -0000 Yes, that was why I put it in within quotes. I just wanted to make clear that DTLS setup/key exchange goes via UDP packets. Those are NOT "normal data" that are error = corrected/retransmitted at that level (in ref to the previous email). /Karl -----Ursprungligt meddelande----- Fr=E5n: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Skickat: den 2 maj 2013 16:13 Till: Karl Stahl Kopia: 'Roy, Radhika R CIV USARMY (US)'; 'Cullen Jennings (fluffy)'; rtcweb@ietf.org =C4mne: Re: SV: [rtcweb] Network times . was SDP Security Descriptions = (RFC 4568) and RTCWeb (UNCLASSIFIED) On 05/01/2013 08:10 PM, Karl Stahl wrote: > Just to clarify: > DTLS setup/key exchange goes over the UDP "voice/video channel". Now you've gotten me confused. DTLS setup/key exchange goes via UDP packets. These UDP packets are not sent over RTP (but I do expect them to use the same source and destination port numbers as the RTP streams). I've always used "voice/video channel" (if I've ever used it) to mean = RTP. > /Karl > > -----Ursprungligt meddelande----- > Fr=E5n: Roy, Radhika R CIV USARMY (US)=20 > [mailto:radhika.r.roy.civ@mail.mil] > Skickat: den 1 maj 2013 13:47 > Till: Karl Stahl; 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' > Kopia: rtcweb@ietf.org > =C4mne: RE: [rtcweb] Network times . was SDP Security Descriptions = (RFC=20 > 4568) and RTCWeb (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > Folks: > > I am responding only on a part of this email about retransmissions of=20 > audio or video packets. > > Let us not consider the retransmission of audio or video packets. Let=20 > us consider audio or video packets are sent only over UDP. Let MOS/QoS = > of audio or video are considered in a way that retransmissions do not = take place. > > Then the question comes only about "data" traffic retransmissions.=20 > Data traffic can tolerate much higher delays than that of audio or=20 > video. Data has only QoS (and no MOS). > > Let us divide the performance problems in two different parts. > > In this case, we can have more focused solutions related to=20 > (Audio/Video) MOS/QoS or (Data) QoS as explained above. > > BR/Radhika > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Karl Stahl > Sent: Wednesday, May 01, 2013 7:12 AM > To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Network times . was SDP Security Descriptions=20 > (RFC > 4568) and RTCWeb > > Regarding delays... > > Today, packets over the Internet reach any point on the earth within=20 > 250 ms as Cullen found - There are simply nowhere packet are=20 > stored/buffered in any amount to give higher delays (Where would Gbps = be stored for a second?). > Routers drop packets at congestion, they don't store them (and light=20 > takes > 140 ms for a turn around the earth, somewhat slower in a fiber). > > So, the problem with voice/video quality (if overall bandwidth for the = > RTP/UDP is sufficient and up) is only dropped packets, which "only"=20 > happens at congestion points where the pipe gets filled by TCP data=20 > (surf, email, file transfer), when TCP end-points regulate down to=20 > share the pipe in their hunger for infinite transfer speed. Then both=20 > TCP and RTP/UPD packets are dropped as a consequence of intense=20 > TCP-flows initiation. (The static situation is ok - no packets are=20 > dropped) > > Second long packet delays must come from retransmission of lost=20 > packets. If DTLS, it must be a higher level retransmission, I believe. > > Questions: > > 1) Does DTLS take long time to set up in itself in the browser (Aren't = > self signed certificate generated and exchanged?) while SRTP/DES is=20 > less CPU intense with ready certificate over the signaling path (I=20 > think)? But is this significant on let's say a 1 GHz smartphone which=20 > would be the lowest CPU power to consider? > > 2) Are packet drops during TLS-setup more likely over the UDP channel=20 > between browsers (as for DTLS) than over the signaling channel (for=20 > SRTP/DES). And are there more packets that safely need to arrive with=20 > DTLS setup? > > 3) SRTP/DES setup rely on TCP retransmission if packets are lost=20 > (correct me if I am wrong), while DTLS must rely on some other higher=20 > level retransmission mechanisms. Are there longer timers involved=20 > then? I think this may be the real explanation for reports of slow = DTLS setup, isn't it? > > The only cure against dropped UPD packets is IP-level QoS, such as=20 > traffic shaping in firewalls/routers (but they need to be aware of=20 > traffic type) and diffserv or reservation over the transport network-=20 > but that is (currently) not enabled over the Internet, where all = traffic is best effort class. > > /Karl > > > > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = > Cullen Jennings (fluffy) > Skickat: den 1 maj 2013 07:10 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > =C4mne: [rtcweb] Network times =85 was SDP Security Descriptions (RFC=20 > 4568) and RTCWeb > > > On Apr 29, 2013, at 2:29 AM, Harald Alvestrand wrote: > >> Would it be possible to get real data on 1) and 2) here, so that we=20 >> can > stop talking about "slow" and instead talk about "N milliseconds"? > I did try and round up a bunch of data for ping times from India to=20 > Singapore as some people were suggesting these were 1500ms. > > I got measurements from both home DSL and more business class from a=20 > range of sources in India. It seems that anywhere one could run video, = > you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in = > less than 250 ms one way. If someone has an actually link that is=20 > getting 1500 ms out of India, I'd love to get the info so I can see=20 > what I can learn (the buffer bloat folks want to hear about this :-) > > > > > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > From karl.stahl@intertex.se Thu May 2 13:08:34 2013 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 3CD6221F8DCF for ; Thu, 2 May 2013 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW8Xy6sX2tpd for ; Thu, 2 May 2013 13:08:30 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6B721F8D2B for ; Thu, 2 May 2013 13:08:27 -0700 (PDT) Received: from ([79.136.100.83]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id NZK97412; Thu, 02 May 2013 22:08:12 +0200 From: "Karl Stahl" To: , "'Justin Uberti'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com> <51823508.8090305@gm ail.com> <5182622e.2a78980a.697f.ffffb5e9SMTPIN_ADDED_BROKEN@mx.google.com> <51827CAD.3000600@gmail.com> In-Reply-To: <51827CAD.3000600@gmail.com> Date: Thu, 2 May 2013 22:08:16 +0200 Message-ID: <01d801ce4770$c85f6f90$591e4eb0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01CE4781.8BE83F90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HRBSk0NhHwZFETXyCdUmhFZYA0QAKY59g Content-Language: sv Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:08:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01D9_01CE4781.8BE83F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 Skickat: den 2 maj 2013 16:48 Till: Karl Stahl; 'Justin Uberti' Kopia: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org =C4mne: Re: SV: [rtcweb] Network times . was SDP Security Descriptions = (RFC 4568) and RTCWeb =20 =20 On 5/2/13 2:45 PM, Karl Stahl wrote: Rtp relays are fast routing devices that should not add even 1 ms to the delay.=20 By the 'routing device' do you mean some hardware based packet = forwarding (e.g, done in the ethernet card) or an application doing the forwarding = in user space? [KS] Even without hw acceleration, and in user space, delays in packet forwarding devices are not significant here. Our small embedded (264 MHz ARM) SIP E-SBC can carry 50 simultaneous G.711 calls with 20 ms voice packets. That is 2500 packets each way, giving us 0.4 ms to handle each packet =96 we do not buffer up packets, they are prioritized to go out = first - so that is the magnitude of delay introduced. And our big 3 GHz quad = core x86 machines handles 8000 simultaneous calls. We are talking 10 us per packet (even in user space, which indeed is slower). =20 So, it not routers and RTP-relays that introduces delays. It is the = distance between them, slow access channels and the jitter buffers needed that together make up the delays. /Karl At least our (Ingates) SBCs add no significant delay when carrying SIP media. =20 But if there is a TURN server on the other side of the earth, you can = get additional delays of course. The point I wanted to make was that any new technology should not be designed for ideal cases, also not for worst cases, but to satisfy the majority of the possible users. Daniel =20 --=20 Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * ------=_NextPart_000_01D9_01CE4781.8BE83F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

Fr=E5n: Daniel-Constantin Mierla [mailto:miconda@gmail.com] =
Skickat: den 2 maj 2013 16:48
Till: Karl Stahl; = 'Justin Uberti'
Kopia: 'Cullen Jennings (fluffy)'; = rtcweb@ietf.org
=C4mne: Re: SV: [rtcweb] Network times . was = SDP Security Descriptions (RFC 4568) and = RTCWeb

 

 

On = 5/2/13 2:45 PM, Karl Stahl wrote:

Rt= p relays are fast routing devices that should not add even 1 ms to the = delay.


By = the 'routing device' do you mean some hardware based packet forwarding = (e.g, done in the ethernet card) or an application doing the forwarding = in user space?
[KS] Even = without hw acceleration, and in user space, delays in packet forwarding = devices are not significant here. Our small embedded (264 MHz ARM) = =A0SIP E-SBC can carry 50 simultaneous G.711 calls with 20 ms voice = packets. That is 2500 packets each way, giving us 0.4 ms to handle each = packet – we do not buffer up packets, they are prioritized to go = out first - so that is the magnitude of delay introduced. And our big 3 = GHz quad core x86 machines handles 8000 simultaneous calls. We are = talking 10 us per packet (even in user space, which indeed is = slower).

 

So, it not = routers and RTP-relays that introduces delays. It is the distance = between them, slow access channels and the jitter buffers needed that = together make up the delays.

/Karl

At= least our (Ingates) SBCs add no significant delay when carrying SIP = media.

&n= bsp;

Bu= t if there is a TURN server on the other side of the earth, you can get = additional delays of course.

The point I wanted to make was that any new technology = should not be designed for ideal cases, also not for worst cases, but to = satisfy the majority of the possible = users.

Daniel

 
-- =

Daniel-Constantin Mierla - http://www.asipto.com
= 
http://twitter.com/#!/miconda =
- http://www.linkedin.com/in/mi=
conda
Kamailio Advanced Training, San =
Francisco, USA - June 24-27, 2013
=A0 * http://asipto.com/u/katu =
*
------=_NextPart_000_01D9_01CE4781.8BE83F90-- From dwing@cisco.com Thu May 2 16:40:56 2013 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 DE35E21F8F41 for ; Thu, 2 May 2013 16:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sr58JU38gKo for ; Thu, 2 May 2013 16:40:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0E28521F8F2F for ; Thu, 2 May 2013 16:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7931; q=dns/txt; s=iport; t=1367538053; x=1368747653; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=8e+TPFE6IBzK1UmQDto3H0NS5ua8iUi3HrZ9oRu0om8=; b=TB+nqXNuHtIpSL+3XiynkVwwwAZkU8VDIXLrJXF/l6DFsAo+xh07usph 7SmNiGtR4B8144u0e6AwK0DbNtxWn1MgEw57rA6jleJkWFxnwrcrqprou U6Y/DPGRX9WxKATbhLxdv95j+PW4BtY0Fmp9P6WqgfDDv91gOlXmctUY3 s=; X-IronPort-AV: E=Sophos;i="4.87,599,1363132800"; d="scan'208,217";a="80135085" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 02 May 2013 23:40:53 +0000 Received: from [10.156.16.58] ([10.156.16.58]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r42NepiN010750; Thu, 2 May 2013 23:40:51 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_F8D6B54D-7E71-4432-90C5-0A24E14F5A37" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <51827CAD.3000600@gmail.com> Date: Thu, 2 May 2013 16:40:51 -0700 Message-Id: <8F49EA56-6BB2-492F-A93F-FEA71EFA9856@cisco.com> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815b69.e3e8440a.460a.002eSMTPIN_ADDED_BROKEN@mx.google.com> <51823508.8090305@gm ail.com> <5182622e.2a78980a.697f.ffffb5e9SMTPIN_ADDED_BROKEN@mx.google.com> <51827CAD.3000600@gmail.com> To: X-Mailer: Apple Mail (2.1503) Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 23:40:57 -0000 --Apple-Mail=_F8D6B54D-7E71-4432-90C5-0A24E14F5A37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 2, 2013, at 7:48 AM, Daniel-Constantin Mierla = wrote: >=20 > On 5/2/13 2:45 PM, Karl Stahl wrote: >> Rtp relays are fast routing devices that should not add even 1 ms to = the delay. >=20 > By the 'routing device' do you mean some hardware based packet = forwarding (e.g, done in the ethernet card) or an application doing the = forwarding in user space? >=20 >> At least our (Ingates) SBCs add no significant delay when carrying = SIP media. >> =20 >> But if there is a TURN server on the other side of the earth, you can = get additional delays of course. > The point I wanted to make was that any new technology should not be = designed for ideal cases, also not for worst cases, but to satisfy the = majority of the possible users. = https://developers.google.com/talk/libjingle/important_concepts#connection= s,=20 "This is because the data pathway can be either a direct connection = (92%=20 of connection attempts can take place directly) or through a relay = server=20 (8% of connection attempts require an intermediary relay server)."=20= -d >=20 > Daniel >=20 > --=20 > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 > * http://asipto.com/u/katu * > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_F8D6B54D-7E71-4432-90C5-0A24E14F5A37 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On May 2, 2013, at 7:48 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:


On 5/2/13 2:45 PM, Karl Stahl wrote:

Rtp relays are fast routing devices that should not add even 1 ms to the delay.


By the 'routing device' do you mean some hardware based packet forwarding (e.g, done in the ethernet card) or an application doing the forwarding in user space?

At least our (Ingates) SBCs add no significant delay when carrying SIP media.

 

But if there is a TURN server on the other side of the earth, you can get additional delays of course.

The point I wanted to make was that any new technology should not be designed for ideal cases, also not for worst cases, but to satisfy the majority of the possible users.

  "This is because the data pathway can be either a direct connection (92% 
    of connection attempts can take place directly) or through a relay server 
    (8% of connection attempts require an intermediary relay server)." 

-d




Daniel


-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
  * http://asipto.com/u/katu *
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--Apple-Mail=_F8D6B54D-7E71-4432-90C5-0A24E14F5A37-- From fluffy@iii.ca Thu May 2 19:15:59 2013 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 2C3A021F89AF for ; Thu, 2 May 2013 19:15:59 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGKq2AXZqz2d for ; Thu, 2 May 2013 19:15:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C121F89D5 for ; Thu, 2 May 2013 19:15:54 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BBFCD22E256; Thu, 2 May 2013 22:15:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51815F43.7090505@jesup.org> Date: Thu, 2 May 2013 20:15:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815F43.709050 5@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 02:15:59 -0000 On May 1, 2013, at 12:30 PM, Randell Jesup = wrote: > On 5/1/2013 9:01 AM, Justin Uberti wrote: >> This doesn't match what we are seeing. I pulled some Chrome stats on = average RTT seen across various network connections; on 3G, close to = half of users had RTTs > 250 ms. 4G is somewhat better. 2G is = considerably worse. >>=20 >> India continues to be especially bad, partially because of the above, = partially because of use of satellite links, which due to physics incur = 500 ms RTTs. >=20 > Those are all RTT measurements, so One Way Delay's of roughly half of = that? speed-of-light for a one-way satellite link would be around 280ms = in theory - and of course that's just for that one physical link. By one way here, you mean up to the satellite link, then back down to = the ground again which the satellite people often don't call one way but = I agree it is the network latency measurement from browser to browser we = are looking for. You are of course correct that, for geosync satellites = that are at somewhere around 42,000 km up, we get around 240 to 280 ms = depending on your relative location to the satellite. But, keep in mind = the preferred satellites for this type of stuff are globalstar at 1400 = km or iridium at less than 800 km which have way less latency than = geosync.=20 I'm still looking for the elusive 1500 ms.=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu May 2 21:49:23 2013 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 2C57D21F8B38 for ; Thu, 2 May 2013 21:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o465eGzp-Gg for ; Thu, 2 May 2013 21:49:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D497121F8D2C for ; Thu, 2 May 2013 21:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 645E739E125 for ; Fri, 3 May 2013 06:49:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHn-bdEJXdUl for ; Fri, 3 May 2013 06:49:12 +0200 (CEST) Received: from [172.30.42.116] (c-e2fee555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.254.226]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B66B539E03B for ; Fri, 3 May 2013 06:49:12 +0200 (CEST) Message-ID: <518341C8.80100@alvestrand.no> Date: Fri, 03 May 2013 06:49:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F3BB9C0F6@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3BB9C0F6@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------090207050803050505020206" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 04:49:23 -0000 This is a multi-part message in MIME format. --------------090207050803050505020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/29/2013 03:40 PM, Ejzak, Richard P (Richard) wrote: > > I responded to this question earlier so didn't want to repeat myself, > but see now that it was either missed or otherwise not accepted. > > Quoting my earlier email from 4/25: > > "Legacy devices support more than just audio and video media. We will > need to occasionally transport protocols like T.140, MSRP, BFCP, > and/or RTSP in some cases, and the primary options are to transport > them over DataChannels or WebSockets. A network server will be needed > to do transport level interworking, of course. It would be useful in > these cases to have an SDES option for DataChannels. Not essential, > but useful. End-to-end security is not even an issue in this case due > to the need for transport level interworking." > > After further consideration, I don't currently see a use case for > RTSP, but I still do for the others. If we have a legacy endpoint > doing T.140 and audio, for example, it would be useful to be able to > multiplex the audio together with T.140/DC at the browser, and to put > a box in the network to adapt them as necessary for the legacy > endpoint (decode, demux, DC-to-RTP i/w for T.140, possibly > transcoding). SDES for DC just makes this easier to do. > I don't get that - I must be dense. DataChannel doesn't have a defined SDES encryption. So you're either talking about inventing a form of encryption that nobody's ever seen before, or you're tunneling SRTP packets over the data channel. If transcoding, the format on DataChannel are not likely to be exactly the RTP headers on the T.140 side, so you have to decrypt and re-encrypt anyway in order to change the bits. The other possibility is to take the encrypted SRTP T.140 packets and send them, raw, over DataChannel to the Web application and decrypt them there. "Only" requires SRTP key derivation, decryption and manipulation + T.140 interpretation to be done in Javascript. Seems possible to me - but do we really need to standardize anything for this option to be workable, or should we as a standards body just say "On your head be it"? --------------090207050803050505020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/29/2013 03:40 PM, Ejzak, Richard P (Richard) wrote:

I responded to this question earlier so didn’t want to repeat myself, but see now that it was either missed or otherwise not accepted.

 

Quoting my earlier email from 4/25:

 

“Legacy devices support more than just audio and video media.  We will need to occasionally transport protocols like T.140, MSRP, BFCP, and/or RTSP in some cases, and the primary options are to transport them over DataChannels or WebSockets.  A network server will be needed to do transport level interworking, of course.  It would be useful in these cases to have an SDES option for DataChannels.  Not essential, but useful.  End-to-end security is not even an issue in this case due to the need for transport level interworking.”

 

After further consideration, I don’t currently see a use case for RTSP, but I still do for the others.  If we have a legacy endpoint doing T.140 and audio, for example, it would be useful to be able to multiplex the audio together with T.140/DC at the browser, and to put a box in the network to adapt them as necessary for the legacy endpoint (decode, demux, DC-to-RTP i/w for T.140, possibly transcoding).  SDES for DC just makes this easier to do.


I don't get that - I must be dense.

DataChannel doesn't have a defined SDES encryption. So you're either talking about inventing a form of encryption that nobody's ever seen before, or you're tunneling SRTP packets over the data channel.

If transcoding, the format on DataChannel are not likely to be exactly the RTP headers on the T.140 side, so you have to decrypt and re-encrypt anyway in order to change the bits.

The other possibility is to take the encrypted SRTP T.140 packets and send them, raw, over DataChannel to the Web application and decrypt them there. "Only" requires SRTP key derivation, decryption and manipulation + T.140 interpretation to be done in Javascript.

Seems possible to me - but do we really need to standardize anything for this option to be workable, or should we as a standards body just say "On your head be it"?

--------------090207050803050505020206-- From bernard_aboba@hotmail.com Thu May 2 22:36:34 2013 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 BE06C21F9058 for ; Thu, 2 May 2013 22:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN3-pmIeauhR for ; Thu, 2 May 2013 22:36:28 -0700 (PDT) Received: from blu0-omc1-s11.blu0.hotmail.com (blu0-omc1-s11.blu0.hotmail.com [65.55.116.22]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA121F8733 for ; Thu, 2 May 2013 22:36:22 -0700 (PDT) Received: from BLU169-W75 ([65.55.116.8]) by blu0-omc1-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 May 2013 22:36:21 -0700 X-EIP: [fdv+V4ZzOe85ING6shjIkCpmwu9ppdLW] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1958101d-9eee-4799-bbeb-3b1a9afe5083_" From: Bernard Aboba To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 2 May 2013 22:36:21 -0700 Importance: Normal In-Reply-To: <518341C8.80100@alvestrand.no> References: , <03FBA798AC24E3498B74F47FD082A92F3BB9C0F6@US70UWXCHMBA05.zam.alcatel-lucent.com>, <518341C8.80100@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2013 05:36:21.0862 (UTC) FILETIME=[24E54060:01CE47C0] Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 05:36:34 -0000 --_1958101d-9eee-4799-bbeb-3b1a9afe5083_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 =0A= =20 "I don't get that - I must be dense.=0A= =20 =0A= DataChannel doesn't have a defined SDES encryption. So you're either=0A= talking about inventing a form of encryption that nobody's ever seen=0A= before=2C or you're tunneling SRTP packets over the data channel." [BA] To put Harald's statement another way=2C SDES/SRTP is only defined for= keying of SRTP as defined in RFC 3711. Not to put too fine a point on it= =2C but UDP is not SRTP=2C and therefore concepts such as "SRTP cryptograph= ic context" and ROC do not make sense without SRTP at least lurking somewhe= re nearby.=20 While some existing implementations do send data in (S)RTP packets (and the= refore could conceivably use SRTP/SDES as a key management mechanism)=2C = the term "data channel" used in the IETF RTCWEB WG implies SCTP over UDP=2C= and therefore requires a key management mechanism that works for UDP trans= port (e.g. DTLS). =20 Have we beaten this horse to death yet? = --_1958101d-9eee-4799-bbeb-3b1a9afe5083_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said: =3B
=0A=
"I don't get that - I must be dense.
=0A=
=0A= DataChannel doesn't have a defined SDES encryption. So you're either=0A= talking about inventing a form of encryption that nobody's ever seen=0A= before=2C or you're tunneling SRTP packets over the data channel."

[BA] To put Harald's statement another way=2C SDES/SRT= P is only defined for keying of SRTP as defined in RFC 3711. Not to put too fine a point on it=2C but UDP is not SR= TP=2C and therefore concepts such as "SRTP cryptographic context" and ROC d= o not make sense without SRTP at least lurking somewhere nearby. =3B

While some existing implementations do send= data in (S)RTP packets (and therefore could conceivably use SRTP/SDES as a= key  =3Bmanagement mechanism)=2C  =3Bthe term "data channel" used = in the IETF RTCWEB WG implies =3BSCTP over UDP=2C and therefore requires a key management mechanism tha= t works for UDP transport (e.g. DTLS).  =3B

Have we beaten this horse to death yet? =3B
= --_1958101d-9eee-4799-bbeb-3b1a9afe5083_-- From juberti@google.com Thu May 2 23:01:27 2013 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 6060221F92EF for ; Thu, 2 May 2013 23:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.69 X-Spam-Level: X-Spam-Status: No, score=-101.69 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnXFIsoAhsQn for ; Thu, 2 May 2013 23:01:26 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 99EAD21F9058 for ; Thu, 2 May 2013 23:01:26 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so1515519iea.32 for ; Thu, 02 May 2013 23:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=L+a+2zkDhSbecrkpVHaylw0WE02gKH7Iur8LYlyXjTQ=; b=R+2wGEuqFy+Zyj4F2HjMGnVDETRCU2QqdpVEI0cLp22iCcehR+YYMkGcg4NfI154jo tWGPQSL1UvgdsB9Vz7+FvX+UoDg8B/OS1sZayIuRkKA5TgQ9w8qOOL2FD1wMFzQ7XAnQ qlex8lBC/601J/s1B3D3UC+V4QqsKm89/sECh0Z3prg5r8r8t0suiv2gHGvuELUcJdJd JuBa66ukQxSklCPWAqRSgzj1LSJRKU3YRaxsBZRi9aOu+y91hhTmXL4wwocbVgXtPJy7 SQF7pm9L6LWE//LtG2p1gxrNJ04AtOcfmAXagK9+a0GTNf62yTv5L0sjdBglDeI8ySxD 4faQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=L+a+2zkDhSbecrkpVHaylw0WE02gKH7Iur8LYlyXjTQ=; b=U/sIrylNeHQE8FH/HHRfWihXRM+wpI/ViiIjMwyRkv3JQiPTTPyNjcT5c1VNsqtiPD 1KMou9oLiy5Bf55EHnqfYekNSxxJpSZIelIUo563M9SjO0s2aGZZJNTkMFTtYb4HKplc m5g+o1X5fwhfA/Ka5bHIjDAuWsk1Q6iHSDZwwh1PJ+IghdmcbSHGEl+dCHdqDSKVhkeT 8R3HIOkQNhB2rNKFXev1rD9A3naZDYLeTCppEJHLCPy992t0k7XW2S1VEdA7vEQSmWEp Ek+YKa6Lx5MIaKagaq0L3vo0jzvm5mP27KXNqKfNPFuWE/EH1xkUzVYHs9chiQ+pN8/H AHqQ== X-Received: by 10.50.37.236 with SMTP id b12mr16047313igk.42.1367560886018; Thu, 02 May 2013 23:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Thu, 2 May 2013 23:01:05 -0700 (PDT) In-Reply-To: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815F43.7090505@jesup.org> From: Justin Uberti Date: Thu, 2 May 2013 23:01:05 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=f46d044788d9d352e204dbca148b X-Gm-Message-State: ALoCoQk2/fteuggipcxwdmbIP7dWsjJQULpeKmP8KehuE0Bo6EgKsVrSmg9UpCjO2GJ5MOT6yqXlhtP3Sa/oJmw655Op8bImICt2QXYuwym8k24HtVdG8NLJehpIkNrRY6cya4cP8P2lwutV1PfghHVOraH1/gSRjZ8TXzpKFnAxVIR+cCAxgZUkPq73hHev7yD3wGMVdtfs Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 06:01:27 -0000 --f46d044788d9d352e204dbca148b Content-Type: text/plain; charset=UTF-8 Worldwide, a significant fraction of 2G and 3G mobile users experience RTT > 1500 ms. I am not suggesting that we design for these extreme cases, however. On Thu, May 2, 2013 at 7:15 PM, Cullen Jennings wrote: > > On May 1, 2013, at 12:30 PM, Randell Jesup wrote: > > > On 5/1/2013 9:01 AM, Justin Uberti wrote: > >> This doesn't match what we are seeing. I pulled some Chrome stats on > average RTT seen across various network connections; on 3G, close to half > of users had RTTs > 250 ms. 4G is somewhat better. 2G is considerably worse. > >> > >> India continues to be especially bad, partially because of the above, > partially because of use of satellite links, which due to physics incur 500 > ms RTTs. > > > > Those are all RTT measurements, so One Way Delay's of roughly half of > that? speed-of-light for a one-way satellite link would be around 280ms in > theory - and of course that's just for that one physical link. > > By one way here, you mean up to the satellite link, then back down to the > ground again which the satellite people often don't call one way but I > agree it is the network latency measurement from browser to browser we are > looking for. You are of course correct that, for geosync satellites that > are at somewhere around 42,000 km up, we get around 240 to 280 ms depending > on your relative location to the satellite. But, keep in mind the preferred > satellites for this type of stuff are globalstar at 1400 km or iridium at > less than 800 km which have way less latency than geosync. > > I'm still looking for the elusive 1500 ms. > > > > > > -- > > Randell Jesup > > randell-ietf@jesup.org > > > > _______________________________________________ > > 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 > --f46d044788d9d352e204dbca148b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Worldwide, a significant fraction of 2G and 3G mobile user= s experience RTT > 1500 ms. I am not suggesting that we design for these= extreme cases, however.


On Thu, May 2, 2013 at 7:15 PM, Cullen Jennings <fluffy@iii.ca> = wrote:

On May 1, 2013, at 12:30 PM, Randell Jesup <randell-ietf@jesup.org> wrote:

> On 5/1/2013 9:01 AM, Justin Uberti wrote:
>> This doesn't match what we are seeing. I pulled some Chrome st= ats on average RTT seen across various network connections; on 3G, close to= half of users had RTTs > 250 ms. 4G is somewhat better. 2G is considera= bly worse.
>>
>> India continues to be especially bad, partially because of the abo= ve, partially because of use of satellite links, which due to physics incur= 500 ms RTTs.
>
> Those are all RTT measurements, so One Way Delay's of roughly half= of that? =C2=A0speed-of-light for a one-way satellite link would be around= 280ms in theory - and of course that's just for that one physical link= .

By one way here, you mean up to the satellite link, then back down to= the ground again which the satellite people often don't call one way b= ut I agree it is the network latency measurement from browser to browser we= are looking for. You are of course correct that, for geosync satellites th= at are at somewhere around 42,000 km up, we get around 240 to 280 ms depend= ing on your relative location to the satellite. But, keep in mind the prefe= rred satellites for this type of stuff are globalstar at 1400 km or iridium= at less than 800 km which have way less latency than geosync.

I'm still looking for the elusive 1500 ms.


>
> --
> Randell Jesup
> randell-ietf@jesup.org >
> _______________________________________________
> 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

--f46d044788d9d352e204dbca148b-- From juberti@google.com Thu May 2 23:09:05 2013 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 DC2E521F8F43 for ; Thu, 2 May 2013 23:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.738 X-Spam-Level: X-Spam-Status: No, score=-101.738 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apSb4rUxpUOl for ; Thu, 2 May 2013 23:09:05 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4803421F8F06 for ; Thu, 2 May 2013 23:09:05 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so1527080iea.3 for ; Thu, 02 May 2013 23:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=LKHTd3sB3AyU5YZMUngUtxOpxh9zJEDvrRKdqh4Rhts=; b=M/ACp9PCkBa5gN5MT4buiSsI5HWu2//wogadusMLVI2HBx8d7s87cNLapUcpKbVzsu +mBVtez7kGNBNpQF6i3Ti6BuhAT/svqYHsTZRrM7bIkGWqrel06U6fsxEAiqcn1gwS5C eEaIgEMM6XG/9BIONbNtkUYeqj/ynqCmSIVdYe4QX/rJxF6I2mwvLWzkXyOtDTlmIrhN +tmNoxuJt/GFt8gAOmZp1fiAiACYPp+aQID4ykR+TuCB9CwufIw4vnRGmmR443JV/U5I 3I/3ge/sBNWUE6uBFBuYvNA3PY7wM2qWwjhw7pv8VnLutH1drg5wyi9fAJ0ighOb3FCE Nquw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=LKHTd3sB3AyU5YZMUngUtxOpxh9zJEDvrRKdqh4Rhts=; b=EKjh/ZptHS8vZ4IYVSZajxut+/swKslil1paEeMmPMGA4POC9ED7cC+JRm1yuY870k x6RNNfaI+vUEcN7v8DJum3/CCClruL4TJf6Z9lJbN0QVB7ZwhVmYCYiI2+qQ6IHw56Ed TJNhYbujng3do3h121jwL8Xe30m24zUwA/pQ3fp1Hy0Xg8htaPGwD/ydwgOtByPphzC/ HcwnnEJGrIXNrAM/ThC28ytWfKiUUZEiUOoRhMABgm8JDlOU5O1P1Y3YjW3BWCwuBbMP f3u5l2yfL4gA9Ohy7mg9TZE1mGstQStkkk2uXbqwre1191+kczV36MjMMqp3AGTs8Lcp q4dg== X-Received: by 10.42.145.137 with SMTP id f9mr4154993icv.52.1367561344772; Thu, 02 May 2013 23:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Thu, 2 May 2013 23:08:43 -0700 (PDT) In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Thu, 2 May 2013 23:08:43 -0700 Message-ID: To: "rtcweb@ietf.org" , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba6e8b502a062404dbca3051 X-Gm-Message-State: ALoCoQlis0eALkmZIq1uK8Y0v4LFXY887sMJIKoKR2NUmb7T3xoW+PSXWOPvARtfsUop16mYF3L4NLNffXt8ddu09L83K1YO5qd0P1bG9vUTc1g1EF16gFaY/j8lrCNpS2VhpXAdb5FFuxDwX0hJr4LK/PIIHISL9PENZ+EtRuE0/Tptghkjv6HL4gJh+ezFNx5eM99567eV Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 06:09:06 -0000 --90e6ba6e8b502a062404dbca3051 Content-Type: text/plain; charset=UTF-8 Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each. Hopefully this will make discussion of this topic easier. ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources in WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat --90e6ba6e8b502a062404dbca3051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scribbled down the basic concepts of what I have been refe= rring to as "Plan B" - a way to signal multiple MediaStreamTracks= in SDP without needing a separate m=3D line for each.

H= opefully this will make discussion of this topic easier.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for= draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>


A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-rtcweb-plan
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Plan B: a proposal for signaling = multiple media sources in WebRTC.
Creation date: =C2=A0 2013-05-03
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 15
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:= //www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.ie= tf.org/doc/draft-uberti-rtcweb-plan
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/d= raft-uberti-rtcweb-plan-00


Abstract:
=C2=A0 =C2=A0This document explains how multiple media sources can be signa= led in
=C2=A0 =C2=A0WebRTC using SDP, in a fashion that avoids many common problem= s and
=C2=A0 =C2=A0provides a simple control surface to the receiver.




The IETF Secretariat



--90e6ba6e8b502a062404dbca3051-- From karl.stahl@intertex.se Fri May 3 00:37:46 2013 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 10D0D21F9488 for ; Fri, 3 May 2013 00:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5US1-uvWAIR for ; Fri, 3 May 2013 00:37:40 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9221F9434 for ; Fri, 3 May 2013 00:37:37 -0700 (PDT) Received: from ([79.136.116.120]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305030937019042; Fri, 03 May 2013 09:37:01 +0200 From: "Karl Stahl" To: "'Cullen Jennings'" , "'Randell Jesup'" References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <51815F43.709050 5@jesup.org> In-Reply-To: Date: Fri, 3 May 2013 09:37:03 +0200 Message-ID: <023b01ce47d1$01aa5480$04fefd80$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HpCyrJqtahWm/RAO4Gk9bsj25ygAK7r1A Content-Language: sv Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 07:37:46 -0000 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Cullen Jennings Skickat: den 3 maj 2013 04:16 Till: Randell Jesup Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC = 4568) and RTCWeb On May 1, 2013, at 12:30 PM, Randell Jesup = wrote: > On 5/1/2013 9:01 AM, Justin Uberti wrote: >> This doesn't match what we are seeing. I pulled some Chrome stats on average RTT seen across various network connections; on 3G, close to = half of users had RTTs > 250 ms. 4G is somewhat better. 2G is considerably = worse. >>=20 >> India continues to be especially bad, partially because of the above, partially because of use of satellite links, which due to physics incur = 500 ms RTTs. >=20 > Those are all RTT measurements, so One Way Delay's of roughly half of that? speed-of-light for a one-way satellite link would be around 280ms = in theory - and of course that's just for that one physical link. By one way here, you mean up to the satellite link, then back down to = the ground again which the satellite people often don't call one way but I = agree it is the network latency measurement from browser to browser we are = looking for. You are of course correct that, for geosync satellites that are at somewhere around 42,000 km up, we get around 240 to 280 ms depending on = your relative location to the satellite. But, keep in mind the preferred satellites for this type of stuff are globalstar at 1400 km or iridium = at less than 800 km which have way less latency than geosync.=20 I'm still looking for the elusive 1500 ms.=20 [KS] Such delays most likely come from packet drop and retransmission of = key exchange packets. If we regularly had that kind of delay over some = channel, it would be unusable for RTC anyway.=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=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 harald@alvestrand.no Fri May 3 05:09:21 2013 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 666B021F919D for ; Fri, 3 May 2013 05:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7nGHjMwfiGo for ; Fri, 3 May 2013 05:09:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 31EE121F90B1 for ; Fri, 3 May 2013 05:09:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FADE39E129 for ; Fri, 3 May 2013 14:09:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keM+CLEIdc5b for ; Fri, 3 May 2013 14:09:14 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9F72939E125 for ; Fri, 3 May 2013 14:09:14 +0200 (CEST) Message-ID: <5183A8EA.8000805@alvestrand.no> Date: Fri, 03 May 2013 14:09:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <517E7DDD.5030705@ericsson.com> In-Reply-To: <517E7DDD.5030705@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] =?windows-1252?q?WG_last_call_comments_on_use-case_and_r?= =?windows-1252?q?equirement_document=2C_=93No_solution_defined=94?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:09:21 -0000 On 04/29/2013 04:04 PM, Stefan Håkansson LK wrote: > > > This relates to the comments to the WG last call of the use-cases and > requirements document [1]. > > The topic in this mail is the feedback that for some use-cases and > requirements no solution has been defined yet. This was brought up in > [2], with responses in [3] and [4]. > > My thinking here is that the bulk of this document was developed a > long time ago when this effort started out. The use-cases, and derived > requirements, reflect what was considered important at that time. > > We basically have two options here: either we publish that document, > including use-cases/requirements that we have not developed solutions > to yet, early (knowing we may not meet all use-cases/requirements), or > we go for a later publication where we update the document to reflect > what we have actually designed. > > My preference would be to go for the early publication, and to use > this document later in the process to see what requirements we do > meet, and what requirements we don’t meet. (This is basically my > proposal for use of this document, referring again to Bernard’s mail > on 2119 language [5]). This makes sense to me. In an ideal world (that is, not this one), there would be a document published after the first suite of specs that laid out: - Which use cases and requirements are met by the current set of documents - Which use cases and requirements can be met by further work (v2 and subsequent) - Which use cases and requirements are unrealistic to fulfil and should be abandoned I don't think we'll actually write such a document. But it's useful to think about it that way. Let's publish early. > > Stefan > > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06136.html > > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06180.html > [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06187.html > [4] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06200.html > [5] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06181.html > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon May 6 07:19:56 2013 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 7488221F933F; Mon, 6 May 2013 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGkrYffG5Oj6; Mon, 6 May 2013 07:19:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8D21F920B; Mon, 6 May 2013 07:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F20D139E1C8; Mon, 6 May 2013 16:19:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDCyLKZMmVQJ; Mon, 6 May 2013 16:19:49 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3AC6839E1BD; Mon, 6 May 2013 16:19:49 +0200 (CEST) Message-ID: <5187BC04.1030200@alvestrand.no> Date: Mon, 06 May 2013 16:19:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Uberti References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030903070701050308060208" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 14:19:56 -0000 This is a multi-part message in MIME format. --------------030903070701050308060208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved. The silence on this issue is disquieting. Harald On 05/03/2013 08:08 AM, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030903070701050308060208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved.

The silence on this issue is disquieting.

           Harald


On 05/03/2013 08:08 AM, Justin Uberti wrote:
Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

Hopefully this will make discussion of this topic easier.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat





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

--------------030903070701050308060208-- From henry.lum@genesyslab.com Mon May 6 07:30:32 2013 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 8727821F9378 for ; Mon, 6 May 2013 07:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHwbCfwUCgsa for ; Mon, 6 May 2013 07:30:27 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id BAF1021F91AB for ; Mon, 6 May 2013 07:30:26 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Mon, 06 May 2013 10:30:25 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 6 May 2013 07:30:24 -0700 From: Henry Lum To: Dan Wing , Harald Alvestrand Thread-Topic: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb Thread-Index: AQHOQc2YQOgDMnTsWEa6Uj24tqGWOZjnmKcAgABdt4CAAOBNgIAAG7QAgAAEhYCAAAaugIAPSUcA Date: Mon, 6 May 2013 14:30:23 +0000 Message-ID: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> In-Reply-To: <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.77] MIME-Version: 1.0 X-MC-Unique: 113050610302504802 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 14:30:32 -0000 Chiming in late. Speaking from a contact center perspective, a lot of calls are required to = be recorded. In order to allow active recording (such as SIPREC), the conta= ct center has to provide a media endpoint for bridging media so that a copy= of the media can be created. The users will have to trust the contact cent= er to handle the media anyways, and the media must be decrypted and re-encr= ypted by some media element within the contact center to perform recording.= To me DTLS-SRTP-EKT does not provide any additional benefit over SDES for = this type of use case. Regards, Henry=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Dan Wing Sent: April-26-13 9:57 AM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb On Apr 26, 2013, at 6:33 AM, Harald Alvestrand wrote= : > On 04/26/2013 03:16 PM, Tim Panton wrote: >>=20 >> On 26 Apr 2013, at 12:37, I=F1aki Baz Castillo wrote: >>=20 >>> Such a solution requires a very expensive gateway. Good for vendors but= bad for all the rest. >>>=20 >>=20 >> I don't understand why the DTLS gateway would be so expensive. It is _ex= actly_ the same >> (conceptually) as the ICE processing - you filter off a few UDP packets = from the stream, do some >> stuff, send replies then once you are happy you punt some dynamic settin= gs back up to the (s)rtp >> layer. >=20 > So you're saying that the gateway doesn't have to decrypt and re-encrypt = the packets? Correct - the gateway does not have to decrypt and re-encrypt the SRTP pack= ets. The gateway only has to interwork the signaling between SDES and DTLS= -SRTP-EKT. Such signaling interworking is necessary when the call is initi= ally set up and when the SRTP key is changed (e.g., a new person joins a ca= ll using their own key, or the SRTP key is exhausted [pretty unlikely, even= with video]). This was summarized in http://www.ietf.org/proceedings/83/s= lides/slides-83-rtcweb-3.pdf >=20 > I think EKT may be a problem, as Inaki pointed out, but I have less qualm= s about supporting DTLS and making it optional to use EKT on some calls tha= n I have about mandating support for SDES. -d > _______________________________________________ > 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 dwing@cisco.com Mon May 6 07:56:59 2013 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 3D2A621F86D5 for ; Mon, 6 May 2013 07:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jX5juvBOVZn for ; Mon, 6 May 2013 07:56:43 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3910921F867B for ; Mon, 6 May 2013 07:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3438; q=dns/txt; s=iport; t=1367852203; x=1369061803; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZGtqNQkK/dCvvpdHyhzJvCUc9uLk8GAL8yAqD1nt3uY=; b=gcqQBadxft2KrKhFsECQ5uFxMnuL7tWbw4WO0/+hIMPG2zcW9AwIEyIo PZh4RUFmaO+tDE7hYtZ4z1QazKj0++Qbe1agKRRpoT9WIYoiYFldQPJHt GY4dPS5wyR/7qto+1H5PlKn49CcdxZi6o02Qwj7Ij4900WWqDQvGwXKv+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAF/Dh1GrRDoJ/2dsb2JhbAA6FoMHN758gQIWdIIfAQEBAgEBAQEBawsFBwQLEQQBAQETFAcnHwkIBhMJEodrBQ2/d41ngRczBwaCbGEDiRqKRYNPhheLHYMtHA X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208";a="80431135" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 May 2013 14:56:41 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r46EudPR004228; Mon, 6 May 2013 14:56:39 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Mon, 6 May 2013 07:56:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> To: Henry Lum X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 14:56:59 -0000 On May 6, 2013, at 7:30 AM, Henry Lum wrote: > Chiming in late. >=20 > Speaking from a contact center perspective, a lot of calls are = required to be recorded. In order to allow active recording (such as = SIPREC), the contact center has to provide a media endpoint for bridging = media so that a copy of the media can be created. The users will have to = trust the contact center to handle the media anyways, and the media must = be decrypted and re-encrypted by some media element within the contact = center to perform recording. To me DTLS-SRTP-EKT does not provide any = additional benefit over SDES for this type of use case. Only DTLS-SRTP proves the call is actually to the call center (bank, = stock broker, reservation company). Security Descriptions cannot prove = the call is actually to the call center. That's a big difference in = security to know the call is terminated at the call center (which does = call recording or whatever it needs to do), versus trusting every SIP = hop along the path to not record the media, not inject audio ("buy 100 = shares" turned into "buy 100 thousand shares"), and to not lie about = where media terminates. Both can be recorded by the call center, which = is one of the parties involved with the call. -d >=20 > Regards, > Henry=20 >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Dan Wing > Sent: April-26-13 9:57 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb >=20 >=20 > On Apr 26, 2013, at 6:33 AM, Harald Alvestrand = wrote: >=20 >> On 04/26/2013 03:16 PM, Tim Panton wrote: >>>=20 >>> On 26 Apr 2013, at 12:37, I=F1aki Baz Castillo wrote: >>>=20 >>>> Such a solution requires a very expensive gateway. Good for vendors = but bad for all the rest. >>>>=20 >>>=20 >>> I don't understand why the DTLS gateway would be so expensive. It is = _exactly_ the same >>> (conceptually) as the ICE processing - you filter off a few UDP = packets from the stream, do some >>> stuff, send replies then once you are happy you punt some dynamic = settings back up to the (s)rtp >>> layer. >>=20 >> So you're saying that the gateway doesn't have to decrypt and = re-encrypt the packets? >=20 > Correct - the gateway does not have to decrypt and re-encrypt the SRTP = packets. The gateway only has to interwork the signaling between SDES = and DTLS-SRTP-EKT. Such signaling interworking is necessary when the = call is initially set up and when the SRTP key is changed (e.g., a new = person joins a call using their own key, or the SRTP key is exhausted = [pretty unlikely, even with video]). This was summarized in = http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf >=20 >=20 >>=20 >> I think EKT may be a problem, as Inaki pointed out, but I have less = qualms about supporting DTLS and making it optional to use EKT on some = calls than I have about mandating support for SDES. >=20 > -d >=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 From henry.lum@genesyslab.com Mon May 6 08:29:15 2013 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 DBCCE21F8F03 for ; Mon, 6 May 2013 08:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeMaF6JShqi6 for ; Mon, 6 May 2013 08:29:10 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15F21F869A for ; Mon, 6 May 2013 08:29:09 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Mon, 06 May 2013 11:29:08 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 6 May 2013 08:28:39 -0700 From: Henry Lum To: Dan Wing Thread-Topic: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb Thread-Index: AQHOQc2YQOgDMnTsWEa6Uj24tqGWOZjnmKcAgABdt4CAAOBNgIAAG7QAgAAEhYCAAAaugIAPSUcAgAB+uAD//44q8A== Date: Mon, 6 May 2013 15:28:39 +0000 Message-ID: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> In-Reply-To: <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.77] MIME-Version: 1.0 X-MC-Unique: 113050611290803801 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 15:29:16 -0000 To clarify, the case where contact center does not control an endpoint reco= rding a call, recording would happen on a media bridge (a SIP B2BUA) in the= contact center. Using DTLS-SRTP can prove that it is a media bridge from t= he contact center while SDES does not as you pointed out.=20 Does EKT provide any benefit in this case? Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: May-06-13 10:57 AM To: Henry Lum Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb On May 6, 2013, at 7:30 AM, Henry Lum wrote: > Chiming in late. >=20 > Speaking from a contact center perspective, a lot of calls are required t= o be recorded. In order to allow active recording (such as SIPREC), the con= tact center has to provide a media endpoint for bridging media so that a co= py of the media can be created. The users will have to trust the contact ce= nter to handle the media anyways, and the media must be decrypted and re-en= crypted by some media element within the contact center to perform recordin= g. To me DTLS-SRTP-EKT does not provide any additional benefit over SDES fo= r this type of use case. Only DTLS-SRTP proves the call is actually to the call center (bank, stock = broker, reservation company). Security Descriptions cannot prove the call = is actually to the call center. That's a big difference in security to kno= w the call is terminated at the call center (which does call recording or w= hatever it needs to do), versus trusting every SIP hop along the path to no= t record the media, not inject audio ("buy 100 shares" turned into "buy 100= thousand shares"), and to not lie about where media terminates. Both can = be recorded by the call center, which is one of the parties involved with t= he call. -d >=20 > Regards, > Henry=20 >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Dan Wing > Sent: April-26-13 9:57 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb >=20 >=20 > On Apr 26, 2013, at 6:33 AM, Harald Alvestrand wro= te: >=20 >> On 04/26/2013 03:16 PM, Tim Panton wrote: >>>=20 >>> On 26 Apr 2013, at 12:37, I=F1aki Baz Castillo wrote: >>>=20 >>>> Such a solution requires a very expensive gateway. Good for vendors bu= t bad for all the rest. >>>>=20 >>>=20 >>> I don't understand why the DTLS gateway would be so expensive. It is _e= xactly_ the same >>> (conceptually) as the ICE processing - you filter off a few UDP packets= from the stream, do some >>> stuff, send replies then once you are happy you punt some dynamic setti= ngs back up to the (s)rtp >>> layer. >>=20 >> So you're saying that the gateway doesn't have to decrypt and re-encrypt= the packets? >=20 > Correct - the gateway does not have to decrypt and re-encrypt the SRTP pa= ckets. The gateway only has to interwork the signaling between SDES and DT= LS-SRTP-EKT. Such signaling interworking is necessary when the call is ini= tially set up and when the SRTP key is changed (e.g., a new person joins a = call using their own key, or the SRTP key is exhausted [pretty unlikely, ev= en with video]). This was summarized in http://www.ietf.org/proceedings/83= /slides/slides-83-rtcweb-3.pdf >=20 >=20 >>=20 >> I think EKT may be a problem, as Inaki pointed out, but I have less qual= ms about supporting DTLS and making it optional to use EKT on some calls th= an I have about mandating support for SDES. >=20 > -d >=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 From dwing@cisco.com Mon May 6 08:38:58 2013 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 354CF21F89DE for ; Mon, 6 May 2013 08:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teyc248sOiOo for ; Mon, 6 May 2013 08:38:52 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3C21F8596 for ; Mon, 6 May 2013 08:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4364; q=dns/txt; s=iport; t=1367854732; x=1369064332; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=M4YgIXXScMsMzKGE5u8iBjlTZCIWn3lQdRbYDmlBu1Q=; b=G7VHISeYxNxWzjXXdpIIQTVpasGcXgmjZydb2HcbW6oJ3PgbrT//H7gB gZBTyEc5OrHrwD27O0F8LG5Fba9sJKvX61577RhoXqDpGYDmD5IEveNq5 8SZKovRB7EKuTX2D99sxu+V02s/weUUvfw8AT8b/aduALFPP04U27V+V3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACzNh1GrRDoI/2dsb2JhbAA6DQmDBze+fIECFnSCHwEBAQIBAQEBAWsLBQcECxEEAQEBExQHJx8JCAYTCRKHawUNv2KNZw+BCDMHBoJsYQOJGopFg0+GF4sdgy0c X-IronPort-AV: E=Sophos;i="4.87,622,1363132800"; d="scan'208";a="77859507" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 06 May 2013 15:38:49 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r46FclKD004605; Mon, 6 May 2013 15:38:48 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Mon, 6 May 2013 08:38:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0AE0AD36-C111-4582-A0C3-0BB4045C168D@cisco.com> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> To: Henry Lum X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 15:38:58 -0000 On May 6, 2013, at 8:28 AM, Henry Lum wrote: > To clarify, the case where contact center does not control an endpoint = recording a call, recording would happen on a media bridge (a SIP B2BUA) = in the contact center. Using DTLS-SRTP can prove that it is a media = bridge from the contact center while SDES does not as you pointed out.=20= >=20 > Does EKT provide any benefit in this case? No, EKT doesn't provide strong identity unless the SRTP keying provides = strong identity (e.g., MIKEY-RSA, DTLS-SRTP). -d >=20 > Henry >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: May-06-13 10:57 AM > To: Henry Lum > Cc: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb >=20 >=20 > On May 6, 2013, at 7:30 AM, Henry Lum = wrote: >=20 >> Chiming in late. >>=20 >> Speaking from a contact center perspective, a lot of calls are = required to be recorded. In order to allow active recording (such as = SIPREC), the contact center has to provide a media endpoint for bridging = media so that a copy of the media can be created. The users will have to = trust the contact center to handle the media anyways, and the media must = be decrypted and re-encrypted by some media element within the contact = center to perform recording. To me DTLS-SRTP-EKT does not provide any = additional benefit over SDES for this type of use case. >=20 > Only DTLS-SRTP proves the call is actually to the call center (bank, = stock broker, reservation company). Security Descriptions cannot prove = the call is actually to the call center. That's a big difference in = security to know the call is terminated at the call center (which does = call recording or whatever it needs to do), versus trusting every SIP = hop along the path to not record the media, not inject audio ("buy 100 = shares" turned into "buy 100 thousand shares"), and to not lie about = where media terminates. Both can be recorded by the call center, which = is one of the parties involved with the call. >=20 > -d >=20 >=20 >=20 >>=20 >> Regards, >> Henry=20 >>=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Dan Wing >> Sent: April-26-13 9:57 AM >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb >>=20 >>=20 >> On Apr 26, 2013, at 6:33 AM, Harald Alvestrand = wrote: >>=20 >>> On 04/26/2013 03:16 PM, Tim Panton wrote: >>>>=20 >>>> On 26 Apr 2013, at 12:37, I=F1aki Baz Castillo wrote: >>>>=20 >>>>> Such a solution requires a very expensive gateway. Good for = vendors but bad for all the rest. >>>>>=20 >>>>=20 >>>> I don't understand why the DTLS gateway would be so expensive. It = is _exactly_ the same >>>> (conceptually) as the ICE processing - you filter off a few UDP = packets from the stream, do some >>>> stuff, send replies then once you are happy you punt some dynamic = settings back up to the (s)rtp >>>> layer. >>>=20 >>> So you're saying that the gateway doesn't have to decrypt and = re-encrypt the packets? >>=20 >> Correct - the gateway does not have to decrypt and re-encrypt the = SRTP packets. The gateway only has to interwork the signaling between = SDES and DTLS-SRTP-EKT. Such signaling interworking is necessary when = the call is initially set up and when the SRTP key is changed (e.g., a = new person joins a call using their own key, or the SRTP key is = exhausted [pretty unlikely, even with video]). This was summarized in = http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf >>=20 >>=20 >>>=20 >>> I think EKT may be a problem, as Inaki pointed out, but I have less = qualms about supporting DTLS and making it optional to use EKT on some = calls than I have about mandating support for SDES. >>=20 >> -d >>=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 >=20 >=20 From csp@csperkins.org Mon May 6 15:01:25 2013 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 4FD1221F9376 for ; Mon, 6 May 2013 15:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPFL0Q1PNlUM for ; Mon, 6 May 2013 15:01:20 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0921F936F for ; Mon, 6 May 2013 15:01:20 -0700 (PDT) Received: from [81.187.2.149] (port=47100 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UZTT7-0001Ru-LY; Mon, 06 May 2013 23:01:14 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <066.6dfe974121b793946276e7b2bf610a93@trac.tools.ietf.org> Date: Mon, 6 May 2013 23:01:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0610BFBA-186C-4AB2-81A1-F6E793EEA6EA@csperkins.org> References: <066.6dfe974121b793946276e7b2bf610a93@trac.tools.ietf.org> To: rtcweb issue tracker X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] #14: Section 4.4: Multiplexing of RTP session over a single UDP flow X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 22:01:25 -0000 This is open issue 2 from Section 13 of the draft, and depends on the = outcome of the bundling and multiplexing discussions. Will revisit = later, when we have more clarity on those decisions. Certainly removing = the text is an option, though.=20 Colin On 20 Apr 2013, at 02:13, rtcweb issue tracker wrote: > #14: Section 4.4: Multiplexing of RTP session over a single UDP flow >=20 > Support for multiple RTP sessions over a single UDP flow as defined > by [I-D.westerlund-avtcore-transport-multiplexing] is RECOMMENDED/ > OPTIONAL. If multiple RTP sessions are to be multiplexed onto a > single UDP flow, this MUST be negotiated during the signalling = phase. >=20 > (tbd: No consensus on the level of support of Multiple RTP > sessions over a single UDP flow.) >=20 > Further discussion about when different RTP session structures and > multiplexing methods are suitable can be found in the memo on > Guidelines for using the Multiplexing Features of RTP > [I-D.westerlund-avtcore-multiplex-architecture]. >=20 > [BA] I would suggest that both of these paragraphs be removed. Leaving = a normative references to an individual submission that seems unlikely = to be advanced to WG work item status soon could delay the document. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: = draft-ietf-rtcweb-rtp- > bernard_aboba@hotmail.com | usage@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: rtp-usage | Version: 1.0 > Severity: Active WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 6 15:20:32 2013 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 20DD221F85EE for ; Mon, 6 May 2013 15:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H78NX5hnJQMe for ; Mon, 6 May 2013 15:20:27 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5221F85BF for ; Mon, 6 May 2013 15:20:27 -0700 (PDT) Received: from [81.187.2.149] (port=45112 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UZTlf-00055S-2O; Mon, 06 May 2013 23:20:23 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <066.dd434dc7b3ac73e1d637e8cf283c2ae0@trac.tools.ietf.org> Date: Mon, 6 May 2013 23:20:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1873D799-001C-432F-B792-0F5432393C3E@csperkins.org> References: <066.dd434dc7b3ac73e1d637e8cf283c2ae0@trac.tools.ietf.org> To: rtcweb issue tracker X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] #16: Section 5.1.6 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 22:20:32 -0000 The bandwidth limitations are defined in Sections 3.5.4 and 4.2.1 of RFC = 5104. They're not really designed for receiver-based congestion control; = as the draft suggests, they're more designed to allow an MCU to control = the streams being sent to it, as an envelope within which a congestion = control algorithm can operate. =20 We can certainly change this to "WebRTC senders are REQUIRED to = implement support for TMMBR messages, and MUST follow the bandwidth = limitations set by a TMMBR message received for their SSRC, as described = in Sections 3.5.4 and 4.2.1 of RFC 5104" if you think it will help?=20 We could also add some words to clarify that the TMMBR limit is an = upper-bound within which congestion control should operate? Colin On 20 Apr 2013, at 02:25, rtcweb issue tracker wrote: > #16: Section 5.1.6 >=20 > WebRTC senders > are REQUIRED to implement support for TMMBR messages, and MUST = follow > bandwidth limitations set by a TMMBR message received for their = SSRC. > The sending of TMMBR requests is OPTIONAL. >=20 > [BA] I realize I'm opening a can of worms here, but what does it mean = to > "follow bandwidth limitations set by a TMMBR message"? Is this = mandating > support for a receiver-side congestion control mechanism? Or is it > considered more like advice from the receiver on average bandwidth > availability over some time period (e.g. averaged over I and P = frames)? > Or is this a maximum simultaneous bw limitation? >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: = draft-ietf-rtcweb-rtp- > bernard_aboba@hotmail.com | usage@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: rtp-usage | Version: 1.0 > Severity: Active WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 6 15:40:28 2013 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 3193821F859C for ; Mon, 6 May 2013 15:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzA-zsPCbqFh for ; Mon, 6 May 2013 15:40:23 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8372C21F8551 for ; Mon, 6 May 2013 15:40:23 -0700 (PDT) Received: from [81.187.2.149] (port=38313 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UZU4w-0007Zl-OI; Mon, 06 May 2013 23:40:20 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <066.fa3a1be1719fe32561d53f4f0eb18295@trac.tools.ietf.org> Date: Mon, 6 May 2013 23:40:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0034C873-D97A-482C-AEE4-70BB28A7BA2D@csperkins.org> References: <066.fa3a1be1719fe32561d53f4f0eb18295@trac.tools.ietf.org> To: rtcweb issue tracker X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] #17: Section 6.1: Support for NACK X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 22:40:28 -0000 On 20 Apr 2013, at 02:32, rtcweb issue tracker wrote: > #17: Section 6.1: Support for NACK >=20 > Senders are REQUIRED to understand the Generic NACK message defined > in Section 6.2.1 of [RFC4585], but MAY choose to ignore this = feedback > (following Section 4.2 of [RFC4585]). >=20 > [BA] What does it mean to "understand" the generic NACK message? Are = we > only asking that an implementation not crash if it receives such a > message? Or does this mean that support for NACK needs to be declared = in "rtcp-fb" attributes? I think: doesn't crash or misbehave if it receives such a message, even = if it has not signalled support, but may ignore the feedback. If it can = respond meaningfully to NACK feedback, needs to declare it in a=3Drtcp-fb:= attributes. If this makes sense, I'll clarify the text. > If an implementation can "understand" NACK, and declare support in SDP = but then ignore the feedback, what does this achieve? Nothing, except some wasted NACKs. It's legal, but pointless.=20 Colin > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: = draft-ietf-rtcweb-rtp- > bernard_aboba@hotmail.com | usage@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: rtp-usage | Version: 1.0 > Severity: Active WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 6 15:44:59 2013 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 71C6821F92CB for ; Mon, 6 May 2013 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiRLR0rG1y0F for ; Mon, 6 May 2013 15:44:55 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id E5FA921F91CA for ; Mon, 6 May 2013 15:44:54 -0700 (PDT) Received: from [81.187.2.149] (port=40385 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UZU9K-0007xL-Qx; Mon, 06 May 2013 23:44:52 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <066.b392c6b846aaf34b02197d493399c8e9@trac.tools.ietf.org> Date: Mon, 6 May 2013 23:44:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <699B6B07-86F5-4642-AC58-1846C242E5DB@csperkins.org> References: <066.b392c6b846aaf34b02197d493399c8e9@trac.tools.ietf.org> To: rtcweb issue tracker X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] #18: Section 6.2: FEC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 06 May 2013 22:44:59 -0000 I'm open to suggestions, but it's not clear what we would recommend = here. My preference is to leave this for version 2. Colin On 20 Apr 2013, at 02:37, rtcweb issue tracker wrote: > #18: Section 6.2: FEC >=20 > At the time > of this writing there is no consensus on which, if any, of these = FEC > schemes is appropriate for use in the WebRTC context. Accordingly, > this memo makes no recommendation on the choice of block-based FEC > for WebRTC use. >=20 > [BA] By being vague on both NACK as well as FEC requirements, I think > we've set ourselves up for issues with respect to implementation = quality > if not interoperability. In practice, it may be possible to come up = with > some advice to FEC implementers (perhaps not at a REQUIRED but a > RECOMMENDED level). So I think we might want to revisit this. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: = draft-ietf-rtcweb-rtp- > bernard_aboba@hotmail.com | usage@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: rtp-usage | Version: 1.0 > Severity: Active WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From tim@phonefromhere.com Tue May 7 01:49:44 2013 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 ED5FD21F89B0 for ; Tue, 7 May 2013 01:49:44 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIHdfXqOL6rR for ; Tue, 7 May 2013 01:49:38 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 55E5A21F89D5 for ; Tue, 7 May 2013 01:49:37 -0700 (PDT) Received: (qmail 26304 invoked from network); 7 May 2013 08:49:35 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 7 May 2013 08:49:35 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id DB35618A0465; Tue, 7 May 2013 09:49:35 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B7A9B18A026B; Tue, 7 May 2013 09:49:35 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Panton In-Reply-To: Date: Tue, 7 May 2013 09:49:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> To: Henry Lum X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:49:45 -0000 On 6 May 2013, at 15:30, Henry Lum wrote: > Chiming in late. >=20 > Speaking from a contact center perspective, a lot of calls are = required to be recorded. In order to allow active recording (such as = SIPREC), the contact center has to provide a media endpoint for bridging = media so that a copy of the media can be created. The users will have to = trust the contact center to handle the media anyways, and the media must = be decrypted and re-encrypted by some media element within the contact = center to perform recording. To me DTLS-SRTP-EKT does not provide any = additional benefit over SDES for this type of use case. It can provide an identity benefit. A bank contact center can offer an = x509 certificate (from a trusted CA) over the DTLS media stream.=20 That's a big difference from the web server offering a cert over https - = the channel that may be shared with the signalling channel, which in = turn=20 may have set up the media. Direct assertion vs 2 uncertain hops. Of course the utility of that depends on the combined UX of the browser = chrome and the site, but at least it is possible... There should perhaps be some extra chrome 'bling' if the cert that = arrives over DTLS matches the HTTPS one that brought the signalling. T. From christer.holmberg@ericsson.com Tue May 7 03:12:03 2013 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 7FDB921F85BF; Tue, 7 May 2013 03:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge-w-QSuBd9L; Tue, 7 May 2013 03:11:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2421F8574; Tue, 7 May 2013 03:11:57 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-a6-5188d36ccc50 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.2E.32006.C63D8815; Tue, 7 May 2013 12:11:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 7 May 2013 12:11:55 +0200 From: Christer Holmberg To: Harald Alvestrand , Justin Uberti Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOR8S71uamUT1UgU2fGg1LHYFLV5j4GHYAgAE/1LA= Date: Tue, 7 May 2013 10:11:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> In-Reply-To: <5187BC04.1030200@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvrW7O5Y5Ag2XzJS2O9XWxWWydKmQx dfljFou1/9rZHVg8rky4wuqxYFOpx5IlP5kCmKO4bFJSczLLUov07RK4Mm7d+Mdc0NjDWDH3 w1e2BsZF1V2MnBwSAiYS617uZoOwxSQu3FsPZHNxCAkcZpQ4fL+JHcJZzCix/VAfUIaDg03A QqL7nzZIg4hAkMTcjxvAmpkFfCQenZnOBGILC0RKvFo9nxGiJkri9/fb7BC2lcSR5u2sIDaL gIrE6WtNYL28Ar4Sq9bsZYTY9ZFRYt79drBmTgFdiYVNJ5hBbEag676fWsMEsUxc4taT+UwQ VwtILNlznhnCFpV4+fgfK4StKHF1+nKo+nyJxnPnGCGWCUqcnPmEZQKj6Cwko2YhKZuFpAwi riOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYmTPTczMSS832sQIjLiDW36r7mC8c07kEKM0 B4uSOG8yV2OgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYmoZtFD9mn51l3dlw56Hl98u3N VtviGTaf/LJ1cX2QJIdtkejW2PL8e48XHA1eVeE3K7xs6bP6E0f5LvEZbOWV6sm0exnbtPBd d9OJyrr1wu/4Lnzfy8NVzNz84J7A1g/MK1V0q6+9WcuzfMObUq+srgjJ2P5FERN9Iw79/v1y cvgtwYWP32gqsRRnJBpqMRcVJwIA0x9NxYYCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:12:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A few questions on the draft: Q1_CODEC/CODEC CONFIGURATION: The examples only show one PT per m- line, and the draft seem to assume tha= t all PTs (ie codecs and/or codec configurations) apply to all SSRCs within= an m- line. I think that is very important to point out, because at least = in my opinion it is an important factor that we need to discuss. Example: I think Cullen often talks about using a camera with built in code= c X. But, Plan B does not allow to (or, at least does not describe how to) = explicitly offer codec X for the track/ssrc associated with the camera. Cod= ec X is offered for ALL tracks/ssrcs associated with the m- line. Q2_1_LEGACY: The text says that things must work with legacy devices, and that an endpoi= nt can choose a single source when communicating with a legacy device. But,= there is really no text about how the legacy device will know which source= to use, etc. Q2_2_LEGACY: The example in section 5.2 (and sub sections) confuses me a little. You ind= icate that the m- line itself represents "main", while ssrc attributes are = used to describe the left/center/right mic sources. Why is there no ssrc at= tribute for the main flow? Q3_NUMBER_OF_M_LINES: The draft does not explicitly forbid the usage of multiple m- lines for a g= iven media type (e.g. audio). It would probably be good to point that out a= lso. Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 6. toukokuuta 2013 17:20 To: Justin Uberti Cc: rtcweb@ietf.org; mmusic@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb= -plan-00.txt Note - I regard the Plan A / Plan B conflict as the "long end of the pole" = with regards to resolving issues regarding SDP signalling in RTCWEB - and a= s such, I regard it as very important to get it resolved. The silence on this issue is disquieting. Harald On 05/03/2013 08:08 AM, Justin Uberti wrote: Scribbled down the basic concepts of what I have been referring to as "Plan= B" - a way to signal multiple MediaStreamTracks in SDP without needing a s= eparate m=3D line for each. Hopefully this will make discussion of this topic easier. ---------- Forwarded message ---------- From: > Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti > A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources in= WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-pl= an-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

A few questions on the dr= aft:

 <= /p>

Q1_CODEC/CODEC CONFIGURAT= ION:

 <= /p>

The examples only show on= e PT per m- line, and the draft seem to assume that all PTs (ie codecs and/= or codec configurations) apply to all SSRCs within an m- line. I think that is very important to point out, because at least in my = opinion it is an important factor that we need to discuss.

 <= /p>

Example: I think Cullen o= ften talks about using a camera with built in codec X. But, Plan B does not= allow to (or, at least does not describe how to) explicitly offer codec X for the track/ssrc associated with the camera. Codec X is of= fered for ALL tracks/ssrcs associated with the m- line.

 <= /p>

 <= /p>

Q2_1_LEGACY:

 <= /p>

The text says that things= must work with legacy devices, and that an endpoint can choose a single so= urce when communicating with a legacy device. But, there is really no text about how the legacy device will know which source to us= e, etc.

 <= /p>

 <= /p>

Q2_2_LEGACY:

 <= /p>

The example in section 5.= 2 (and sub sections) confuses me a little. You indicate that the m- line it= self represents “main”, while ssrc attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute= for the main flow?

 <= /p>

 <= /p>

Q3_NUMBER_OF_M_LINES:

 <= /p>

The draft does not explic= itly forbid the usage of multiple m- lines for a given media type (e.g. aud= io). It would probably be good to point that out also.

 <= /p>

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti= -rtcweb-plan-00.txt

 

Note - I regard the Plan A / Plan B conflict as the = "long end of the pole" with regards to resolving issues regarding= SDP signalling in RTCWEB - and as such, I regard it as very important to g= et it resolved.

The silence on this issue is disquieting.

           Harald


On 05/03/2013 08:08 AM, Justin Uberti wrote:

Scribbled down the basic concepts of what I have bee= n referring to as "Plan B" - a way to signal multiple MediaStream= Tracks in SDP without needing a separate m=3D line for each.

 

Hopefully this will make discussion of this topic ea= sier.

 

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling = multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ie= tf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/d= raft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signa= led in
   WebRTC using SDP, in a fashion that avoids many common problem= s and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb

 

--_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_-- From harald@alvestrand.no Tue May 7 03:39:11 2013 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 E844B21F8EF2; Tue, 7 May 2013 03:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42bFgfqMjuKO; Tue, 7 May 2013 03:39:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2C21F8ED8; Tue, 7 May 2013 03:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D705F39E170; Tue, 7 May 2013 12:39:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR1gO-IvPOU8; Tue, 7 May 2013 12:39:02 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6969139E0D7; Tue, 7 May 2013 12:39:02 +0200 (CEST) Message-ID: <5188D9C5.3010209@alvestrand.no> Date: Tue, 07 May 2013 12:39:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------010502000906090604020403" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:39:12 -0000 This is a multi-part message in MIME format. --------------010502000906090604020403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/07/2013 12:11 PM, Christer Holmberg wrote: > > Hi, > > A few questions on the draft: > > Q1_CODEC/CODEC CONFIGURATION: > > The examples only show one PT per m- line, and the draft seem to > assume that all PTs (ie codecs and/or codec configurations) apply to > all SSRCs within an m- line. I think that is very important to point > out, because at least in my opinion it is an important factor that we > need to discuss. > > Example: I think Cullen often talks about using a camera with built in > codec X. But, Plan B does not allow to (or, at least does not describe > how to) explicitly offer codec X for the track/ssrc associated with > the camera. Codec X is offered for ALL tracks/ssrcs associated with > the m- line. > My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient. If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines. > Q2_1_LEGACY: > > The text says that things must work with legacy devices, and that an > endpoint can choose a single source when communicating with a legacy > device. But, there is really no text about how the legacy device will > know which source to use, etc. > The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application. > Q2_2_LEGACY: > > The example in section 5.2 (and sub sections) confuses me a little. > You indicate that the m- line itself represents "main", while ssrc > attributes are used to describe the left/center/right mic sources. Why > is there no ssrc attribute for the main flow? > The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics. > Q3_NUMBER_OF_M_LINES: > > The draft does not explicitly forbid the usage of multiple m- lines > for a given media type (e.g. audio). It would probably be good to > point that out also. > In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this. There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types. I don't know if such a scenario ever occurs in practice. > > Regards, > > Christer > > *From:*rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Harald Alvestrand > *Sent:* 6. toukokuuta 2013 17:20 > *To:* Justin Uberti > *Cc:* rtcweb@ietf.org ; mmusic@ietf.org > > *Subject:* Re: [rtcweb] Fwd: New Version Notification for > draft-uberti-rtcweb-plan-00.txt > > Note - I regard the Plan A / Plan B conflict as the "long end of the > pole" with regards to resolving issues regarding SDP signalling in > RTCWEB - and as such, I regard it as very important to get it resolved. > > The silence on this issue is disquieting. > > Harald > > > On 05/03/2013 08:08 AM, Justin Uberti wrote: > > Scribbled down the basic concepts of what I have been referring to > as "Plan B" - a way to signal multiple MediaStreamTracks in SDP > without needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be > signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --------------010502000906090604020403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/07/2013 12:11 PM, Christer Holmberg wrote:

Hi,

 

A few questions on the draft:

 

Q1_CODEC/CODEC CONFIGURATION:

 

The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss.

 

Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line.


My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient.

If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines.

 

 

Q2_1_LEGACY:

 

The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a legacy device. But, there is really no text about how the legacy device will know which source to use, etc.


The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application.

 

 

Q2_2_LEGACY:

 

The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents “main”, while ssrc attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow?


The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics.

 

 

Q3_NUMBER_OF_M_LINES:

 

The draft does not explicitly forbid the usage of multiple m- lines for a given media type (e.g. audio). It would probably be good to point that out also.


In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this.

There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types.
I don't know if such a scenario ever occurs in practice.

 

 

Regards,

 

Christer

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

 

Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved.

The silence on this issue is disquieting.

           Harald


On 05/03/2013 08:08 AM, Justin Uberti wrote:

Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

 

Hopefully this will make discussion of this topic easier.

 

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 




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

 


--------------010502000906090604020403-- From stefan.lk.hakansson@ericsson.com Tue May 7 03:45:30 2013 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 DE77721F8519; Tue, 7 May 2013 03:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO4LvaH-aY2F; Tue, 7 May 2013 03:45:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91521F84F9; Tue, 7 May 2013 03:45:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-ea-5188db43254f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 00.84.32006.34BD8815; Tue, 7 May 2013 12:45:24 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 7 May 2013 12:45:23 +0200 Message-ID: <5188DB43.60406@ericsson.com> Date: Tue, 7 May 2013 12:45:23 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> In-Reply-To: <5187BC04.1030200@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvra7L7Y5Ag0cfmS2mLn/MYrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgytq5dy15wQbiic8VS9gbGh/xdjJwcEgImEu0/57FC 2GISF+6tZ+ti5OIQEjjFKNHZt4gJwlnDKHGuZxoLSBWvgKbE5Slt7CA2i4CKxIItH8C62QQC Ja7//8UEYosKREn8e7ubEaJeUOLkzCdgvSJA9bPvnwCLCwuES8y6NJsRYsFrRok3n7rABnEK 6EosbDrBDGIzC9hKXJhznQXClpfY/nYOWFwIqObd63usExgFZiHZMQtJyywkLQsYmVcxsucm ZuaklxttYgQG3cEtv1V3MN45J3KIUZqDRUmcN5mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY3JPUE9GuXHr1adfuc9fXD19kgDX4dszZWUnPH5/6GOS09rn0z/mRZkILPqtYPEhI1JE Y+mXj/+PxvcXL9S59OVsQvSZj7q3F7/JkBF77e8fdmKKBINJjODmMz8C6hKeHjIN+iy17KIX 20Hl2CWf0lV4hR53bxDeFntblVE058Hl5aLJ100/2yqxFGckGmoxFxUnAgAhLIvnCAIAAA== Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:45:31 -0000 On 2013-05-06 16:19, Harald Alvestrand wrote: > Note - I regard the Plan A / Plan B conflict as the "long end of the > pole" with regards to resolving issues regarding SDP signalling in > RTCWEB - and as such, I regard it as very important to get it resolved. > > The silence on this issue is disquieting. I agree. Thinking out loud: could a meeting (joint mmusic and rtcweb I guess), that has as objective to discuss and decided which Plan to move forward with, be set up? Then there would be concrete deadlines, and most likely things would not stay as quiet. I guess it is a question for the chairs of those groups. > > Harald > > > On 05/03/2013 08:08 AM, Justin Uberti wrote: >> Scribbled down the basic concepts of what I have been referring to as >> "Plan B" - a way to signal multiple MediaStreamTracks in SDP without >> needing a separate m= line for each. >> >> Hopefully this will make discussion of this topic easier. >> >> ---------- Forwarded message ---------- >> From: > >> Date: Thu, May 2, 2013 at 10:46 PM >> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt >> To: Justin Uberti > >> >> >> >> A new version of I-D, draft-uberti-rtcweb-plan-00.txt >> has been successfully submitted by Justin Uberti and posted to the >> IETF repository. >> >> Filename: draft-uberti-rtcweb-plan >> Revision: 00 >> Title: Plan B: a proposal for signaling multiple media >> sources in WebRTC. >> Creation date: 2013-05-03 >> Group: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >> Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan >> Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 >> >> >> Abstract: >> This document explains how multiple media sources can be signaled in >> WebRTC using SDP, in a fashion that avoids many common problems and >> provides a simple control surface to the receiver. >> >> >> >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> 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 christer.holmberg@ericsson.com Tue May 7 05:08:27 2013 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 9EF3721F8EFC; Tue, 7 May 2013 05:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6kQj6wDNPVb; Tue, 7 May 2013 05:08:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6821F8F3C; Tue, 7 May 2013 05:08:21 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-16-5188eeb4bdb8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C5.D1.32006.4BEE8815; Tue, 7 May 2013 14:08:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 7 May 2013 14:08:20 +0200 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOSw8clsjra9RECEqdCjXAKrt6wpj5iT9g Date: Tue, 7 May 2013 12:08:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> <5188D9C5.3010209@alvestrand.no> In-Reply-To: <5188D9C5.3010209@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7Wdx2BBn+WMVkc6+tis9g6Vchi 6vLHLBZr/7WzO7B4XJlwhdVjwaZSjyVLfjIFMEdx2aSk5mSWpRbp2yVwZSy5+JSl4KZ+xeNP H1gbGJeodTFyckgImEi8+7CcFcIWk7hwbz1bFyMXh5DAYUaJG2f+sEI4ixklfsz4xtTFyMHB JmAh0f1PG6RBREBH4uH+BiYQm1mgSOL82weMILawQKTE1GtfGSFqoiQuHT3HBGEbSTzc+JER ZAyLgIrEjjX6ICavgK/E5uuOIBVCAjeYJL4f0gKxOQV0JRa+3Q7WyQh02vdTa6A2iUvcejKf CeJkAYkle84zQ9iiEi8f/4N6RVHi6vTlUPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjGKz kIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9rECIycg1t+q+5gvHNO5BCjNAeLkjhvMldjoJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbGWR/nTnP/U2t3wnDDKS7vAjH2hQfOXHy6z+sB96T2 lrVO3UZxXPu2XNq1/oZZoqfDHgNV1zdy9+3cTbJVGsRt46KWC7P43s474CyXxaom6j+tx+Lc niXzF10O+FhfYb/fyshhy7SUWKuqqc+aw+MdVYPeBx+oZGS9L/1DRbI5fY0lL3ex+iYlluKM REMt5qLiRABxn+cZagIAAA== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:08:27 -0000 Hi, =A0 >> A few questions on the draft: >> >> Q1_CODEC/CODEC CONFIGURATION: >>=A0 >> The examples only show one PT per m- line, and the draft seem to assume = that all PTs (ie codecs and/or codec configurations) apply to all SSRCs=20 >> within an m- line. I think that is very important to point out, because = at least in my opinion it is an important factor that we need to discuss. >> > Example: I think Cullen often talks about using a camera with built in co= dec X. But, Plan B does not allow to (or, at least does not describe how to= )=20 > explicitly offer codec X for the track/ssrc associated with the camera. C= odec X is offered for ALL tracks/ssrcs associated with the m- line. > > My read: This is a very special use case. The sender always chooses the c= odec from the available codecs that the recipient can understand - and it's= then free to choose the built in codec X if supported by the recipient. > > If, for some reason, the application is dependent on segregating the code= cs, it can use the "a=3Dcontent" mechanism to segregate the streams onto di= fferent M-lines. - Assume I have two cameras, one which can handle codec X, and one which ca= n handle codec Y.=20 - I send you an offer with a video m- line, offering X, Y and a ssrc for ea= ch camera - You only want one of my camera streams, AND you only support codec X. Now= , how do you know which ssrc to choose? You don't know which uses codec X. Now, maybe this is a theoretical problem, but I think the draft needs to de= scribe that codecs, and codec configurations, apply to all ssrcs associated= with an m- line. And, IF there is a need to apply codecs to a specific ssrc only, you need t= o use a separate m- line for that ssrc. >> Q2_1_LEGACY: >>=A0 >> The text says that things must work with legacy devices, and that an end= point can choose a single source when communicating with a=20 >> legacy device. But, there is really no text about how the legacy device = will know which source to use, etc. > > The application that drives the API will have to decide that it can send = only one source. The browser cannot (in my opinion) sensibly make that choi= ce on behalf of the application. Fair enough, but that needs to be clearly described. >> Q2_2_LEGACY: >>=A0 >> The example in section 5.2 (and sub sections) confuses me a little. You = indicate that the m- line itself represents "main", while ssrc=20 >> attributes are used to describe the left/center/right mic sources. Why i= s there no ssrc attribute for the main flow? > > The MSID identifier is, by definition, meaningless. The association betwe= en the MSID and the function of the stream is not carried in=20 > the MSID attribute. The example is a bit unfortunate in that it uses MSID= s that look as if they're human-readable strings that carry semantics. I wasn't referring to the MSID identifier, but more to the fact that you do= n't indicate the ssrc value for the "main" flow. I thought we were going to= mandate the indication of the ssrc value for each flow, but maybe I rememb= er wrong. >> Q3_NUMBER_OF_M_LINES: >> >> The draft does not explicitly forbid the usage of multiple m- lines for = a given media type (e.g. audio). It would probably be good to point that ou= t also. >> > In fact the a=3Dcontent mechanism (see section 3.1) depends on the abilit= y to use multiple m- lines for a given media type, so it would be really ha= rd to interpret the draft as forbidding this. Fair enough. My mistake. Regards, Christer There's an issue with representing the semantics of an incoming call that u= ses multiple m- lines for a given media type and doesn't give differing a= =3Dcontent attributes for those media types. I don't know if such a scenario ever occurs in practice. =A0 =A0 =A0 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 6. toukokuuta 2013 17:20 To: Justin Uberti Cc: rtcweb@ietf.org; mmusic@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb= -plan-00.txt =A0 Note - I regard the Plan A / Plan B conflict as the "long end of the pole" = with regards to resolving issues regarding SDP signalling in RTCWEB - and a= s such, I regard it as very important to get it resolved. The silence on this issue is disquieting. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald On 05/03/2013 08:08 AM, Justin Uberti wrote: Scribbled down the basic concepts of what I have been referring to as "Plan= B" - a way to signal multiple MediaStreamTracks in SDP without needing a s= eparate m=3D line for each.=20 =A0 Hopefully this will make discussion of this topic easier. =A0 ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-uberti-rtcweb-plan Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Plan B: a proposal for signaling multiple media = sources in WebRTC. Creation date: =A0 2013-05-03 Group: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 15 URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-uber= ti-rtcweb-plan-00.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-uberti-rtc= web-plan Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-uberti-rtcweb-pla= n-00 Abstract: =A0 =A0This document explains how multiple media sources can be signaled in =A0 =A0WebRTC using SDP, in a fashion that avoids many common problems and =A0 =A0provides a simple control surface to the receiver. The IETF Secretariat =A0 =A0 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =A0 From ron.even.tlv@gmail.com Tue May 7 05:52:45 2013 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 C8ABA21F8FEB; Tue, 7 May 2013 05:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCcCF7CwMapr; Tue, 7 May 2013 05:52:44 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5252921F86CB; Tue, 7 May 2013 05:52:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id z12so546555wgg.23 for ; Tue, 07 May 2013 05:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=2RWu8vEvaNNxgdOEgSPUq0KFcKvUdFCXvtl2aqaWnIY=; b=Zj1IE1eHWA7ZQMRF7jD/qyb8LwoyxQMxNoOIiwn4qxh3/Vqw0JQeEB/Txc71N/Fwxn zAjiQUHWJQ+RDHbOGRBw07mrceD4AK0E2s+gqdT0lsiaaTUyFuRp55sAlP+EY8GbaEuV qU29U8red0FprDT1EOEl2EQbUndBenOCaQ2xNjPF1fbK3uQPR4GV/Qn7U9OiOHac5QQF 6XJo90V9LO8z1dPdiuROEBLfjFqQ70S6ToXbz9F+26p5+cyfEZO+3Sup0k5ALKX0fZ0S AMMCS8NR7bAT3JdaqFVNIeygapOAG9HgPNJW/+IrcwOPATjSCvMxhLOQaF6xZFg2B0rk 9ErQ== X-Received: by 10.180.212.3 with SMTP id ng3mr3138032wic.22.1367931150438; Tue, 07 May 2013 05:52:30 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id q18sm2618430wiw.8.2013.05.07.05.52.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 05:52:29 -0700 (PDT) From: "Roni Even" To: "'Justin Uberti'" , , References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 7 May 2013 15:51:40 +0300 Message-ID: <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CE4B3A.C5E88760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfiYMNuJkA== Content-Language: en-us Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:52:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0088_01CE4B3A.C5E88760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I think that plan B is the right direction. I am wondering if this = should be discussed in RTCWEB or MMUSIC =20 I like the proposed solution for multicast support but there is also an = individual draft in MMUSIC see = http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . I = think that it will be good to have a separate document on simulcast = support =20 Some comments =20 1. In section 3.1 when talking about using more than one m-line = for a media type I think that there are other cases when this may be = required . for example, if an attribute is not specified at SSRC level = or if the SDP will be simpler when using multiple m-line )describing = different codec combinations 2. In section 3.2 the document says that collision will not happen = if the answerer sees the SDP from the Offer. I am not sure it will work = when joining a multipoint conference since the offer is joining an = existing session and do not know what SSRC have been used. I think that = the issue is handled in RFC5576 so you can point at it. 3. The draft, as far as I can tell, is discussing point to point = calls and full meshed conferences. I think we need to look at other = topologies including a centralized MCU doing video switch, for example. 4. In section 4.1 you suggest using the MSID as an indication for = supporting plan B. I think that this may be RTCWEB specific and other = usages like CLUE may use a different way to associate an SSRC to a Media = Capture. My proposal is to use maxssrc. I think that it will be needed = since an offer may include more options than can be really sent by the = offerer and the maxssrc can tell the answerer how many it can select. It = can also tell the answerer how many simultaneous RTP streams the offerer = can receive. Otherwise it may be better to have a specific identifier = that will tell that multiple RTP streams in an m-line are supported. 5. I have a question about the last paragraph of section 4.2. = Currently the answerer can start sending media immediately when getting = the offer in parallel to sending the SDP answer since the offer includes = receive capabilities and receive transport address. Are you suggesting = that media will flow only after the 3 way handshake? 6. Small nit on section 5.1.4, according to section 8 of the = Lennox source selection draft, the third offer must have sending:on for = the streams that are being sent so probably need a=3Dssrc:1 = msid:left-mic sending:on =20 =20 Roni Even =20 =20 =20 =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Justin Uberti Sent: 03 May, 2013 9:09 AM To: rtcweb@ietf.org; mmusic@ietf.org Subject: [rtcweb] Fwd: New Version Notification for = draft-uberti-rtcweb-plan-00.txt =20 Scribbled down the basic concepts of what I have been referring to as = "Plan B" - a way to signal multiple MediaStreamTracks in SDP without = needing a separate m=3D line for each. =20 Hopefully this will make discussion of this topic easier. =20 ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources = in WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: = http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt Status: = http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat =20 =20 _____ =20 ------=_NextPart_000_0088_01CE4B3A.C5E88760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

I think that plan B is the right direction. I am wondering if this = should be discussed in RTCWEB or MMUSIC

 

I like the proposed solution for multicast support but there is also = an individual draft in MMUSIC see http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02= . I think that it will be good to have a separate document on = simulcast support

 

Some comments

 

1.       = In section 3.1 when talking about using more than one m-line for a = media type I think that there are other cases when this may be required = . for example, if an attribute is not specified at SSRC level or if the = SDP will be simpler when using multiple m-line =C2=A0)describing = different codec combinations

2.       = In section 3.2 the document says that collision will not happen if = the answerer sees the SDP from the Offer. I am not sure it will work = when joining a multipoint conference since the offer is joining an = existing session and do not know what SSRC have been used. I think that = the issue is handled in RFC5576 so you can point at = it.

3.       = The draft, as far as I can tell, is discussing point to point calls = and full meshed conferences. I think we need to look at other topologies = including a centralized MCU doing video switch, for = example.

4.       = In section 4.1 you suggest using the MSID as an indication for = supporting plan B. I think that this may be RTCWEB specific and other = usages like CLUE may use a different way to associate an SSRC to a Media = Capture. My proposal is to use maxssrc. I think that it will be needed = since an offer may include more options than can be really sent by the = offerer and the maxssrc can tell the answerer how many it can select. It = can also tell the answerer how many simultaneous RTP streams the offerer = can receive. Otherwise it may be better to have a specific identifier = that will tell that multiple RTP streams in an m-line are = supported.

5.       = I have a question about the last paragraph of section 4.2. Currently = the answerer can start sending media immediately when getting the offer = in parallel to sending the SDP answer since the offer includes receive = capabilities and receive transport address. Are you suggesting that = media will flow only after the 3 way handshake?

6.       = Small nit on section 5.1.4, according to section 8 of the Lennox = source selection draft, the third offer must have sending:on for the = streams that are being sent so probably need a=3Dssrc:1 msid:left-mic = sending:on

 

 

Roni Even

 

 

 

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Justin Uberti
Sent: 03 May, 2013 9:09 AM
To: = rtcweb@ietf.org; mmusic@ietf.org
Subject: [rtcweb] Fwd: New = Version Notification for = draft-uberti-rtcweb-plan-00.txt

 

Scribbled down the basic concepts of what I have been = referring to as "Plan B" - a way to signal multiple = MediaStreamTracks in SDP without needing a separate m=3D line for = each.

 

Hopefully this will make discussion of this topic = easier.

 

---------- Forwarded = message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, = 2013 at 10:46 PM
Subject: New Version Notification for = draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new = version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully = submitted by Justin Uberti and posted to the
IETF = repository.

Filename:       =  draft-uberti-rtcweb-plan
Revision:       =  00
Title:           Plan B: a proposal = for signaling multiple media sources in WebRTC.
Creation date:   = 2013-05-03
Group:           Individual = Submission
Number of pages: 15
URL:         =     http://www.ietf.org/internet-drafts/draft-uberti-rtcweb= -plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-pla= n
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00<= /a>


Abstract:
   This document explains how = multiple media sources can be signaled in
   WebRTC using = SDP, in a fashion that avoids many common problems and
  =  provides a simple control surface to the = receiver.




The IETF Secretariat

 

 

------=_NextPart_000_0088_01CE4B3A.C5E88760-- From harald@alvestrand.no Tue May 7 06:08:45 2013 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 7143F21F8BBC; Tue, 7 May 2013 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-XizyqwCGDf; Tue, 7 May 2013 06:08:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A421F8A6B; Tue, 7 May 2013 06:08:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6515A39E1C4; Tue, 7 May 2013 15:08:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VOFtKWAT2pG; Tue, 7 May 2013 15:08:36 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7EF4339E0D7; Tue, 7 May 2013 15:08:36 +0200 (CEST) Message-ID: <5188FCD3.9050306@alvestrand.no> Date: Tue, 07 May 2013 15:08:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> <5188D9C5.3010209@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:08:45 -0000 On 05/07/2013 02:08 PM, Christer Holmberg wrote: > Hi, > >>> A few questions on the draft: >>> >>> Q1_CODEC/CODEC CONFIGURATION: >>> >>> The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs >>> within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss. >>> >> Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) >> explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line. >> >> My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient. >> >> If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines. > - Assume I have two cameras, one which can handle codec X, and one which can handle codec Y. > > - I send you an offer with a video m- line, offering X, Y and a ssrc for each camera > > - You only want one of my camera streams, AND you only support codec X. Now, how do you know which ssrc to choose? You don't know which uses codec X. Right. That's the part that goes all artificial on me. Two cameras, and I'm going to choose blindly between them if I support both codecs, but I can't accept both and let you deal with sending me only the one I can handle? You can, if you want to, send me two M-lines: "a=content:codec-x" and "a=content:codec-y". This is an example of "the application is dependent on segregating the codecs". > > Now, maybe this is a theoretical problem, but I think the draft needs to describe that codecs, and codec configurations, apply to all ssrcs associated with an m- line. > > And, IF there is a need to apply codecs to a specific ssrc only, you need to use a separate m- line for that ssrc. Agreed. > >>> Q2_1_LEGACY: >>> >>> The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a >>> legacy device. But, there is really no text about how the legacy device will know which source to use, etc. >> The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application. > Fair enough, but that needs to be clearly described. > > >>> Q2_2_LEGACY: >>> >>> The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents "main", while ssrc >>> attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow? >> The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in >> the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics. > I wasn't referring to the MSID identifier, but more to the fact that you don't indicate the ssrc value for the "main" flow. I thought we were going to mandate the indication of the ssrc value for each flow, but maybe I remember wrong. I was trying to locate the flows in the example in section 5.2, and I couldn't find them anywhere but in the MSID attribute. So I couldn't parse your comment. The way I read the document, the first m=audio line is the main audio; it has 3 audio flows. The first m=video line is the main video; it has 3 video flows. The third m=video line is the slides video; it has 2 SSRCs, one for the main flow and one for the repair flow. So - the issue seems to be that the word "main" as in "main audio" is easy to mistake for "a single main flow". It isn't intended to be that way. I guess the text could be clearer. > > >>> Q3_NUMBER_OF_M_LINES: >>> >>> The draft does not explicitly forbid the usage of multiple m- lines for a given media type (e.g. audio). It would probably be good to point that out also. >>> >> In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this. > Fair enough. My mistake. > > Regards, > > Christer > > There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types. > I don't know if such a scenario ever occurs in practice. > > > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: 6. toukokuuta 2013 17:20 > To: Justin Uberti > Cc: rtcweb@ietf.org; mmusic@ietf.org > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt > > Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved. > > The silence on this issue is disquieting. > > Harald > > > On 05/03/2013 08:08 AM, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From harald@alvestrand.no Tue May 7 06:25:47 2013 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 BD9AB21F85BF; Tue, 7 May 2013 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.848 X-Spam-Level: X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFIm19FNwyFh; Tue, 7 May 2013 06:25:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1A21F8528; Tue, 7 May 2013 06:25:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C18939E1C4; Tue, 7 May 2013 15:25:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fOxclB7mdGC; Tue, 7 May 2013 15:25:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9DAA439E170; Tue, 7 May 2013 15:25:36 +0200 (CEST) Message-ID: <518900CF.6050403@alvestrand.no> Date: Tue, 07 May 2013 15:25:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Roni Even References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> In-Reply-To: <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> Content-Type: multipart/alternative; boundary="------------050909030601020704020703" Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: Re: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:25:47 -0000 This is a multi-part message in MIME format. --------------050909030601020704020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/07/2013 02:51 PM, Roni Even wrote: > > Hi, > > I think that plan B is the right direction. I am wondering if this > should be discussed in RTCWEB or MMUSIC > Good question. > I like the proposed solution for multicast support but there is also > an individual draft in MMUSIC see > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . > I think that it will be good to have a separate document on simulcast > support > > Some comments > > 1.In section 3.1 when talking about using more than one m-line for a > media type I think that there are other cases when this may be > required . for example, if an attribute is not specified at SSRC level > or if the SDP will be simpler when using multiple m-line )describing > different codec combinations > > 2.In section 3.2 the document says that collision will not happen if > the answerer sees the SDP from the Offer. I am not sure it will work > when joining a multipoint conference since the offer is joining an > existing session and do not know what SSRC have been used. I think > that the issue is handled in RFC5576 so you can point at it. > > 3.The draft, as far as I can tell, is discussing point to point calls > and full meshed conferences. I think we need to look at other > topologies including a centralized MCU doing video switch, for example. > I'm not sure the multipoint conference scenario (using a mixer, transport relay or multicast) is in scope here. Those scenarios can't be done with offer/answer anyway. With scenarios that do centralized call termination (and not using CSRC), doing per-leg SSRC allocation is reasonable. > 4.In section 4.1 you suggest using the MSID as an indication for > supporting plan B. I think that this may be RTCWEB specific and other > usages like CLUE may use a different way to associate an SSRC to a > Media Capture. My proposal is to use maxssrc. I think that it will be > needed since an offer may include more options than can be really sent > by the offerer and the maxssrc can tell the answerer how many it can > select. It can also tell the answerer how many simultaneous RTP > streams the offerer can receive. Otherwise it may be better to have a > specific identifier that will tell that multiple RTP streams in an > m-line are supported. > > 5.I have a question about the last paragraph of section 4.2. Currently > the answerer can start sending media immediately when getting the > offer in parallel to sending the SDP answer since the offer includes > receive capabilities and receive transport address. Are you suggesting > that media will flow only after the 3 way handshake? > > 6.Small nit on section 5.1.4, according to section 8 of the Lennox > source selection draft, the third offer must have sending:on for the > streams that are being sent so probably need a=ssrc:1 msid:left-mic > sending:on > > Roni Even > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* 03 May, 2013 9:09 AM > *To:* rtcweb@ietf.org; mmusic@ietf.org > *Subject:* [rtcweb] Fwd: New Version Notification for > draft-uberti-rtcweb-plan-00.txt > > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > ------------------------------------------------------------------------ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------050909030601020704020703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/07/2013 02:51 PM, Roni Even wrote:

Hi,

I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC


Good question.

 

I like the proposed solution for multicast support but there is also an individual draft in MMUSIC see http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . I think that it will be good to have a separate document on simulcast support

 

Some comments

 

1.       In section 3.1 when talking about using more than one m-line for a media type I think that there are other cases when this may be required . for example, if an attribute is not specified at SSRC level or if the SDP will be simpler when using multiple m-line  )describing different codec combinations

2.       In section 3.2 the document says that collision will not happen if the answerer sees the SDP from the Offer. I am not sure it will work when joining a multipoint conference since the offer is joining an existing session and do not know what SSRC have been used. I think that the issue is handled in RFC5576 so you can point at it.

3.       The draft, as far as I can tell, is discussing point to point calls and full meshed conferences. I think we need to look at other topologies including a centralized MCU doing video switch, for example.


I'm not sure the multipoint conference scenario (using a mixer, transport relay or multicast) is in scope here. Those scenarios can't be done with offer/answer anyway.

With scenarios that do centralized call termination (and not using CSRC), doing per-leg SSRC allocation is reasonable.


4.       In section 4.1 you suggest using the MSID as an indication for supporting plan B. I think that this may be RTCWEB specific and other usages like CLUE may use a different way to associate an SSRC to a Media Capture. My proposal is to use maxssrc. I think that it will be needed since an offer may include more options than can be really sent by the offerer and the maxssrc can tell the answerer how many it can select. It can also tell the answerer how many simultaneous RTP streams the offerer can receive. Otherwise it may be better to have a specific identifier that will tell that multiple RTP streams in an m-line are supported.

5.       I have a question about the last paragraph of section 4.2. Currently the answerer can start sending media immediately when getting the offer in parallel to sending the SDP answer since the offer includes receive capabilities and receive transport address. Are you suggesting that media will flow only after the 3 way handshake?

6.       Small nit on section 5.1.4, according to section 8 of the Lennox source selection draft, the third offer must have sending:on for the streams that are being sent so probably need a=ssrc:1 msid:left-mic sending:on

 

 

Roni Even

 

 

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 03 May, 2013 9:09 AM
To: rtcweb@ietf.org; mmusic@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

 

Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

 

Hopefully this will make discussion of this topic easier.

 

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 



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

--------------050909030601020704020703-- From henry.lum@genesyslab.com Tue May 7 07:55:53 2013 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 7449521F861B for ; Tue, 7 May 2013 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8fFdxEapvUC for ; Tue, 7 May 2013 07:55:47 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0451721F856D for ; Tue, 7 May 2013 07:55:45 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Tue, 07 May 2013 10:55:42 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 7 May 2013 07:55:39 -0700 From: Henry Lum To: Tim Panton Thread-Topic: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb Thread-Index: AQHOQc2YQOgDMnTsWEa6Uj24tqGWOZjnmKcAgABdt4CAAOBNgIAAG7QAgAAEhYCAAAaugIAPSUcAgAGqgQD//+37IA== Date: Tue, 7 May 2013 14:55:38 +0000 Message-ID: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.77] MIME-Version: 1.0 X-MC-Unique: 113050710554300202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 14:55:54 -0000 Does the signalling and DTLS media stream need to use the same certificate = or the certificates can be from the same organization right? The contact ce= nter gateway and the recording element would be different components and he= nce have different certificates from the same organization. I agree it would be useful for a browser to warn the user that the media st= ream is coming from a different identity than the signalling if we agree th= at DTLS is the only transport. Regards, Henry -----Original Message----- From: Tim Panton [mailto:tim@phonefromhere.com]=20 Sent: May-07-13 4:50 AM To: Henry Lum Cc: Dan Wing; Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb On 6 May 2013, at 15:30, Henry Lum wrote: > Chiming in late. >=20 > Speaking from a contact center perspective, a lot of calls are required t= o be recorded. In order to allow active recording (such as SIPREC), the con= tact center has to provide a media endpoint for bridging media so that a co= py of the media can be created. The users will have to trust the contact ce= nter to handle the media anyways, and the media must be decrypted and re-en= crypted by some media element within the contact center to perform recordin= g. To me DTLS-SRTP-EKT does not provide any additional benefit over SDES fo= r this type of use case. It can provide an identity benefit. A bank contact center can offer an x509= certificate (from a trusted CA) over the DTLS media stream.=20 That's a big difference from the web server offering a cert over https - th= e channel that may be shared with the signalling channel, which in turn=20 may have set up the media. Direct assertion vs 2 uncertain hops. Of course the utility of that depends on the combined UX of the browser chr= ome and the site, but at least it is possible... There should perhaps be some extra chrome 'bling' if the cert that arrives = over DTLS matches the HTTPS one that brought the signalling. T. From dwing@cisco.com Tue May 7 09:06:59 2013 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 C2A5621F8F2C for ; Tue, 7 May 2013 09:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grR6O02hRo2y for ; Tue, 7 May 2013 09:06:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7121F8D0D for ; Tue, 7 May 2013 09:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2521; q=dns/txt; s=iport; t=1367942814; x=1369152414; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zSRXmUqYCDj3PSZPmmmZkt3LzQxXkqOIEmWfdDw1quk=; b=dgYhyK0cC8Lnm1legpJQwlJ5YUyiDapkJ4LXU+jEtPTeQfsbffYV45jB COok0nb2p0+f5KUiwI4CcRaGcI4PnjXiS/xtpTwN5aCM4LmyNuKEhlpM1 1lG6GhM8FEKzzN/ffgtr1l9i9lIOdxueGrNhEIDYGudztC5POd/Zpig+d c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAIkliVGrRDoJ/2dsb2JhbAA6DQmDBze/CYEIFnSCHwEBAQMBeQUHBAsRBAEBARMUB0YJCAYTiAYFsw6OQ41pD4EIMwcGgm5hA4kbikWDT4YXiyCDLhw X-IronPort-AV: E=Sophos;i="4.87,629,1363132800"; d="scan'208";a="80512949" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 May 2013 16:06:53 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r47G6q80023729; Tue, 7 May 2013 16:06:52 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Tue, 7 May 2013 09:06:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65B9872A-12D8-4CD3-85B6-DDCA13652D0C@cisco.com> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> To: Henry Lum X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:06:59 -0000 On May 7, 2013, at 7:55 AM, Henry Lum wrote: > Does the signalling and DTLS media stream need to use the same = certificate or the certificates No, DTLS-SRTP does not require they have the same certificate. It does = require the certificate fingerprint be sent in call signaling (in the = SDP a=3Dfingerprint line), and that the certificate exchanged in DTLS = match that fingerprint. This binds the call signaling to the media. -d > can be from the same organization right? The contact center gateway = and the recording element would be different components and hence have = different certificates from the same organization. >=20 > I agree it would be useful for a browser to warn the user that the = media stream is coming from a different identity than the signalling if = we agree that DTLS is the only transport. >=20 > Regards, > Henry >=20 > -----Original Message----- > From: Tim Panton [mailto:tim@phonefromhere.com]=20 > Sent: May-07-13 4:50 AM > To: Henry Lum > Cc: Dan Wing; Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb >=20 >=20 > On 6 May 2013, at 15:30, Henry Lum wrote: >=20 >> Chiming in late. >>=20 >> Speaking from a contact center perspective, a lot of calls are = required to be recorded. In order to allow active recording (such as = SIPREC), the contact center has to provide a media endpoint for bridging = media so that a copy of the media can be created. The users will have to = trust the contact center to handle the media anyways, and the media must = be decrypted and re-encrypted by some media element within the contact = center to perform recording. To me DTLS-SRTP-EKT does not provide any = additional benefit over SDES for this type of use case. >=20 > It can provide an identity benefit. A bank contact center can offer an = x509 certificate (from a trusted CA) over the DTLS media stream.=20 > That's a big difference from the web server offering a cert over https = - the channel that may be shared with the signalling channel, which in = turn=20 > may have set up the media. >=20 > Direct assertion vs 2 uncertain hops. >=20 > Of course the utility of that depends on the combined UX of the = browser chrome and the site, but at least it is possible... >=20 > There should perhaps be some extra chrome 'bling' if the cert that = arrives over DTLS matches the HTTPS one that brought the signalling. >=20 > T. >=20 >=20 From christer.holmberg@ericsson.com Tue May 7 10:03:31 2013 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 4E81B21F90A1; Tue, 7 May 2013 10:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9troQlxFrNe; Tue, 7 May 2013 10:03:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 59AB921F908B; Tue, 7 May 2013 10:03:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-f6-518933da845b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5A.68.28165.BD339815; Tue, 7 May 2013 19:03:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 7 May 2013 19:03:22 +0200 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOSw8clsjra9RECEqdCjXAKrt6wpj5iT9ggAAHEoCAAGIK0A== Date: Tue, 7 May 2013 17:03:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CBE1@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> <5188D9C5.3010209@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> <5188FCD3.9050306@alvestrand.no> In-Reply-To: <5188FCD3.9050306@alvestrand.no> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre5t485Ag0Or5S2O9XWxWWydKmQx dfljFou1/9rZHVg8rky4wuqxYFOpx5IlP5kCmKO4bFJSczLLUov07RK4Mj61f2MvaOWrWPWv hbGBsYO7i5GTQ0LAROL70l3sELaYxIV769m6GLk4hAQOM0rM/z2PFcJZzCjxcOoOli5GDg42 AQuJ7n/aIA0iAjoSD/c3MIHYzAJFEuffPmAEsYUFIiUatt9lgqiJkrh09ByU7STR170XzGYR UJG48vQEWD2vgK/ErS0fWCB27WeW2PlzPytIglNAV+LuvJMsIDYj0HXfT62BWiYu8eHgdWaI qwUkluw5D2WLSrx8/I8VwlaSaFzyhBWiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRj ZyFpmYWkZRaSlgWMLKsY2XMTM3PSyw03MQLj5+CW37o7GE+dEznEKM3BoiTOm8TVGCgkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBUaN7R7Xfnd2nlu9myHFdb5G778/cs8Gs146nXxe9l85p J/mct/7Umz6+KbtPCD+3miYn9W/ZukgFwQz7g10BSw89Oiul+eEJ58sLbFwf0nNiVDYXcF8L rgn/XuVgJZ/7guFB8juT3Ys/zymaGHU4Ra3YIVenrzn+Sc/Vu04++XsZ73S47Fl/TomlOCPR UIu5qDgRAPubvJptAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:03:31 -0000 Hi, =20 >>>> Q2_2_LEGACY: >>>> =20 >>>> The example in section 5.2 (and sub sections) confuses me a little. Yo= u indicate that the m- line itself represents "main", while ssrc >>>> attributes are used to describe the left/center/right mic sources. Why= is there no ssrc attribute for the main flow? >>> The MSID identifier is, by definition, meaningless. The association bet= ween the MSID and the function of the stream is not carried in >>> the MSID attribute. The example is a bit unfortunate in that it uses MS= IDs that look as if they're human-readable strings that carry semantics. >> I wasn't referring to the MSID identifier, but more to the fact that you= don't indicate the ssrc value for the "main" flow. I thought we were going= to mandate the indication of the ssrc value for each flow, but maybe I rem= ember wrong. > > I was trying to locate the flows in the example in section 5.2, and I=20 > couldn't find them anywhere but in the MSID attribute. So I couldn't=20 > parse your comment. > > The way I read the document, the first m=3Daudio line is the main audio;= =20 > it has 3 audio flows. > The first m=3Dvideo line is the main video; it has 3 video flows. > The third m=3Dvideo line is the slides video; it has 2 SSRCs, one for the= =20 > main flow and one for the repair flow. > > So - the issue seems to be that the word "main" as in "main audio" is=20 > easy to mistake for "a single main flow". It isn't intended to be that=20 > way. I guess the text could be clearer. That is how I understood it - that "main" is a flow by itself, separate fro= m the left/center/right mic flows :) Maybe "media description for main audio flows" would be a move clear descri= ption, rather than simply "main audio". Regards, Christer From martin.thomson@gmail.com Tue May 7 10:53:50 2013 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 313CE21F93D6 for ; Tue, 7 May 2013 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w8uIaNiSi3k for ; Tue, 7 May 2013 10:53:49 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 999C321F9385 for ; Tue, 7 May 2013 10:53:42 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x53so835626wes.19 for ; Tue, 07 May 2013 10:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=keRtU8sjFfT4kk+33wdM67s7a5YK6MJXZRnJ6/lRv7c=; b=zhnBYr6z7L1xuP17lZO26cpghO88VZ6CjulDZeOnQDENjJQrfiKYJJD9zJLU7OYAGw KYkhn06wnnCgJWbFfGuhtcVtFert71t7UclKs0pP0htuTaB6HIsCHv5BJUJIVMHVE24K Xam96lGDvcJkiB7+1k6vq4gPacq3bpoQsTLm/UaRUMF1FXRD8YoFG4VaBZvbvl+FucgM Jagrs+6tjH8Tg2b+FKwu56C17XrGk5iR3NU1HJa78/8eDScZwTa0YJSO4PgICALpnGxF fQKYeBBXV3vJWLpQk5h322/WG9cYEh6NpMFhl9aZWygOfFaMN/q9z0MDrY0r9WcgnHJY hzbQ== MIME-Version: 1.0 X-Received: by 10.194.78.204 with SMTP id d12mr5177323wjx.42.1367949221734; Tue, 07 May 2013 10:53:41 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Tue, 7 May 2013 10:53:41 -0700 (PDT) In-Reply-To: <65B9872A-12D8-4CD3-85B6-DDCA13652D0C@cisco.com> References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> <65B9872A-12D8-4CD3-85B6-DDCA13652D0C@cisco.com> Date: Tue, 7 May 2013 10:53:41 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:53:50 -0000 On 7 May 2013 09:06, Dan Wing wrote: > > On May 7, 2013, at 7:55 AM, Henry Lum wrote: > >> Does the signalling and DTLS media stream need to use the same certifica= te or the certificates > > No, DTLS-SRTP does not require they have the same certificate. It does r= equire the certificate fingerprint be sent in call signaling (in the SDP a= =3Dfingerprint line), and that the certificate exchanged in DTLS match that= fingerprint. This binds the call signaling to the media. That provides the "this is the call that I signaled" assertion. Identity is provided separately. As Tim points out, the certificate could be signed by a trusted CA and contain identity information. It might be the same identity as the signaling channel, but it doesn't have to be the same private key. Alternatively, identity could be provided by the generic IdP mechanism. Then the specific contents of the certificate are largely irrelevant. I wonder though. Is there any point in discussing the advantages of DTLS-SRTP on this thread? We already agree that it is MUST implement. Recording scenarios like this aren't especially interesting because mostly they occur beyond the point at which peer identity authentication occurs. The gateway decrypts the media and sends it to a recording point, or it just forwards it on with the necessary keys. I doubt very much that the recording element would need to be authenticated to the remote caller, unless recording is the only thing you plan on doing. From adam@nostrum.com Tue May 7 11:30:33 2013 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 1560621F870F for ; Tue, 7 May 2013 11:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiXx96F-Qupc for ; Tue, 7 May 2013 11:30:32 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D521F855A for ; Tue, 7 May 2013 11:30:32 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47IUU11010883 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 7 May 2013 13:30:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51894846.3090102@nostrum.com> Date: Tue, 07 May 2013 13:30:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:30:33 -0000 In order to facilitate discussion between the two SDP format alternatives we're considering, I've put together a document that more clearly spells out the Plan A approach as we originally envisioned it. Note that this is a slightly different approach than Cullen outlined in Orlando. I fear the Orlando approach may have suffered from its attempts to incorporate some elements of Plan B in an attempt to appease proponents of that approach; and, in doing so, lost some of its clean architecture. The cleaned up, new-and-improved description of the Plan A approach is available here: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt Note that we've omitted discussion of glare reduction from that document, as I believe that mid-session glare can be completely avoided by applications implementing a set of non-normative behaviors. These behaviors are described in the a separate companion document: http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks. /a From pkyzivat@alum.mit.edu Tue May 7 12:29:08 2013 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 D3FDE21F91B8 for ; Tue, 7 May 2013 12:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlZT0oBoeJOO for ; Tue, 7 May 2013 12:29:04 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 09EBC21F91D8 for ; Tue, 7 May 2013 12:29:03 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id Z0yY1l00117dt5G5D7V3BG; Tue, 07 May 2013 19:29:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Z7V31l00W3ZTu2S3Z7V3KP; Tue, 07 May 2013 19:29:03 +0000 Message-ID: <518955FE.9000801@alum.mit.edu> Date: Tue, 07 May 2013 15:29:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> In-Reply-To: <51894846.3090102@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367954943; bh=a2L8VW4d6SPDt4yWTb1JHaLo/tL4c3lnx37hxYSg4+U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VuvgBqJB/UVEk9jZKDe7rpodN2KtXIuzuvhOgVNg8Kyi1ds119NJn+iQDQH1tdR0Y s9aFRDbTKROqapn17t7a+dp13CEz62UTiBYHoBrVF0BnY3+f9fB29hA29150PoBTXh BOoL13LtVvuDk2a0fI11LmuZlkfN5apw6Q/5Lf0Glq1v97HB2k1Ces647wB9jRwrk/ LDoD/+0jIe1hH1F76mwdkunWDzJ11W/EXaGCIwdhHtSSl8yFkhrlw8nFTj9OxcUEMq OzQ7lTEv1sQaCnyN8VbiOmeJKO+DTUQHUwfAQk4jnebh18ac8dbr6JTRLSLqKESCvH g5TetZDXRPWbw== Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:29:08 -0000 Adam, I want to check on something: If I bundle an m-line without a=ssrc, and with unique PTs, do you consider it ok if there are multiple "anonymous" flows each complying to the attributes of the m-line? Or do you assume that all packets with that PT are treated as one flow, switching from one SSRC to another as they are received? Thanks, Paul On 5/7/13 2:30 PM, Adam Roach wrote: > In order to facilitate discussion between the two SDP format > alternatives we're considering, I've put together a document that more > clearly spells out the Plan A approach as we originally envisioned it. > Note that this is a slightly different approach than Cullen outlined in > Orlando. I fear the Orlando approach may have suffered from its attempts > to incorporate some elements of Plan B in an attempt to appease > proponents of that approach; and, in doing so, lost some of its clean > architecture. > > The cleaned up, new-and-improved description of the Plan A approach is > available here: > > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > > Note that we've omitted discussion of glare reduction from that > document, as I believe that mid-session glare can be completely avoided > by applications implementing a set of non-normative behaviors. These > behaviors are described in the a separate companion document: > > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > Thanks. > > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From christer.holmberg@ericsson.com Tue May 7 12:45:50 2013 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 B0A2D21F86AE for ; Tue, 7 May 2013 12:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbxKQpnqv6nD for ; Tue, 7 May 2013 12:45:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C233621F860B for ; Tue, 7 May 2013 12:45:38 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-65-518959e153c3 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6E.71.01956.1E959815; Tue, 7 May 2013 21:45:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 7 May 2013 21:45:36 +0200 From: Christer Holmberg To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Plan A, respun - bundle-only attribute Thread-Index: Ac5LW3FEeMc+OMbaQO+bvWbaIxtpCA== Date: Tue, 7 May 2013 19:45:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvre7DyM5Ag9+TZS32/F3EbrH2Xzu7 A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXx59MZxoLTwhWnr91laWDsFehi5OSQEDCR +P3nAjOELSZx4d56ti5GLg4hgcOMEt8a70E5ixklli7+BFTFwcEmYCHR/U8bpEFEwE1i47d3 7CC2sICNxJHzx5kg4rYSnY/eMkLYehKXL84Fi7MIqEjs+rkcbBmvgK/E/+mdrCA2I9Di76fW gNUwC4hLfDh4HeogAYkle85D2aISLx//Y4WwlSQalzxhhajXk7gxdQobhK0tsWzha6j5ghIn Zz5hmcAoPAvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLzTYzA0D645bfBDsZN98UOMUpzsCiJ 8yZzNQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGw9OPOM+f68+2cMXztIaLw33R+48EL2 k6c7X5nrM075tfzEPTH9izoJXscrl73a6Dfr8/U1sckz+a75VXzlsJJsecYiMb1vJ/PvWWvV 4yW3/HrFvePKVsefXet8/U9EldxLlOQ91X5lalj8weTA3V1N6xWNdvZ3OE25sGfnA3NRk9mr Wy68XO6nxFKckWioxVxUnAgAWoJ4ADsCAAA= Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:45:50 -0000 Hi, After couple of initial questions, related to the bundle-only attribute: Q1: You are adding m- lines with a zero port value into a BUNDLE group. RFC= 5888 (SDP grouping framework) currently explicitly forbids that, we have = discussed it on the MMUSIC list, and the outcome (eventhough there weren't = too many expressing their opinion) was that we were not going to allow zero= port m- lines in BUNDLE groups. Of course, we can always change that decision, but that would mean modifyin= g RFC 5888. Q2: It is indicated that devices that do not support BUNDLE will reject the= bundle-only m- lines, by setting the port value to zero in the SDP Answer.= That is probably true. But, what if the device DOES support BUNDLE as such= , but does NOT want to use the same port number? I think that e.g. a gatewa= y could act that way. In my opinion, as BUNDLE now uses 2 offer/answer transactions, the device c= ould be allowed to return different port values. Then the offerer, when sen= ding the second offer, can decide whether it wants to keep them. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta Adam Roach L=E4hetetty: 7. toukokuuta 2013 21:31 Vastaanottaja: rtcweb@ietf.org Aihe: [rtcweb] Plan A, respun In order to facilitate discussion between the two SDP format alternatives w= e're considering, I've put together a document that more clearly spells out= the Plan A approach as we originally envisioned it.=20 Note that this is a slightly different approach than Cullen outlined in Orl= ando. I fear the Orlando approach may have suffered from its attempts to in= corporate some elements of Plan B in an attempt to appease proponents of th= at approach; and, in doing so, lost some of its clean architecture. The cleaned up, new-and-improved description of the Plan A approach is avai= lable here: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt Note that we've omitted discussion of glare reduction from that document, a= s I believe that mid-session glare can be completely avoided by application= s implementing a set of non-normative behaviors. These behaviors are descri= bed in the a separate companion document: http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Tue May 7 13:00:54 2013 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 4D3FE21F86DE for ; Tue, 7 May 2013 13:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMUkCQKVpjwh for ; Tue, 7 May 2013 13:00:53 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 199F721F86CB for ; Tue, 7 May 2013 13:00:53 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47K0nGl021319 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 15:00:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51895D71.3090000@nostrum.com> Date: Tue, 07 May 2013 15:00:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> In-Reply-To: <518955FE.9000801@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:00:54 -0000 On 5/7/13 14:29, Paul Kyzivat wrote: > If I bundle an m-line without a=ssrc, and with unique PTs, do you > consider it ok if there are multiple "anonymous" flows each complying > to the attributes of the m-line? I presume, by "multiple anonymous flows," you mean multiple series of packets with the same PT, but with different SSRC values. > Or do you assume that all packets with that PT are treated as one > flow, switching from one SSRC to another as they are received? In the example you gave, all of those packets are defined to be associated with the same media line. Looking at basic principles, the intention here is that the semantics would be identical to non-webrtc, non-bundle clients receiving multiple SSRCs on the same port. Admittedly, those semantics have never been crystal clear, but my experience is that most systems would use this approach to send multiple streams that are semantically the same "thing" and should be rendered as one "thing" (e.g., window, speaker, etc). Specifically, we are *not* trying to allow the situation in which (1) the SDP has no SSRC for the m-lines in a bundle group; (2) the party who generated the SDP receives multiple streams (distinguished, presumably, by SSRC) with the same PT, and (3) the recipient then deduces that there should be two different rendering outputs (e.g., windows) as a result. That is specifically and intentionally one of the behaviors we removed from the Orlando proposal, since it severely dilutes the value of preserving existing SDP semantics. Does that answer the question you're answering? /a From worley@shell01.TheWorld.com Tue May 7 13:31:13 2013 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 5BF2621F912C for ; Tue, 7 May 2013 13:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRralv1Y6hYZ for ; Tue, 7 May 2013 13:31:07 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1D021F8E62 for ; Tue, 7 May 2013 13:31:07 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r47KUa1b018965; Tue, 7 May 2013 16:30:38 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r47KUapk4333693; Tue, 7 May 2013 16:30:36 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r47KUZkM4320466; Tue, 7 May 2013 16:30:35 -0400 (EDT) Date: Tue, 7 May 2013 16:30:35 -0400 (EDT) Message-Id: <201305072030.r47KUZkM4320466@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Bernard Aboba In-reply-to: (bernard_aboba@hotmail.com) References: <066.4c5db43349d3176acaa90d17617a02d6@trac.tools.ietf.org> <5173ECC7.7020909@jitsi.org> <51754363.3090300@ericsson.com> <201304222215.r3MMFqsE3199256@shell01.TheWorld.com> <201304231858.r3NIw4OJ3260483@shell01.TheWorld.com> <201304252220.r3PMKUjt3433388@shell01.TheWorld.com> <201304292159.r3TLxgYw3758081@shell01.TheWorld.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #15: Section 4.8: SSRC signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:31:13 -0000 > From: Bernard Aboba > > >> From: Martin Thomson > >> > >>> Each SSRC is demultiplexed based on an RTCP SDES item that gives > >>> the mapping between the SSRC and the m= line via which it is > >>> presented to the application layer (that is, the constituent m= > >>> line sequence number). > > > > a=ssrc attributes are not strictly needed, because RTCP packets > > contain SSRC identifiers, and RTP packets contain both SSRC and PT. > > So caching the SSRC/PT correspondence seen in the RTP packets allows > > the RTCP packets to be assigned to the proper m= lines. > > > > This matters because a=ssrc attributes are problematic; we want to > > add, remove, and adjust video flows without additional offer/answer > > cycles, which precludes adding or changing a=ssrc attributes in the > > SDP to handle the new flow. > > [BA] The PT/SSRC mapping only works if each PT maps to only one m= > line (and you don't run out of PTs). I miswrote above. The structure is this: You cache the SSRC->m= index associations that are seen in the incoming RTCP. When an RTP arrives, you use its SSRC to determine the proper m= index. The m= index, combined with the PT in the RTP, tells which codec is used, and provides a pointer to the other information carried in the SDP m= line section. It doesn't require the PTs used by each m= line to be different, because the m= indexes are determined from only the SSRCs. > Also, without a parameter in an > SDES report you might get a receiver report from an SSRC without > corresponding RTP packets to allow mapping the SSRC to an m= line. I'm not sure precisely what this means. Do you mean, "You might receive an RTCP receiver report that mentions an SSRC, without having received an SDES report about that SSRC"? I don't see any problem with receiving receiver reports, as they describe sources that this end has assigned SSRCs for. (If not, presumably they can be ignored.) There could be a problem with receiving a sender report, if this end hasn't received an SDES telling which m= line the sender report corresponds to. But the far end can ensure that it has sent an SDES describing the SSRC before it sends a sender report describing that SSRC. Dale From christer.holmberg@ericsson.com Tue May 7 13:39:29 2013 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 F3FF621F9049 for ; Tue, 7 May 2013 13:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kIppNIj1nQk for ; Tue, 7 May 2013 13:39:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 033E621F8F32 for ; Tue, 7 May 2013 13:39:21 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-7b-51896678b840 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DF.24.01956.87669815; Tue, 7 May 2013 22:39:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 7 May 2013 22:39:20 +0200 From: Christer Holmberg To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Plan A, respun - bundle-only attribute Thread-Index: Ac5LW3FEeMc+OMbaQO+bvWbaIxtpCAABvyFA Date: Tue, 7 May 2013 20:39:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvrW5FWmegwZpD5hZ7/i5it1j7r53d gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mq4t+wFS8EFyYrDvxQbGGeIdjFyckgImEhs On+YHcIWk7hwbz1bFyMXh5DAYUaJYzvOsEA4ixklbjevAqri4GATsJDo/qcN0iAi4Cax8ds7 sGZhARuJI+ePM0HEbSU6H71lBCkXETCSWH5UHiTMIqAiMeNKA1gJr4CvxOEZy1lBbCEg+/nS TYwgNqeAn8Szj1NZQGxGoHu+n1oDVs8sIC7x4eB1Zog7BSSW7DkPZYtKvHz8jxXCVpL4seES C0S9nsSNqVPYIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSX m29iBMbBwS2/DXYwbrovdohRmoNFSZw3masxUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj wBsbn6mhiVzX2i5Pqbn3Wvqak8T2KU+CHDwVP8Vs4XH5vSPrNn/k6RMrT1/1O61sHDLnWcwT w81X14dUcNoeyX7o/HbS0gkRF4ti5T6baERe2sJ6kD8sY9H65vITbXIz7eSPbZy8+62vkd+V mUfmGZybHaY+MSL1ft6rL9Oi1HMn14fKfBVYqMRSnJFoqMVcVJwIADYeFr1RAgAA Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:39:29 -0000 Hi, One more question, regarding the bundle-only attribute: Q3: Assume the answerer supports BUNDLE, and return an SDP answer with iden= tical port numbers, as shown in section 7.1. I guess the second offer will = then replace the zero port lines with the actual port value that the offere= r uses for the multiplexing? Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta Christer Holmberg L=E4hetetty: 7. toukokuuta 2013 22:46 Vastaanottaja: Adam Roach; rtcweb@ietf.org Aihe: Re: [rtcweb] Plan A, respun - bundle-only attribute Hi, After couple of initial questions, related to the bundle-only attribute: Q1: You are adding m- lines with a zero port value into a BUNDLE group. RFC= 5888 (SDP grouping framework) currently explicitly forbids that, we have = discussed it on the MMUSIC list, and the outcome (eventhough there weren't = too many expressing their opinion) was that we were not going to allow zero= port m- lines in BUNDLE groups. Of course, we can always change that decision, but that would mean modifyin= g RFC 5888. Q2: It is indicated that devices that do not support BUNDLE will reject the= bundle-only m- lines, by setting the port value to zero in the SDP Answer.= That is probably true. But, what if the device DOES support BUNDLE as such= , but does NOT want to use the same port number? I think that e.g. a gatewa= y could act that way. In my opinion, as BUNDLE now uses 2 offer/answer transactions, the device c= ould be allowed to return different port values. Then the offerer, when sen= ding the second offer, can decide whether it wants to keep them. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta Adam Roach L=E4hetetty: 7. toukokuuta 2013 21:31 Vastaanottaja: rtcweb@ietf.org Aihe: [rtcweb] Plan A, respun In order to facilitate discussion between the two SDP format alternatives w= e're considering, I've put together a document that more clearly spells out= the Plan A approach as we originally envisioned it.=20 Note that this is a slightly different approach than Cullen outlined in Orl= ando. I fear the Orlando approach may have suffered from its attempts to in= corporate some elements of Plan B in an attempt to appease proponents of th= at approach; and, in doing so, lost some of its clean architecture. The cleaned up, new-and-improved description of the Plan A approach is avai= lable here: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt Note that we've omitted discussion of glare reduction from that document, a= s I believe that mid-session glare can be completely avoided by application= s implementing a set of non-normative behaviors. These behaviors are descri= bed in the a separate companion document: http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks. /a _______________________________________________ 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 adam@nostrum.com Tue May 7 13:46:33 2013 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 3285B21F8E96 for ; Tue, 7 May 2013 13:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0R37BP0-i-y for ; Tue, 7 May 2013 13:46:32 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3B821F8E7B for ; Tue, 7 May 2013 13:46:32 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47KkSBj026643 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 15:46:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51896824.2000705@nostrum.com> Date: Tue, 07 May 2013 15:46:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:46:33 -0000 On 5/7/13 15:39, Christer Holmberg wrote: > Q3: Assume the answerer supports BUNDLE, and return an SDP answer with identical port numbers, as shown in section 7.1. I guess the second offer will then replace the zero port lines with the actual port value that the offerer uses for the multiplexing? I don't think it really matters, since the port number in these subsequent offers don't convey any additional information, but I'm perfectly happy with the behavior you describe. I'm also happy keeping them set to zero, or specifying that they should be floor(pi * 10000) or any other arbitrary value. Yeah, I'm pretty sure it doesn't actually matter. /a From pkyzivat@alum.mit.edu Tue May 7 13:59:07 2013 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 9DAA221F92F5 for ; Tue, 7 May 2013 13:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BhfF-V+jkUo for ; Tue, 7 May 2013 13:59:03 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id CE00D21F87D2 for ; Tue, 7 May 2013 13:58:59 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id YyCd1l00C17dt5G538yyKD; Tue, 07 May 2013 20:58:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Z8yy1l00W3ZTu2S3Z8yyKL; Tue, 07 May 2013 20:58:58 +0000 Message-ID: <51896B12.8090203@alum.mit.edu> Date: Tue, 07 May 2013 16:58:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367960338; bh=kKOHgTwB4BAFQhYhXIrj/W6RJ+hoCoTI2WbgRSx2HrI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M7AShtErJbsBiGDi0o1wyBeE0o+LYMj/0O6wf7CRVyUMljzg5789Y5TzV8RPb8BCL 5VSUT79QCFf6agw6T6hjp5ihjKMrKoI77XLFb72B91iLPX4FF5HRLobktNcepfHdQP CUXbuaZuP+MPg7PzgMzA5tlNGY8ipD3csbVO6sUVz2E0hlU3oPIpbvaGY5LKy8dGET 6OBbJSdm3QsmQAX61veYvwQVUUzaLKD6Pf14/url6WZVCCX1eVH8+IMPxKjO++xiCv XnYtHn2CRhunLwf1AOPWK1pKK0ZmwerB+RNZ8+A8sfxDQLp+7rhu0Jstv/hXkkpBV1 Rnoqve6MSNdTg== Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:59:07 -0000 Jason, (I removed the cross posting) I started a thread in mmusic about "bundle splitting". It is predicated on the assumption that the offerer may propose to bundle some m-lines that the answerer can't handle if bundled together. But it could handle some smaller bundles of the same m-lines. With "Plan A" that should be enough to solve the problem. With the Plan B described here, there is a variant of that. The offerer may offer an m-line with several SSRCs. The answerer wants those "flows", but may not be able to handle them in the same m-line. (It needs to receive them at different addresses, corresponding to separate hardware.) In my earlier posting, I proposed that a subset of the bundled m-lines that can be received at a single address be accepted, and the others refused in the answer. And that then there be a new offer in the reverse direction, accepting those same m-lines, but bundling them separately. The assumption here is that they will still be identified as being associated with the same flows. Would something analogous work with Plan B as you see it? The initial answerer would need to refuse SSRCs. Then it would need to send a new offer, with a separate m-line, and include something indicating the flows it wanted there. It could use the same MSIDs, but it can't necessarily use a=ssrc with the original SSRCs, because the new m-line is a separate SSRC space. This may work, but the details elude me. I also have a concern about use of ssrc-group for multicast. That only works if the all the members of the multicast group share the same m-line (or at least the same bundle.) That may not always be the case. When it does't, we need a more generalized grouping, that can reference specific SSRCs in different m-lines. Thanks, Paul > ---------- Forwarded message ---------- > From: Justin Uberti > Date: Fri, May 3, 2013 at 1:08 AM > Subject: [rtcweb] Fwd: New Version Notification for > draft-uberti-rtcweb-plan-00.txt > To: "rtcweb@ietf.org" , "mmusic@ietf.org" > > > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Tue May 7 14:00:55 2013 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 2F7E121F881C for ; Tue, 7 May 2013 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36iaD+ce3g0H for ; Tue, 7 May 2013 14:00:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61E21F8651 for ; Tue, 7 May 2013 14:00:45 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-1d-51896b7c0833 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F2.45.01956.C7B69815; Tue, 7 May 2013 23:00:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Tue, 7 May 2013 23:00:44 +0200 From: Christer Holmberg To: Adam Roach Thread-Topic: VS: [rtcweb] Plan A, respun - bundle-only attribute Thread-Index: Ac5LW3FEeMc+OMbaQO+bvWbaIxtpCAABvyFA///hggD//9sDAA== Date: Tue, 7 May 2013 21:00:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CE1B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> In-Reply-To: <51896824.2000705@nostrum.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW5NdmegwYKZehZ7/i5it1j7r53d gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MroXrGErWAWW0XfvomMDYyfWLoYOTkkBEwk TjWsgLLFJC7cW8/WxcjFISRwmFGiu+MqO0hCSGAxo8TX1bpdjBwcbAIWEt3/tEHCIgKKEm2H bzKD2MwC6hJ3Fp8DKxcWcJA4u3I5E0SNo8SZ/hmsIK0iAk4Sb19WgYRZBFQk9u94zApi8wr4 SpxbfYUJYu0mRoklc18zgiQ4BbQlzl35DFbECHTb91NrmCB2iUt8OHidGeJmAYkle85D2aIS Lx//Y4WwlSR+bLjEAlGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nL AkaWVYzsuYmZOenl5psYgRFycMtvgx2Mm+6LHWKU5mBREudN5moMFBJITyxJzU5NLUgtii8q zUktPsTIxMEp1cCofq9UesMXgwz1aw76HQLilg/EjZKZNs1+xJG2bcGq+LWpp0uVektKPS2d piR0bV1V9lvXLcBHTv2Q/13R+Jesq/8feKs3r9jnjvfVYv51C78HZLGsDbfZ62HTm8oqdLl7 7s17999zb57FsK87mlf59huz55WqHAFFd/Xc1pmyLmZPWnzvKKsSS3FGoqEWc1FxIgBiMAvi XgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:00:55 -0000 Hi, >> Q3: Assume the answerer supports BUNDLE, and return an SDP answer with i= dentical port numbers, as shown in section 7.1. I guess the second offer wi= ll=20 >> then replace the zero port lines with the actual port value that the off= erer uses for the multiplexing? > > I don't think it really matters, since the port number in these subsequen= t offers don't convey any additional information, but I'm perfectly happy w= ith=20 > the behavior you describe. I'm also happy keeping them set to zero, or sp= ecifying that they should be floor(pi * 10000) or any other arbitrary value= . Good - I just wanted to make sure that we stick to the agreed way forward o= n BUNDLE, which is based on sending a second offer with the actual port val= ue. Regards, Christer From pkyzivat@alum.mit.edu Tue May 7 14:09:45 2013 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 335AF21F9254 for ; Tue, 7 May 2013 14:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE7muojvIL6z for ; Tue, 7 May 2013 14:09:39 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 36BCB21F8AD5 for ; Tue, 7 May 2013 14:09:39 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id Z8op1l0031ap0As5A99eva; Tue, 07 May 2013 21:09:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id Z99e1l00W3ZTu2S3i99eRo; Tue, 07 May 2013 21:09:38 +0000 Message-ID: <51896D91.9070004@alum.mit.edu> Date: Tue, 07 May 2013 17:09:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> In-Reply-To: <51895D71.3090000@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367960978; bh=XyzlJzWGCz/dBJ7xx5iD2QsHUAByTq7O5znWlE4Ceig=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fQgw5/pHrAdPqDDFoh2ulVA04zBREeSP3b/6UPG5I1FamcX09Zs8BuEZG/V4nsnm2 4AS/32vEoRyrvX8Lr+Jtoe3UHX8cYE5/JwuYNHx1r9TIquH3D2qOfv5QBuqzo3MP+o 5V9w0P2EmQmQfuhGwF1SZCAVUpKMTXAIvT2o7S+k9IE9BkZnu+aJxL7afWprzq69Yc LnKKSRGeRiKZopTH8UMlHkUgdU/Zx0TLJRFxvYxjcD1wQ1tTlX86H6dgKXPlwHBFuP KOtfPJSWSUTWzLDHLf4/fYrZ/EHIqFlSqDU6CQ5LyL+mqq3ge5B4C9fLFNuD7IVsJB 88q8eX343rgvg== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:09:45 -0000 On 5/7/13 4:00 PM, Adam Roach wrote: > On 5/7/13 14:29, Paul Kyzivat wrote: >> If I bundle an m-line without a=ssrc, and with unique PTs, do you >> consider it ok if there are multiple "anonymous" flows each complying >> to the attributes of the m-line? > > I presume, by "multiple anonymous flows," you mean multiple series of > packets with the same PT, but with different SSRC values. > >> Or do you assume that all packets with that PT are treated as one >> flow, switching from one SSRC to another as they are received? > > In the example you gave, all of those packets are defined to be > associated with the same media line. Looking at basic principles, the > intention here is that the semantics would be identical to non-webrtc, > non-bundle clients receiving multiple SSRCs on the same port. > Admittedly, those semantics have never been crystal clear, but my > experience is that most systems would use this approach to send multiple > streams that are semantically the same "thing" and should be rendered as > one "thing" (e.g., window, speaker, etc). > > Specifically, we are *not* trying to allow the situation in which (1) > the SDP has no SSRC for the m-lines in a bundle group; (2) the party who > generated the SDP receives multiple streams (distinguished, presumably, > by SSRC) with the same PT, and (3) the recipient then deduces that there > should be two different rendering outputs (e.g., windows) as a result. > That is specifically and intentionally one of the behaviors we removed > from the Orlando proposal, since it severely dilutes the value of > preserving existing SDP semantics. > > Does that answer the question you're answering? Yes, that exactly answers the question I was asking. It fits a clue case, of a "dynamic switched capture", where a single logical flow (capture) may be conveyed via unknown SSRCs. But it doesn't cope well with a case where there a several of those, because each will require distinct PTs, and that may not work. To adequately cover that, I think we need the potential to signal a *different* demux algorithm, instead of PT or SSRC. (We are assuming a new RTP header extension). Bottom line, instead of saying the demux is by ssrc if present, and otherwise by PT, I suggest that we explicitly signal the demux mechanism, with options being at least those, plus another one once we get it defined. Otherwise I think what you are proposing can work for CLUE. Thanks, Paul From ekr@rtfm.com Tue May 7 14:13:33 2013 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 225C721F90AF for ; Tue, 7 May 2013 14:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.425 X-Spam-Level: X-Spam-Status: No, score=-100.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTPdJH5ZreEQ for ; Tue, 7 May 2013 14:13:28 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ED20921F8EFD for ; Tue, 7 May 2013 14:13:27 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id k15so579775qcv.2 for ; Tue, 07 May 2013 14:13:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=aUYOYaSExHp3DmMJC0MbYoErXiqJI0z7GcFm0AIrKss=; b=FcaufrEST02KStzCZSbabHypvYQVLg182RR8lY6dugKKqtHOmfwQKQaErHd6behHpv Ip9RVQLyQB48icoibAISaDwed+jwFQSHaYb2XYfggGKhWtMDjNUvOvzKWMSj0NPmAmPI FeFjEqrAe75/XnqLPcL7B7+MwXa07+8mJYgt6NQCdoJjjakTGW8aDJ1fJnfAp394FNO7 Fha1nafVcaXQIXGDsISBJaLxrzi9Z3BakD0FO13DjYJwvrkRQHD86rZEPzhKi1QKCraw vHJwtmufvAeUc4onSM65gblFMrpp/k7TUKuGcGIUzpjzFw5DNsqo/2terbYufB5OZf/0 Dj1g== X-Received: by 10.229.136.68 with SMTP id q4mr1078628qct.54.1367961207238; Tue, 07 May 2013 14:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.18.231 with HTTP; Tue, 7 May 2013 14:12:47 -0700 (PDT) X-Originating-IP: [169.228.176.186] In-Reply-To: <51896D91.9070004@alum.mit.edu> References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> From: Eric Rescorla Date: Tue, 7 May 2013 14:12:47 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=00248c6a6566d3426304dc274951 X-Gm-Message-State: ALoCoQkLIiAR8BcQlJ09wqetUsgNB6hggT38cG/h6uec1emLEl99aJAcGwM84VYYxhcFGUwOy+cA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:13:33 -0000 --00248c6a6566d3426304dc274951 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 2:09 PM, Paul Kyzivat wrote: > > Yes, that exactly answers the question I was asking. > > It fits a clue case, of a "dynamic switched capture", where a single > logical flow (capture) may be conveyed via unknown SSRCs. > > But it doesn't cope well with a case where there a several of those, > because each will require distinct PTs, and that may not work. > > To adequately cover that, I think we need the potential to signal a > *different* demux algorithm, instead of PT or SSRC. (We are assuming a new > RTP header extension). > So your thinking is that the offerer would say something like m=audio a=demux-token:ABC m=video a=demux-token:DEF And then at that point he would need to be prepared to demux RTP packets with header extension [demux=ABC], etc.? -Ekr --00248c6a6566d3426304dc274951 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 7, 2013 at 2:09 PM, Paul Kyz= ivat <pkyzivat@alum.mit.edu> wrote:
Yes, that exactly answers the question I was asking.

It fits a clue case, of a "dynamic switched capture", where a sin= gle logical flow (capture) may be conveyed via unknown SSRCs.

But it doesn't cope well with a case where there a several of those, be= cause each will require distinct PTs, and that may not work.

To adequately cover that, I think we need the potential to signal a *differ= ent* demux algorithm, instead of PT or SSRC. (We are assuming a new RTP hea= der extension).

So your thinking is tha= t the offerer would say something like

m=3Daudio
a=3Ddemux-token:ABC

<= /div>
m=3Dvideo
a=3Ddemux-token:DEF

=
And then at that point he would need to be prepared to demux=
RTP packets with header extension [demux=3DABC], etc.?

<= /div>
-Ekr

--00248c6a6566d3426304dc274951-- From ted.ietf@gmail.com Tue May 7 14:17:39 2013 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 003B821F90AF for ; Tue, 7 May 2013 14:17:38 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLLFroV9Egpj for ; Tue, 7 May 2013 14:17:38 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0DC21F905F for ; Tue, 7 May 2013 14:17:38 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id e36so1157355iag.5 for ; Tue, 07 May 2013 14:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=StDMqXrceflOhkMKBiNEsl1ojgtG2KwK8BrenxwBzSg=; b=dompqbb7YCwqxMLvUhWAm6pwJoS7Ff1Sj3nm8INeIYBvGD7+wWEHeBGvr8pC4sPF4Y fnZXgEkf40Or9q0yuyvrxKs3oukL03eC7pDIEmMI0sp38ba4d6v4w1/ZyoKoz6vTJKW7 FrOfIqZb6gtynLjt/3kSw3DSZokLlPLUp1LlA8Rbb28npeLE1+XGYHkSK5UNmG5rHf4v M+BhvMp8S77EcWSM9m2muI4a7TiDreNq+HnSru96Jv0h99F8K9aNySuoc5LMhigNFPAb /jRtTIXN8AVWClMIff82ux7jWLwP2wsdvTKpjJq1ADeppK/ZVfXCPUnB/IrBbXeigkP6 tGkA== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr4728778igj.96.1367961457983; Tue, 07 May 2013 14:17:37 -0700 (PDT) Received: by 10.42.211.16 with HTTP; Tue, 7 May 2013 14:17:37 -0700 (PDT) Date: Tue, 7 May 2013 14:17:37 -0700 Message-ID: From: Ted Hardie To: Adam Roach , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=14dae934032bc50d0b04dc275883 Subject: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:17:39 -0000 --14dae934032bc50d0b04dc275883 Content-Type: text/plain; charset=ISO-8859-1 Hi Adam, Taking the first look at this, there were two quick issues I wanted to mention. The first is this text: "In the offer-answer model used by RTCWEB, "glare" arises when offer messages "cross on the wire" (that is, both parties in a session attempt to change the session at the same time)." While RTCWEB is being built to support offer/answer, there is no requirement that an application use that model for the interaction between two clients. So, this wording might need to get a tweak. Second, it seems like the avoidance of glare by having a single offer/answerer at a time would work in most cases, but I'm wondering why the initial exchange isn't simply a request to change roles? If the initial offer role is determined by time, one of the options seems to be to accede to a request by the other client to become the offerer. Is this because you're concerned that it would add a round trip? If so, would including the "potential offer" with the request to change role solve that problem? regards, Ted --14dae934032bc50d0b04dc275883 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adam,

Taking the first look at this, there were two quick issues = I wanted to
mention.=A0 The first is this text:

"In the off= er-answer model used by RTCWEB, "glare" arises when
offer messages "cross on the wire" (that is, both parties in a sessi= on
attempt to change the session at the same time)."

While = RTCWEB is being built to support offer/answer, there is no
requirement t= hat an application use that model for the interaction
between two client= s.=A0 So, this wording might need to get a tweak.

Second, it seems like the avoidance of glare by having a single
offe= r/answerer at a time would work in most cases, but I'm wondering
why= the initial exchange isn't simply a request to change roles?=A0=A0 If<= br> the initial offer role is determined by time, one of the options seems tobe to accede to a request by the other client to become the offerer.=A0 I= s
this because you're concerned that it would add a round trip?=A0 I= f so,
would including the "potential offer" with the request to change = role
solve that problem?

regards,

Ted
--14dae934032bc50d0b04dc275883-- From bernard_aboba@hotmail.com Tue May 7 14:45:03 2013 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 CF7B021F91B0 for ; Tue, 7 May 2013 14:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq-AjisTLCiP for ; Tue, 7 May 2013 14:44:56 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9584B21F912C for ; Tue, 7 May 2013 14:44:56 -0700 (PDT) Received: from BLU169-W42 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 14:44:56 -0700 X-EIP: [SXuLA96QGEWTKw19I1/m+A4SjizflPTslu+z0h12QX8=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ec29dd5c-2a83-4cad-a492-86bbb5a84cf8_" From: Bernard Aboba To: Adam Roach Date: Tue, 7 May 2013 14:44:55 -0700 Importance: Normal In-Reply-To: <51896D91.9070004@alum.mit.edu> References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>, <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 21:44:56.0270 (UTC) FILETIME=[1D6F2EE0:01CE4B6C] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:45:03 -0000 --_ec29dd5c-2a83-4cad-a492-86bbb5a84cf8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam Roach said: > Specifically=2C we are *not* trying to allow the situation in which (1) > the SDP has no SSRC for the m-lines in a bundle group=3B (2) the party wh= o > generated the SDP receives multiple streams (distinguished=2C presumably= =2C > by SSRC) with the same PT=2C and (3) the recipient then deduces that ther= e > should be two different rendering outputs (e.g.=2C windows) as a result. > That is specifically and intentionally one of the behaviors we removed > from the Orlando proposal=2C since it severely dilutes the value of > preserving existing SDP semantics. The "existing SDP semantics" have allowed multiplexing of RTP streams from = multiple SSRCs on the=20 same RTP session without explicit declaration since multicast days -- and t= his behavior is implemented within a number of shipping video implementatio= ns. In fact=2C dealing with this is proposed as a MUST within the RTP Usag= e document.=20 If an event is triggered for a newly encountered (but undeclared) SSRC=2C t= his can be handled by the web application which can take care of making sur= e that new RTP stream is appropriately rendered. Applications (including o= pen source ones=2C such as Jitsi) do this today. =20 = --_ec29dd5c-2a83-4cad-a492-86bbb5a84cf8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Adam Roach said:

>= =3B Specifically=2C we are *not* trying to allow the situation in which (1)=
>=3B the SDP has no SSRC for the m-lines in a bundle group=3B (2) the= party who
>=3B generated the SDP receives multiple streams (distingui= shed=2C presumably=2C
>=3B by SSRC) with the same PT=2C and (3) the re= cipient then deduces that there
>=3B should be two different rendering= outputs (e.g.=2C windows) as a result.
>=3B That is specifically and = intentionally one of the behaviors we removed
>=3B from the Orlando pr= oposal=2C since it severely dilutes the value of
>=3B preserving exist= ing SDP semantics.

The "existing SDP semantics" have allowed multipl= exing of RTP streams from multiple SSRCs on the
same RTP session withou= t explicit declaration since multicast days -- and this behavior is impleme= nted within a number of shipping video implementations. =3B In fact=2C = dealing with this is proposed as a MUST within the RTP Usage document.
=
If an event is triggered for a newly encountered (but undeclared) SSRC= =2C this can be handled by the web application which can take care of makin= g sure that new RTP stream is appropriately rendered. =3B Applications = (including open source ones=2C such as Jitsi) do this today. =3B
= --_ec29dd5c-2a83-4cad-a492-86bbb5a84cf8_-- From bernard_aboba@hotmail.com Tue May 7 14:56:18 2013 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 8B9BD21F8F2C; Tue, 7 May 2013 14:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15y4-BNv82iq; Tue, 7 May 2013 14:56:11 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5AD21F8F03; Tue, 7 May 2013 14:56:11 -0700 (PDT) Received: from BLU169-W108 ([65.55.111.73]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 14:56:10 -0700 X-EIP: [izp0FB9rnfTVCJ71FBPs+TcF4RFmoqVd5NwWkxvuy8M=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a6681fa6-d553-4a7a-9cfe-d3526eb65904_" From: Bernard Aboba To: Roni Even , 'Justin Uberti' , "rtcweb@ietf.org" , "mmusic@ietf.org" Date: Tue, 7 May 2013 14:56:10 -0700 Importance: Normal In-Reply-To: <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 21:56:10.0889 (UTC) FILETIME=[AF89DF90:01CE4B6D] Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:56:18 -0000 --_a6681fa6-d553-4a7a-9cfe-d3526eb65904_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni said: =20 3. The draft=2C as far as I can tell=2C is discussing point to point = calls and full meshed conferences. I think we need to look at other topolog= ies including a centralized MCU doing video switch=2C for example. [BA] There should be an evaluation against the RTP topology bis draft which= would include assessment of compatibility. In addition to "video switch" = I would be interested in RTP translator compatibility as well.=20 4. In section 4.1 you suggest using the MSID as an indication for sup= porting plan B. I think that this may be RTCWEB specific and other usages l= ike CLUE may use a different way to associate an SSRC to a Media Capture. M= y proposal is to use maxssrc.=20 [BA] Among other things=2C putting maxssrc in the Offer partially addresses= the issue of being able to receive streams before the Answer is received. = However=2C since the Offerer will not know the SSRCs that it is expected t= o receive there has got to be a way to map the incoming streams to WebRTC m= ediastreams. =20 5. I have a question about the last paragraph of section 4.2. Current= ly the answerer can start sending media immediately when getting the offer = in parallel to sending the SDP answer since the offer includes receive capa= bilities and receive transport address. Are you suggesting that media will = flow only after the 3 way handshake? [BA] Yes=2C I think that is the implication=2C though it doesn't seem eithe= r necessary or desirable to me. Actually=2C I don't think that "Peer B" wi= ll be able to send until it gets an Answer to its Offer (the second Offer/A= nswer exchange)=2C because it won't know what streams "Peer A" is prepared = to accept (assuming there is no maxssrc in the initial offer). =20 = --_a6681fa6-d553-4a7a-9cfe-d3526eb65904_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roni said:

 =3B


3.&= nbsp=3B =3B =3B =3B =3B =3B The draft=2C= as far as I can tell=2C is discussing point to point calls and full meshed= conferences. I think we need to look at other topologies including a centr= alized MCU doing video switch=2C for example.


[BA] There should be an evaluation against the RTP to= pology bis draft which would include assessment of compatibility. =3B I= n addition to "video switch" I would be interested in RTP translator compat= ibility as well.


4. =3B =3B =3B =3B =3B =3B In section 4.1 you suggest using the MSID as an indication for support= ing plan B. I think that this may be RTCWEB specific and other usages like = CLUE may use a different way to associate an SSRC to a Media Capture. My pr= oposal is to use maxssrc.

=


[BA] Among = other things=2C putting maxssrc in the Offer partially addresses the issue = of being able to receive streams before the Answer is received. =3B How= ever=2C since the Offerer will not know the SSRCs that it is expected to re= ceive there has got to be a way to map the incoming streams to WebRTC media= streams.  =3B



5. =3B =3B =3B =3B =3B =3B I h= ave a question about the last paragraph of section 4.2. Currently the answe= rer can start sending media immediately when getting the offer in parallel = to sending the SDP answer since the offer includes receive capabilities and= receive transport address. Are you suggesting that media will flow only af= ter the 3 way handshake?


=

[BA] Yes=2C I think that is the implication=2C though it doesn't= seem either necessary or desirable to me. =3B Actually=2C I don't thin= k that "Peer B" will be able to send until it gets an Answer to its Offer (= the second Offer/Answer exchange)=2C because it won't know what streams "Pe= er A" is prepared to accept (assuming there is no maxssrc in the initial of= fer). =3B



= --_a6681fa6-d553-4a7a-9cfe-d3526eb65904_-- From bernard_aboba@hotmail.com Tue May 7 15:02:17 2013 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 7E47A21F905F; Tue, 7 May 2013 15:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8VzJSP47cD9; Tue, 7 May 2013 15:02:11 -0700 (PDT) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8D49121F86F0; Tue, 7 May 2013 15:02:11 -0700 (PDT) Received: from BLU169-W108 ([65.55.116.9]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 15:02:09 -0700 X-EIP: [z+ikBbIH0mZ0gFFuDSFbCAnQhucye7spSp/gk4LOp2Y=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f739abbd-a421-4394-b155-2762a690f704_" From: Bernard Aboba To: Harald Alvestrand , Roni Even Date: Tue, 7 May 2013 15:02:09 -0700 Importance: Normal In-Reply-To: <518900CF.6050403@alvestrand.no> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 22:02:09.0543 (UTC) FILETIME=[85502170:01CE4B6E] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:02:17 -0000 --_f739abbd-a421-4394-b155-2762a690f704_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni said:=20 I=0A= think that plan B is the right direction. I am wondering if=0A= this should be discussed in RTCWEB or MMUSIC=0A= =0A= =0A= =20 =0A= To the extent that the proposals are attempts to "profile" existing RFC= s or MMUSIC work in progress for use in WebRTC=2C it seems to me like the d= iscussion belongs in RTCWEB. One advantage of that approach is that the sol= ution need not necessarily apply to "all uses of SDP for any scenario for a= ll time"=2C just to the WebRTC use cases.=20 To the extent that NEW SDP functionality is needed=2C MMUSIC discussion wou= ld be appropriate. But until the general direction is decided=2C it won't = be clear what the required new functionality is (if any). =20 =0A= =20 =0A= =0A= =0A= =20 = --_f739abbd-a421-4394-b155-2762a690f704_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roni said:

I=0A= think that plan B is the right direction. I am wondering if=0A= this should be discussed in RTCWEB or MMUSIC

=0A=
=0A= =0A=
=0A= To the extent that the proposals are attempts to "profile" existing RFC= s or MMUSIC work in progress for use in WebRTC=2C it seems to me like the d= iscussion belongs in RTCWEB. One advantage of that approach is that the sol= ution need not necessarily apply to "all uses of SDP for any scenario for a= ll time"=2C just to the WebRTC use cases.

To the extent that NEW SD= P functionality is needed=2C MMUSIC discussion would be appropriate. = =3B But until the general direction is decided=2C it won't be clear what th= e required new functionality is (if any). =3B
=0A=
=0A=
=0A=
=0A=


= --_f739abbd-a421-4394-b155-2762a690f704_-- From adam@nostrum.com Tue May 7 15:07:19 2013 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 E499821F91CF for ; Tue, 7 May 2013 15:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw9ev7uiksCc for ; Tue, 7 May 2013 15:07:19 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3707D21F912C for ; Tue, 7 May 2013 15:07:18 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47M7DkP035640 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 17:07:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51897B11.60004@nostrum.com> Date: Tue, 07 May 2013 17:07:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:07:20 -0000 On 5/7/13 16:17, Ted Hardie wrote: > Taking the first look at this, there were two quick issues I wanted to > mention. The first is this text: > > "In the offer-answer model used by RTCWEB, "glare" arises when > offer messages "cross on the wire" (that is, both parties in a session > attempt to change the session at the same time)." > > While RTCWEB is being built to support offer/answer, there is no > requirement that an application use that model for the interaction > between two clients. I'm not sure that's right. When calling setRemoteDescription / setLocalDescription, the RTCSessionDescription objects contain a mandatory "type" field that must be "offer", "answer", or "pranswer." This really makes the 3264 offer/answer model pretty thoroughly baked into the system. > So, this wording might need to get a tweak. If I'm wrong above, I'm happy to take text that explains this fact. I can't craft any right now, since I don't know how you would set up a WebRTC session (I say WebRTC since we're really talking about the API side of things here) without use of offer/answer. > Second, it seems like the avoidance of glare by having a single > offer/answerer at a time would work in most cases, but I'm wondering > why the initial exchange isn't simply a request to change roles? If > the initial offer role is determined by time, one of the options seems to > be to accede to a request by the other client to become the offerer. That's an interesting approach that certainly works just fine. It's probably worth documenting as an alternative. One thing to note is that the technique described in my draft is something applications can apply unilaterally without any standardization work; whether they choose to perform a solicitation/offer/answer or role-switch/offer/answer is something implementors can decide to do as they see fit. Implementations can even do both, with the decision about which approach to use at any given moment dictated by which works best for the current application behavior. The only real twist this introduces is for the work described in section 3. If we think this role switching behavior is useful, then it's probably something that we would want to include in any equivalent SIP mechanisms. > Is this because you're concerned that it would add a round trip? I think it's more like half a round trip, but it's not worth splitting hairs over. In any case, I'm not terribly concerned about an extra (half-)round-trip delay for mid-session media changes. /a From ron.even.tlv@gmail.com Tue May 7 15:17:48 2013 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 99D7D21F90DF for ; Tue, 7 May 2013 15:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFxP6FIjXswE for ; Tue, 7 May 2013 15:17:47 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 84ADA21F90CC for ; Tue, 7 May 2013 15:17:47 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so1245540wgg.9 for ; Tue, 07 May 2013 15:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=rNUdRSXqoDP+TBRALEyZrTOE7D/Gm2QjAOOtFQFNHjE=; b=lRoF+CPaAn6uU+BXXW01OI6gZ46eq77mg8SuzbN02p/a0PkEtyNjY8bFyikRcG2aTH a6lgVrzTff/GJT8Yklz2TSUxP1Zj8O1Gv2tb1GXQCqt5742G+N0mXdTYaU3I3TFgQSgD G7nKv0QsbiJhUMkb/vbonjOTetHmk97gMsX95dmJ6u4tKRcrNihAEoS4YjimttwzqgE0 AbUh3rlsjsGX7Rm5z8MbPx923rrcfzFQ+qqQZMyfcW9jYs8shL9nc1Rg1mZaUSbolS+4 bc51oa6w1BqYM3/obUXa84f+P3vGTeRNOMJy7DC91yxcRXijmHCWhsquiNzvYqZfgz4O nWOw== X-Received: by 10.194.78.137 with SMTP id b9mr6374822wjx.10.1367965066705; Tue, 07 May 2013 15:17:46 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id nf9sm5626486wic.3.2013.05.07.15.17.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 15:17:45 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'Adam Roach'" References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> In-Reply-To: <51896D91.9070004@alum.mit.edu> Date: Wed, 8 May 2013 01:16:57 +0300 Message-ID: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFGcIWRrin1agXBJhH0vjVWcsv/GwHIq9K3ASGmi/cCjADdF5neS2Iw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:17:48 -0000 Hi Paul, The problem in the CLUE case in the example you gave is that the receiver will get an RTP stream with a new SSRC not in the SDP to the same port and will need to know how to map it to one of the media capture replacing the previous one. I think that this mode can work in plan B as an additional case, multiple RTP streams in an m-line but the SSRC or mapping to media capture is done via RTP header extension. For plan A it works only if it will allow multiple RTP streams based on the same m-line. The assumption in both cases is that both sides identify that they understand this specific usage, for example, by support of the specific header extension Roni -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 08 May, 2013 12:10 AM To: Adam Roach Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun On 5/7/13 4:00 PM, Adam Roach wrote: > On 5/7/13 14:29, Paul Kyzivat wrote: >> If I bundle an m-line without a=ssrc, and with unique PTs, do you >> consider it ok if there are multiple "anonymous" flows each complying >> to the attributes of the m-line? > > I presume, by "multiple anonymous flows," you mean multiple series of > packets with the same PT, but with different SSRC values. > >> Or do you assume that all packets with that PT are treated as one >> flow, switching from one SSRC to another as they are received? > > In the example you gave, all of those packets are defined to be > associated with the same media line. Looking at basic principles, the > intention here is that the semantics would be identical to non-webrtc, > non-bundle clients receiving multiple SSRCs on the same port. > Admittedly, those semantics have never been crystal clear, but my > experience is that most systems would use this approach to send > multiple streams that are semantically the same "thing" and should be > rendered as one "thing" (e.g., window, speaker, etc). > > Specifically, we are *not* trying to allow the situation in which (1) > the SDP has no SSRC for the m-lines in a bundle group; (2) the party > who generated the SDP receives multiple streams (distinguished, > presumably, by SSRC) with the same PT, and (3) the recipient then > deduces that there should be two different rendering outputs (e.g., windows) as a result. > That is specifically and intentionally one of the behaviors we removed > from the Orlando proposal, since it severely dilutes the value of > preserving existing SDP semantics. > > Does that answer the question you're answering? Yes, that exactly answers the question I was asking. It fits a clue case, of a "dynamic switched capture", where a single logical flow (capture) may be conveyed via unknown SSRCs. But it doesn't cope well with a case where there a several of those, because each will require distinct PTs, and that may not work. To adequately cover that, I think we need the potential to signal a *different* demux algorithm, instead of PT or SSRC. (We are assuming a new RTP header extension). Bottom line, instead of saying the demux is by ssrc if present, and otherwise by PT, I suggest that we explicitly signal the demux mechanism, with options being at least those, plus another one once we get it defined. Otherwise I think what you are proposing can work for CLUE. Thanks, Paul _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Tue May 7 15:29:57 2013 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 9202721F9057 for ; Tue, 7 May 2013 15:29:57 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kToBs6ijK9bL for ; Tue, 7 May 2013 15:29:56 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E36EA21F910E for ; Tue, 7 May 2013 15:29:49 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id b11so1960370iee.23 for ; Tue, 07 May 2013 15:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nEA/y5Hd5fW9Ev55cT6s8iNf7kxICUUGTvdgagHmGag=; b=u50AKZ8VYHbv+KLx1FQv0mES+2b4vPLyZayqO6Ws+Kbs++25rSThvp/9xLAoltBBYp a3DP9Ujn2uO6I2Up6hqc3q66dNCfPewxXlJQZbSW42Ng6pnj0ueDUuKl0BLfv8prAxlC zHzBT4tsOpUBbHa7z7wY70sL7bYOtP/GKmbzhUhc4Uz6u/EOP5gUEKTMOboMcWHML60P PJtksnF3c/KOJUcaMQDYStpAIikU2GTAxTGpjHikIFEhzi/tvslPpBlGqisUOhmz5DnB WDBcZxoG40SgkCvOV2iVlh+2/xgmaaQXOVQ/F9oq7kRbIVyXI23xag24FBfm4hVO/2Fz UOxw== MIME-Version: 1.0 X-Received: by 10.50.40.106 with SMTP id w10mr4864199igk.20.1367965789524; Tue, 07 May 2013 15:29:49 -0700 (PDT) Received: by 10.42.211.16 with HTTP; Tue, 7 May 2013 15:29:49 -0700 (PDT) In-Reply-To: <51897B11.60004@nostrum.com> References: <51897B11.60004@nostrum.com> Date: Tue, 7 May 2013 15:29:49 -0700 Message-ID: From: Ted Hardie To: Adam Roach Content-Type: multipart/alternative; boundary=089e0111b9d4f318d004dc285aae Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:29:57 -0000 --089e0111b9d4f318d004dc285aae Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 3:07 PM, Adam Roach wrote: > On 5/7/13 16:17, Ted Hardie wrote: > >> Taking the first look at this, there were two quick issues I wanted to >> mention. The first is this text: >> >> "In the offer-answer model used by RTCWEB, "glare" arises when >> offer messages "cross on the wire" (that is, both parties in a session >> attempt to change the session at the same time)." >> >> While RTCWEB is being built to support offer/answer, there is no >> requirement that an application use that model for the interaction >> between two clients. >> > > I'm not sure that's right. When calling setRemoteDescription / > setLocalDescription, the RTCSessionDescription objects contain a mandatory > "type" field that must be "offer", "answer", or "pranswer." This really > makes the 3264 offer/answer model pretty thoroughly baked into the system. > > Well, the overview document is pretty careful in its terminology: " The RTCWEB media negotiations will be capable of representing the same SDP offer/answer semantics that are used in SIP [RFC3264 ], in such a way that it is possible to build a signaling gateway between SIP and the RTCWEB media negotiation. " > > So, this wording might need to get a tweak. >> > > If I'm wrong above, I'm happy to take text that explains this fact. I > can't craft any right now, since I don't know how you would set up a WebRTC > session (I say WebRTC since we're really talking about the API side of > things here) without use of offer/answer. > > I think the tweak I'm thinking of here is a shift from "used by RTCWEB" to "supported by RTCWEB". It's not critical, since it is motivation text rather than specification, but it did strike me. > > Second, it seems like the avoidance of glare by having a single >> offer/answerer at a time would work in most cases, but I'm wondering >> why the initial exchange isn't simply a request to change roles? If >> the initial offer role is determined by time, one of the options seems to >> be to accede to a request by the other client to become the offerer. >> > > That's an interesting approach that certainly works just fine. It's > probably worth documenting as an alternative. One thing to note is that the > technique described in my draft is something applications can apply > unilaterally without any standardization work; whether they choose to > perform a solicitation/offer/answer or role-switch/offer/answer is > something implementors can decide to do as they see fit. Implementations > can even do both, with the decision about which approach to use at any > given moment dictated by which works best for the current application > behavior. > > The only real twist this introduces is for the work described in section > 3. If we think this role switching behavior is useful, then it's probably > something that we would want to include in any equivalent SIP mechanisms. > > It seems like this would require a similar Supported header to that described in the draft and an Info package for changing roles. Is there a more efficient way to do that? Or am I missing something else? regards, Ted Hardie > Is this because you're concerned that it would add a round trip? >> > > I think it's more like half a round trip, but it's not worth splitting > hairs over. In any case, I'm not terribly concerned about an extra > (half-)round-trip delay for mid-session media changes. > > /a > --089e0111b9d4f318d004dc285aae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 7, 2013 at 3:07 PM, Adam Roach <adam@nostrum.com>= wrote:
On 5/7/13 16:17, Ted Hardie wrote:
Taking the first look at this, there were two quick issues I wanted to
mention. =A0The first is this text:

"In the offer-answer model used by RTCWEB, "glare" arises wh= en
offer messages "cross on the wire" (that is, both parties in a se= ssion
attempt to change the session at the same time)."

While RTCWEB is being built to support offer/answer, there is no
requirement that an application use that model for the interaction
between two clients.

I'm not sure that's right. When calling setRemoteDescription / setL= ocalDescription, the RTCSessionDescription objects contain a mandatory &quo= t;type" field that must be "offer", "answer", or &= quot;pranswer." This really makes the 3264 offer/answer model pretty t= horoughly baked into the system.

Well, the overview document is pretty careful i= n its terminology:

"
      The RTCWEB=
 media negotiations will be capable of representing the
       same SDP offer/answer semantics that are used in SIP [RFC3264],
       in such a way that it is possible to build a signaling gateway
       between SIP and the RTCWEB media negotiation.
"
=A0

=A0 So, this wording might need to get a tweak.

If I'm wrong above, I'm happy to take text that explains this fact.= I can't craft any right now, since I don't know how you would set = up a WebRTC session (I say WebRTC since we're really talking about the = API side of things here) without use of offer/answer.


I think the tweak I'm thinking of here = is a shift from "used by RTCWEB" to "supported by RTCWEB&quo= t;.=A0
It's not critical, since it is motivation text rather than s= pecification, but it did strike me.

=A0

Second, it seems like the avoidance of glare by having a single
offer/answerer at a time would work in most cases, but I'm wondering why the initial exchange isn't simply a request to change roles? If
the initial offer role is determined by time, one of the options seems to be to accede to a request by the other client to become the offerer.

That's an interesting approach that certainly works just fine. It's= probably worth documenting as an alternative. One thing to note is that th= e technique described in my draft is something applications can apply unila= terally without any standardization work; whether they choose to perform a = solicitation/offer/answer or role-switch/offer/answer is something implemen= tors can decide to do as they see fit. Implementations can even do both, wi= th the decision about which approach to use at any given moment dictated by= which works best for the current application behavior.

The only real twist this introduces is for the work described in section 3.= If we think this role switching behavior is useful, then it's probably= something that we would want to include in any equivalent SIP mechanisms.<= div class=3D"im">

It seems like this would require a similar = Supported header to that described in the draft and an Info package for cha= nging roles.=A0 Is there a more efficient way to do that?=A0 Or am I missin= g something else?

regards,

Ted Hardie

=

Is this because you're concerned that it would add a round trip?

I think it's more like half a round trip, but it's not worth splitt= ing hairs over. In any case, I'm not terribly concerned about an extra = (half-)round-trip delay for mid-session media changes.

/a

--089e0111b9d4f318d004dc285aae-- From bernard_aboba@hotmail.com Tue May 7 15:33:47 2013 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 2D34621F8FDD for ; Tue, 7 May 2013 15:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imfMRCu12err for ; Tue, 7 May 2013 15:33:41 -0700 (PDT) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by ietfa.amsl.com (Postfix) with ESMTP id 400EB21F8F0C for ; Tue, 7 May 2013 15:33:41 -0700 (PDT) Received: from BLU169-W68 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 15:33:40 -0700 X-EIP: [KFl3oumTelNyCq+B1DcLC/nqXNu3RZcyyRfiLRn+L78=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_7b5f5020-72bf-4ee1-8871-65ab776e578f_" From: Bernard Aboba To: Roni Even Date: Tue, 7 May 2013 15:33:40 -0700 Importance: Normal In-Reply-To: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> References: <51894846.3090102@nostrum.com>,<518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu>, <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 22:33:40.0972 (UTC) FILETIME=[ECB14AC0:01CE4B72] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:33:47 -0000 --_7b5f5020-72bf-4ee1-8871-65ab776e578f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni said:=20 > I think that this mode can work in plan B as an additional case=2C multip= le > RTP streams in an m-line but the SSRC or mapping to media capture is done > via RTP header extension.=20 [BA] Support for RTP extensions is supposed to be optional. So if the RTP = extension is there to help the receiver deal with the anonymous SSRC until = an SDP Answer or RTP SDES packet shows up to clarify things=2C I can live w= ith it. But if supporting the RTP extension is necessary to process every = RTP packet I would not be favorably inclined toward this approach.=20 = --_7b5f5020-72bf-4ee1-8871-65ab776e578f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roni said:

>=3B I= think that this mode can work in plan B as an additional case=2C multiple<= br>>=3B RTP streams in an m-line but the SSRC or mapping to media capture= is done
>=3B via RTP header extension.

[BA] Support for RTP e= xtensions is supposed to be optional. =3B So if the RTP extension is th= ere to help the receiver deal with the anonymous SSRC until an SDP Answer o= r RTP SDES packet shows up to clarify things=2C I can live with it. =3B= But if supporting the RTP extension is necessary to process every RTP pack= et I would not be favorably inclined toward this approach.
=
= --_7b5f5020-72bf-4ee1-8871-65ab776e578f_-- From ron.even.tlv@gmail.com Tue May 7 15:33:47 2013 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 D03EF21F8F0C for ; Tue, 7 May 2013 15:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVvVbWMKkpww for ; Tue, 7 May 2013 15:33:47 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 46CE521F8FB3 for ; Tue, 7 May 2013 15:33:43 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q57so1068954wes.23 for ; Tue, 07 May 2013 15:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=koURch6yIogRZbf8Es6roduPj+M0ixus5BM579lBoSs=; b=tq+X9QLSESQY5V3bCHP4ZQoit8k3CNw8kcBWPRXZRD5HseK9asOT0czExz/zoLZTEM uE3lvtZAHHAzEd2Nc2UXSOJMxO6NyWO1FgFb9EDgb5DyeI943FfCixtpEwjg8tSEG5dZ c8/abKjDiEO8Z1LSc4IBO+nuSQFGIrHffu6NbyrJA5iJr+zgtJiWXLv+noFmqMecIgih 3UU3vD5Fbo+xMrAkwfsWUFA3Jt8SYirZjdBG0+arNFrGGTkUcRXP9isj+1USpbLwCneC hIk2G5KDPZvklvBCfBGqE+MtK7Q9MK9pyWjOL24kxwxBARXM2XojMO2Je7C10Y9Asyey dA7w== X-Received: by 10.194.109.136 with SMTP id hs8mr6436799wjb.8.1367966022392; Tue, 07 May 2013 15:33:42 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id s1sm5688588wiz.2.2013.05.07.15.33.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 15:33:41 -0700 (PDT) From: "Roni Even" To: "'Bernard Aboba'" , "'Adam Roach'" References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>, <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu> In-Reply-To: Date: Wed, 8 May 2013 01:32:52 +0300 Message-ID: <00c301ce4b72$d1e47b90$75ad72b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01CE4B8B.F73276E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFGcIWRrin1agXBJhH0vjVWcsv/GwHIq9K3ASGmi/cCjADdFwEGzMbbmdYXwAA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:33:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C4_01CE4B8B.F73276E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think I agree with Bernard. The limitation mentioned in the second paragraph of the introduction is not in SDP. The limitation described can be concluded from RFC3264 but even there people are still arguing that when looking at the following offer m=video 10000 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 What does it mean one RTP session is offered with H.261 or MPV codecs for the same content, or one RTP session is offered with H.261 and MPV codecs each with different content? This offer should really mean "arbitrarily many streams, with potentially different content, any of which could use either H.261 or MPV, potentially switching dynamically between them." I agree that some implementations take this offer as a single RTP stream that can be either H.261 or MPV. I think that the maxssrc proposal tries to make it clearer. Roni From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 08 May, 2013 12:45 AM To: Adam Roach Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun Adam Roach said: > Specifically, we are *not* trying to allow the situation in which (1) > the SDP has no SSRC for the m-lines in a bundle group; (2) the party who > generated the SDP receives multiple streams (distinguished, presumably, > by SSRC) with the same PT, and (3) the recipient then deduces that there > should be two different rendering outputs (e.g., windows) as a result. > That is specifically and intentionally one of the behaviors we removed > from the Orlando proposal, since it severely dilutes the value of > preserving existing SDP semantics. The "existing SDP semantics" have allowed multiplexing of RTP streams from multiple SSRCs on the same RTP session without explicit declaration since multicast days -- and this behavior is implemented within a number of shipping video implementations. In fact, dealing with this is proposed as a MUST within the RTP Usage document. If an event is triggered for a newly encountered (but undeclared) SSRC, this can be handled by the web application which can take care of making sure that new RTP stream is appropriately rendered. Applications (including open source ones, such as Jitsi) do this today. ------=_NextPart_000_00C4_01CE4B8B.F73276E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think I = agree with Bernard. The limitation mentioned in the second paragraph of = the introduction is not in SDP. The limitation described can be = concluded from RFC3264 but even there people are still arguing =  that when = looking at the following offer

 =

m=3Dvideo = 10000 RTP/AVP 31 32

a=3Drtpmap:= 31 H261/90000

a=3Drtpmap:= 32 MPV/90000

 =

What does = it mean one RTP session is offered with H.261 or MPV codecs for the same = content, or one RTP session is offered with H.261 and MPV codecs each = with different content?

This offer = should really mean "arbitrarily many streams, with potentially = different content, any of which could use either H.261 or MPV, = potentially switching dynamically between = them."

 =

I agree = that some implementations take this offer as a single RTP stream that = can be either H.261 or MPV. I think that the maxssrc proposal tries to = make it clearer.

 =

Roni= =

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: 08 May, 2013 12:45 AM
To: = Adam Roach
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] = Plan A, respun

 

Adam Roach = said:

> Specifically, we are = *not* trying to allow the situation in which (1)
> the SDP has no = SSRC for the m-lines in a bundle group; (2) the party who
> = generated the SDP receives multiple streams (distinguished, = presumably,
> by SSRC) with the same PT, and (3) the recipient = then deduces that there
> should be two different rendering = outputs (e.g., windows) as a result.
> That is specifically and = intentionally one of the behaviors we removed
> from the Orlando = proposal, since it severely dilutes the value of
> preserving = existing SDP semantics.

The "existing SDP semantics" = have allowed multiplexing of RTP streams from multiple SSRCs on the =
same RTP session without explicit declaration since multicast days = -- and this behavior is implemented within a number of shipping video = implementations.  In fact, dealing with this is proposed as a MUST = within the RTP Usage document.

If an event is triggered for a = newly encountered (but undeclared) SSRC, this can be handled by the web = application which can take care of making sure that new RTP stream is = appropriately rendered.  Applications (including open source ones, = such as Jitsi) do this today.  =

------=_NextPart_000_00C4_01CE4B8B.F73276E0-- From adam@nostrum.com Tue May 7 15:45:00 2013 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 4266021F9079 for ; Tue, 7 May 2013 15:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-U+iV48EBTp for ; Tue, 7 May 2013 15:44:59 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AF47021F9054 for ; Tue, 7 May 2013 15:44:59 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47Miujo039699 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 17:44:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <518983E8.50603@nostrum.com> Date: Tue, 07 May 2013 17:44:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Hardie References: <51897B11.60004@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050004060608000009050204" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:45:00 -0000 This is a multi-part message in MIME format. --------------050004060608000009050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/7/13 17:29, Ted Hardie wrote: > > The only real twist this introduces is for the work described in > section 3. If we think this role switching behavior is useful, > then it's probably something that we would want to include in any > equivalent SIP mechanisms. > > > It seems like this would require a similar Supported header to that > described in the draft and an Info package for changing roles. Is > there a more efficient way to do that? Or am I missing something else? This is getting a little far from the topic at hand, and is something I'm comfortable we can work out in SIP when we take the work on in earnest. /a --------------050004060608000009050204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/7/13 17:29, Ted Hardie wrote:
The only real twist this introduces is for the work described in section 3. If we think this role switching behavior is useful, then it's probably something that we would want to include in any equivalent SIP mechanisms.


It seems like this would require a similar Supported header to that described in the draft and an Info package for changing roles.  Is there a more efficient way to do that?  Or am I missing something else?

This is getting a little far from the topic at hand, and is something I'm comfortable we can work out in SIP when we take the work on in earnest.

/a
--------------050004060608000009050204-- From ron.even.tlv@gmail.com Tue May 7 15:47:56 2013 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 94FC321F90DF; Tue, 7 May 2013 15:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGr+cS5E3zaV; Tue, 7 May 2013 15:47:54 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27921F9054; Tue, 7 May 2013 15:47:53 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so4472242wgg.4 for ; Tue, 07 May 2013 15:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=JW6aovL1kjSKH3Tn6s2HOMeS5xbMjeJ+HgmursTftZU=; b=cPYHRT3+unJnI9wPZRs3S1ZEhzW1yc906EnB/BoEb9j9pWCo6k7AxHS3SRnQZpEoBG /rjKHNd7uxv6vJzVfQr35G94BKDMl5QqBkpJA1HfTnkGzEO1HfgH5LF8hhJQmfG6qRjJ jCWUglox70VjjDmhwyIRQ9riKtzYYnpbpqb9XY9sow/I6cBObKMdnANK7Si9PPGXxHcB HFEFNdVMWw3OzNHLqP1WySD8k73zpF7/bR8ICaxeZH7gMpHhf2o19zv/x4X4xi3UwKlH KBAgb6IZ7NTU+CM087uNN+nfYXFk50cEujYqfQRz/3mPemikZNuslCmMUklrfjqbSn71 MWyw== X-Received: by 10.180.160.134 with SMTP id xk6mr9833360wib.21.1367966872493; Tue, 07 May 2013 15:47:52 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id s1sm5737569wiz.2.2013.05.07.15.47.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 15:47:51 -0700 (PDT) From: "Roni Even" To: "'Bernard Aboba'" , "'Harald Alvestrand'" References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> In-Reply-To: Date: Wed, 8 May 2013 01:47:02 +0300 Message-ID: <00d701ce4b74$cc846000$658d2000$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01CE4B8D.F1D23440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfgBm/E5GwHeOU28Aj4bM9CYA9p5gA== Content-Language: en-us Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: Re: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:47:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D8_01CE4B8D.F1D23440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bernard, The reason I asked was before plan A and plan B were discussed in MMUSIC in Orlando. Yet I understand that if the purpose of this draft and Adam's one are to describe how to do things in RTCweb it should be discussed in RTCWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rtp-mapping Roni From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 08 May, 2013 1:02 AM To: Harald Alvestrand; Roni Even Cc: rtcweb@ietf.org; mmusic@ietf.org Subject: RE: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Roni said: I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC To the extent that the proposals are attempts to "profile" existing RFCs or MMUSIC work in progress for use in WebRTC, it seems to me like the discussion belongs in RTCWEB. One advantage of that approach is that the solution need not necessarily apply to "all uses of SDP for any scenario for all time", just to the WebRTC use cases. To the extent that NEW SDP functionality is needed, MMUSIC discussion would be appropriate. But until the general direction is decided, it won't be clear what the required new functionality is (if any). ------=_NextPart_000_00D8_01CE4B8D.F1D23440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

The reason I asked was before plan A and plan B were discussed in = MMUSIC in Orlando. Yet I understand that if the purpose of this draft = and Adam’s one are to describe how to do things in RTCweb it = should be discussed in RTCWEB. And we will need a similar one in CLUE = probably in draft-ietf-clue-rtp-mapping

Roni

 

From:= = Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 08 = May, 2013 1:02 AM
To: Harald Alvestrand; Roni = Even
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: = RE: [rtcweb] [MMUSIC] Fwd: New Version Notification for = draft-uberti-rtcweb-plan-00.txt

 

Roni said: =

I think that plan B is the right direction. I am wondering if this = should be discussed in RTCWEB or MMUSIC

=


To the extent that the = proposals are attempts to "profile" existing RFCs or MMUSIC = work in progress for use in WebRTC, it seems to me like the discussion = belongs in RTCWEB. One advantage of that approach is that the solution = need not necessarily apply to "all uses of SDP for any scenario for = all time", just to the WebRTC use cases.

To the extent that = NEW SDP functionality is needed, MMUSIC discussion would be = appropriate.  But until the general direction is decided, it won't = be clear what the required new functionality is (if any).  =


 

=
------=_NextPart_000_00D8_01CE4B8D.F1D23440-- From adam@nostrum.com Tue May 7 15:55:20 2013 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 EE4B221F912C for ; Tue, 7 May 2013 15:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdE+r1Hdkhe0 for ; Tue, 7 May 2013 15:55:20 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5246A21F90CC for ; Tue, 7 May 2013 15:55:20 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47MtFO1040863 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 17:55:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51898653.1010907@nostrum.com> Date: Tue, 07 May 2013 17:55:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Roni Even References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> In-Reply-To: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> Content-Type: multipart/alternative; boundary="------------090609070405040708090501" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:55:21 -0000 This is a multi-part message in MIME format. --------------090609070405040708090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/7/13 17:16, Roni Even wrote: > For plan A it works only if it will allow multiple RTP streams based on the same m-line. I want to re-iterate the most important part of my answer to Paul, since it allows anyone who can apply apply critical thinking skills to arrive at the correct conclusion about what we are proposing. Here is the crux of my answer again, from which the remainder of my answer was derived: Looking at basic principles, the intention here is that the semantics would be identical to non-webrtc, non-bundle clients receiving multiple SSRCs on the same port. So if you're going to define an extension that makes it explicit that multiple SSRCs in non-bundled media is intended to represent multiple independent streams, then you've defined that extension and it works just fine with Plan A. /a --------------090609070405040708090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/7/13 17:16, Roni Even wrote:
For plan A it works only if it will allow multiple RTP streams based on the same m-line.

I want to re-iterate the most important part of my answer to Paul, since it allows anyone who can apply apply critical thinking skills to arrive at the correct conclusion about what we are proposing. Here is the crux of my answer again, from which the remainder of my answer was derived:

Looking at basic principles, the intention here is that the semantics would be identical to non-webrtc, non-bundle clients receiving multiple SSRCs on the same port.

So if you're going to define an extension that makes it explicit that multiple SSRCs in non-bundled media is intended to represent multiple independent streams, then you've defined that extension and it works just fine with Plan A.

/a
--------------090609070405040708090501-- From bernard_aboba@hotmail.com Tue May 7 16:07:12 2013 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 C261121F90CD; Tue, 7 May 2013 16:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJmS5SrUTu3j; Tue, 7 May 2013 16:07:06 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by ietfa.amsl.com (Postfix) with ESMTP id C8BAA21F905F; Tue, 7 May 2013 16:07:06 -0700 (PDT) Received: from BLU169-W4 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 16:07:06 -0700 X-EIP: [z8UyhQM504Tf75ckwG92qWmBYhYCPrBNPjyVqZXitwE=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d290e148-fa9f-4ebf-9aac-15bb029a37ec_" From: Bernard Aboba To: Roni Even , 'Harald Alvestrand' Date: Tue, 7 May 2013 16:07:06 -0700 Importance: Normal In-Reply-To: <00d701ce4b74$cc846000$658d2000$@gmail.com> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> , <00d701ce4b74$cc846000$658d2000$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 23:07:06.0388 (UTC) FILETIME=[98037D40:01CE4B77] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 23:07:13 -0000 --_d290e148-fa9f-4ebf-9aac-15bb029a37ec_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Roni said:=20 "If the purpose of this draft and Adam=92s one are to describe how to do th= ings in RTCweb it should be discussed in RTCWEB. And we will need a similar= one in CLUE probably in draft-ietf-clue-rtp-mapping." [BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping rela= tionship to draft-ietf-rtcweb-rtp-usage)=2C and there are SDP issues. To d= ate=2C I believe we have somewhat neglected the RTP discussion=2C which is = unfortunate=2C because if all the time is spent talking about the SDP Hamme= r=2C then the inclination is to use it to pound every nail=2C and if there = is no SDP=2C then we have no tools at all.=20 The place for the RTP discussion is probably not in RTCWEB (more like AVTCO= RE).=20 = --_d290e148-fa9f-4ebf-9aac-15bb029a37ec_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Roni said:
"If the purpose of this draft and Adam=92s = one are to describe how to do things in RTCweb it should be discussed in RT= CWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rt= p-mapping."

[BA] There are RTP issues to discuss (e.g. draft-= ietf-clue-rtp-mapping relationship to draft-ietf-rtcweb-rtp-usage)=2C and t= here are SDP issues. =3B To date=2C I believe we have somewhat neglecte= d the RTP discussion=2C which is unfortunate=2C because if all the time is = spent talking about the SDP Hammer=2C then the inclination is to use it to = pound every nail=2C and if there is no SDP=2C then we have no tools at all.=

The place for the RTP discussion is probably not in RTCWEB (more l= ike AVTCORE).



 =3B

= --_d290e148-fa9f-4ebf-9aac-15bb029a37ec_-- From stefan.lk.hakansson@ericsson.com Wed May 8 01:53:06 2013 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 85F2821F8F0C for ; Wed, 8 May 2013 01:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umhlvfq1L0wv for ; Wed, 8 May 2013 01:53:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8021F8F27 for ; Wed, 8 May 2013 01:52:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-52-518a1269c1ad Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E7.84.28165.9621A815; Wed, 8 May 2013 10:52:58 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 10:52:57 +0200 Message-ID: <518A1268.8090107@ericsson.com> Date: Wed, 8 May 2013 10:52:56 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvrW6WUFegwZT5vBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/xbs4Ln0hX3r/xiaWBcJdbFyMEhIWAi0fIwoouRE8gUk7hw bz1bFyMXh5DAKUaJ272t7BDOGkaJG6c62UGqeAW0JV78e8sCYrMIqEjM2fSAEcRmEwiUuP7/ FxOILSoQJfHv7W5GiHpBiZMzn4DViwgIS2x91QtWIywQLjHr0mxGuG27jj8FS3ACDTq+7wwr iM0sYCtxYc51FghbXmL72znMILaQgK7Eu9f3WCcwCsxCsmMWkpZZSFoWMDKvYmTPTczMSS83 3MQIDLODW37r7mA8dU7kEKM0B4uSOG8SV2OgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbj iafNHh143hbPn1bRsNr9bbLx9oiFN59Hnusti6x0l1qwfa7e/cbZK82dd+4qfDwzcUEm2+MX y7PFzYq9006bSsVpTWXJ7Vxhrp7tfDpSRdSjTDJ6yePPff7bvj1pj11jlxmhU73/6Z/mqV1v 50qrvm/cxiRld7Za8vyvxpVv7vX7r0hS4FJiKc5INNRiLipOBAA4jOnbAQIAAA== Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:53:06 -0000 I think this could work. There are some parts that I like a lot (and, yes, I tend to have a narrow rtcweb centric perspective): * The (3-way) handshake is well aligned with the API (where the sending app initiates the sending of media) * That simulcast and layered encoding is supported * The text about end-points ensuring that its SSRC's are unique - I think this enables mixers/translators to form arbitrary RTP sessions * It is outlined how sending, or stop sending, is signaled per MediaStreamTrack One thing I do not understand is why the imageattr is signaled in the sending direction in the examples. Is not this info anyway part of the bitstream and will become apparent during the decoding process? It would be more natural to signal imageattr from the receiver (e.g. the receiver telling the sender the size of the video display). (An alternative would be to not signal it at all but leave it to app proprietary signaling and the APIs available to the sending application). I think that an alternative for simulcast could be that, instead of sending several resolutions for the same MediaStreamTrack, it was designed so that a separate MediaStreamTrack would have to be used (and the tracks would of course have to be synced) for each resolution. The primary reason is that the application can only really handle data down to the MediaStreamTrack level - there are no handles below that level in the API's currently. I thing that strikes me is that perhaps we could lift out the msid signaling into its own block, that established the MediaStream and MediaStreamTrack structure of the outgoing media and how is relates to SSRC's. The MediaStream-id/MediaStreamTrack-id info is only relevant to WebRTC endpoints and could be ripped out if the endpoint is legacy, and the remaining SDP would have fewer strange (to legacy) elements. On 2013-05-03 08:08, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: ** > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media sources > in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Wed May 8 03:05:47 2013 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 8DF2321F85EF; Wed, 8 May 2013 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.198 X-Spam-Level: X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x87e0g4UoGqY; Wed, 8 May 2013 03:05:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DE24821F85CC; Wed, 8 May 2013 03:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0243A39E18D; Wed, 8 May 2013 12:05:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2ifBMiQxOAS; Wed, 8 May 2013 12:05:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CC45939E062; Wed, 8 May 2013 12:05:36 +0200 (CEST) Message-ID: <518A236F.6060909@alvestrand.no> Date: Wed, 08 May 2013 12:05:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Bernard Aboba References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> , <00d701ce4b74$cc846000$658d2000$@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080302090407080003090203" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:05:47 -0000 This is a multi-part message in MIME format. --------------080302090407080003090203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 05/08/2013 01:07 AM, Bernard Aboba wrote: > Roni said: > "If the purpose of this draft and Adam’s one are to describe how to do > things in RTCweb it should be discussed in RTCWEB. And we will need a > similar one in CLUE probably in draft-ietf-clue-rtp-mapping." > > [BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping > relationship to draft-ietf-rtcweb-rtp-usage), and there are SDP > issues. To date, I believe we have somewhat neglected the RTP > discussion, which is unfortunate, because if all the time is spent > talking about the SDP Hammer, then the inclination is to use it to > pound every nail, and if there is no SDP, then we have no tools at all. I felt that the discussion of draft-ietf-rtcweb-rtp-usage was largely uncontroversial in the Stockholm interim, and that not much further discussion of that level of the stack was needed - so I have not been worrying much about it after that. It's more like we've got the RTP nail in place, and are hammering on it with the SDP hammer... if we were to use an axe instead (hopefully the back end of it), not much in RTP would change. > > The place for the RTP discussion is probably not in RTCWEB (more like > AVTCORE). > > I think we've already done most of the discussion needed in AVTCORE - we seem to have the dictum of "don't send audio and video on the same 5-tuple" changed to "if you send audio and video on the same 5-tuple, here's what you need to consider", which was really the only critical *change* I saw in RTP-land. > --------------080302090407080003090203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 05/08/2013 01:07 AM, Bernard Aboba wrote:
Roni said:
"If the purpose of this draft and Adam’s one are to describe how to do things in RTCweb it should be discussed in RTCWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rtp-mapping."

[BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping relationship to draft-ietf-rtcweb-rtp-usage), and there are SDP issues.  To date, I believe we have somewhat neglected the RTP discussion, which is unfortunate, because if all the time is spent talking about the SDP Hammer, then the inclination is to use it to pound every nail, and if there is no SDP, then we have no tools at all.

I felt that the discussion of draft-ietf-rtcweb-rtp-usage was largely uncontroversial in the Stockholm interim, and that not much further discussion of that level of the stack was needed - so I have not been worrying much about it after that.

It's more like we've got the RTP nail in place, and are hammering on it with the SDP hammer... if we were to use an axe instead (hopefully the back end of it), not much in RTP would change.


The place for the RTP discussion is probably not in RTCWEB (more like AVTCORE).


I think we've already done most of the discussion needed in AVTCORE - we seem to have the dictum of "don't send audio and video on the same 5-tuple" changed to "if you send audio and video on the same 5-tuple, here's what you need to consider", which was really the only critical *change* I saw in RTP-land.


 


--------------080302090407080003090203-- From harald@alvestrand.no Wed May 8 04:00:38 2013 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 24AEA21F85E8 for ; Wed, 8 May 2013 04:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzi1ENX++-9u for ; Wed, 8 May 2013 04:00:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8126B21F8F2E for ; Wed, 8 May 2013 04:00:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1784539E1C4 for ; Wed, 8 May 2013 13:00:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w2dN8mAi0EL for ; Wed, 8 May 2013 13:00:27 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A23F939E04C for ; Wed, 8 May 2013 13:00:27 +0200 (CEST) Message-ID: <518A304A.1030609@alvestrand.no> Date: Wed, 08 May 2013 13:00:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> In-Reply-To: <51894846.3090102@nostrum.com> Content-Type: multipart/alternative; boundary="------------040404070105060408010402" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:00:38 -0000 This is a multi-part message in MIME format. --------------040404070105060408010402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The paragraph that worries me most is this one: Offerers conformant to this specification MUST do one of the following: o Use non-overlapping PT values for each m-line in any given bundle group. o Provide distinct a=ssrc attributes for each m-line which uses overlapping PT values with any other m-line. [Technically, this is a general case of the previous point.] To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes. To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover point. It would seem to me to be architecturally cleaner to insist that a=ssrc be used always. But in that case, I have a very large difficulty seeing the important advantage this has over Plan B. On 05/07/2013 08:30 PM, Adam Roach wrote: > In order to facilitate discussion between the two SDP format > alternatives we're considering, I've put together a document that more > clearly spells out the Plan A approach as we originally envisioned it. > Note that this is a slightly different approach than Cullen outlined > in Orlando. I fear the Orlando approach may have suffered from its > attempts to incorporate some elements of Plan B in an attempt to > appease proponents of that approach; and, in doing so, lost some of > its clean architecture. > > The cleaned up, new-and-improved description of the Plan A approach is > available here: > > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > > Note that we've omitted discussion of glare reduction from that > document, as I believe that mid-session glare can be completely > avoided by applications implementing a set of non-normative behaviors. > These behaviors are described in the a separate companion document: > > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > Thanks. > > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040404070105060408010402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The paragraph that worries me most is this one:


   Offerers conformant to this specification MUST do one of the
   following:

   o  Use non-overlapping PT values for each m-line in any given bundle
      group.

   o  Provide distinct a=ssrc attributes for each m-line which uses
      overlapping PT values with any other m-line.  [Technically, this
      is a general case of the previous point.]

To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes.

To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover point.

It would seem to me to be architecturally cleaner to insist that a=ssrc be used always.
But in that case, I have a very large difficulty seeing the important advantage this has over Plan B.



On 05/07/2013 08:30 PM, Adam Roach wrote:
In order to facilitate discussion between the two SDP format alternatives we're considering, I've put together a document that more clearly spells out the Plan A approach as we originally envisioned it. Note that this is a slightly different approach than Cullen outlined in Orlando. I fear the Orlando approach may have suffered from its attempts to incorporate some elements of Plan B in an attempt to appease proponents of that approach; and, in doing so, lost some of its clean architecture.

The cleaned up, new-and-improved description of the Plan A approach is available here:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

Note that we've omitted discussion of glare reduction from that document, as I believe that mid-session glare can be completely avoided by applications implementing a set of non-normative behaviors. These behaviors are described in the a separate companion document:

http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt

Thanks.

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

--------------040404070105060408010402-- From harald@alvestrand.no Wed May 8 04:03:43 2013 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 D762621F9079 for ; Wed, 8 May 2013 04:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTUqQ0ygr4Na for ; Wed, 8 May 2013 04:03:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4380121F925B for ; Wed, 8 May 2013 04:03:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0891E39E1C4 for ; Wed, 8 May 2013 13:03:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rit8Ewn8-v7y for ; Wed, 8 May 2013 13:03:35 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 046B539E04C for ; Wed, 8 May 2013 13:03:34 +0200 (CEST) Message-ID: <518A3106.1070107@alvestrand.no> Date: Wed, 08 May 2013 13:03:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>, <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040207080109050703040000" Subject: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:03:43 -0000 This is a multi-part message in MIME format. --------------040207080109050703040000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/07/2013 11:44 PM, Bernard Aboba wrote: > Adam Roach said: > > > Specifically, we are *not* trying to allow the situation in which (1) > > the SDP has no SSRC for the m-lines in a bundle group; (2) the party who > > generated the SDP receives multiple streams (distinguished, presumably, > > by SSRC) with the same PT, and (3) the recipient then deduces that there > > should be two different rendering outputs (e.g., windows) as a result. > > That is specifically and intentionally one of the behaviors we removed > > from the Orlando proposal, since it severely dilutes the value of > > preserving existing SDP semantics. > > The "existing SDP semantics" have allowed multiplexing of RTP streams > from multiple SSRCs on the > same RTP session without explicit declaration since multicast days -- > and this behavior is implemented within a number of shipping video > implementations. In fact, dealing with this is proposed as a MUST > within the RTP Usage document. > > If an event is triggered for a newly encountered (but undeclared) > SSRC, this can be handled by the web application which can take care > of making sure that new RTP stream is appropriately rendered. > Applications (including open source ones, such as Jitsi) do this today. > There's a paragraph in draft-ietf-mmusic-msid about this: 4.1. Handling of non-signalled tracks Pre-WebRTC entities will not send msid. This means that there will be some incoming RTP packets with SSRCs where the recipient does not know about a corresponding MediaStream id. Handling will depend on whether or not any SSRCs are signaled in the relevant m-line(s). There are two cases: o No SSRC is signaled with an msid attribute. The SDP session is assumed to be a backwards-compatible session. All incoming SSRCs, on all m-lines that are part of the SDP session, are assumed to belong to independent media streams, each with one track. The identifier of this media stream and of the media stream track is a randomly generated string; the label of this media stream will be set to "Non-WMS stream". So for the non-msid case, we already have this signal in the WebRTC API - it's called "onaddstream". --------------040207080109050703040000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/07/2013 11:44 PM, Bernard Aboba wrote:
Adam Roach said:

> Specifically, we are *not* trying to allow the situation in which (1)
> the SDP has no SSRC for the m-lines in a bundle group; (2) the party who
> generated the SDP receives multiple streams (distinguished, presumably,
> by SSRC) with the same PT, and (3) the recipient then deduces that there
> should be two different rendering outputs (e.g., windows) as a result.
> That is specifically and intentionally one of the behaviors we removed
> from the Orlando proposal, since it severely dilutes the value of
> preserving existing SDP semantics.

The "existing SDP semantics" have allowed multiplexing of RTP streams from multiple SSRCs on the
same RTP session without explicit declaration since multicast days -- and this behavior is implemented within a number of shipping video implementations.  In fact, dealing with this is proposed as a MUST within the RTP Usage document.

If an event is triggered for a newly encountered (but undeclared) SSRC, this can be handled by the web application which can take care of making sure that new RTP stream is appropriately rendered.  Applications (including open source ones, such as Jitsi) do this today. 

There's a paragraph in draft-ietf-mmusic-msid about this:

4.1.  Handling of non-signalled tracks

   Pre-WebRTC entities will not send msid.  This means that there will
   be some incoming RTP packets with SSRCs where the recipient does not
   know about a corresponding MediaStream id.

   Handling will depend on whether or not any SSRCs are signaled in the
   relevant m-line(s).  There are two cases:

   o  No SSRC is signaled with an msid attribute.  The SDP session is
      assumed to be a backwards-compatible session.  All incoming SSRCs,
      on all m-lines that are part of the SDP session, are assumed to
      belong to independent media streams, each with one track.  The
      identifier of this media stream and of the media stream track is a
      randomly generated string; the label of this media stream will be
      set to "Non-WMS stream".

So for the non-msid case, we already have this signal in the WebRTC API - it's called "onaddstream".

--------------040207080109050703040000-- From csp@csperkins.org Wed May 8 04:33:30 2013 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 C6AC121F8976 for ; Wed, 8 May 2013 04:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi2TjBZ799YW for ; Wed, 8 May 2013 04:33:24 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8D79821F919D for ; Wed, 8 May 2013 04:33:24 -0700 (PDT) Received: from [130.209.247.112] (port=62987 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ua2cM-0007mt-Tw; Wed, 08 May 2013 12:33:13 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_F773D11D-2737-4C8F-B832-30AC26EA1C1A" From: Colin Perkins In-Reply-To: <518A304A.1030609@alvestrand.no> Date: Wed, 8 May 2013 12:33:05 +0100 Message-Id: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:33:30 -0000 --Apple-Mail=_F773D11D-2737-4C8F-B832-30AC26EA1C1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 8 May 2013, at 12:00, Harald Alvestrand wrote: > The paragraph that worries me most is this one: >=20 > Offerers conformant to this specification MUST do one of the > following: >=20 > o Use non-overlapping PT values for each m-line in any given = bundle > group. >=20 > o Provide distinct a=3Dssrc attributes for each m-line which uses > overlapping PT values with any other m-line. [Technically, this > is a general case of the previous point.] >=20 > To put a blunt point on it: Either send less than ~32 streams, or give = a=3Dssrc attributes. >=20 > To me, that measn we're mandating one mechanism (PT values) for small = numbers of flows, and another mechanism (a=3Dssrc) for large numbers of = flows - such mechanism changes usually have "interesting" properties in = what happens at the changeover point. >=20 > It would seem to me to be architecturally cleaner to insist that = a=3Dssrc be used always. I agree: the PT was never intended to be used as a demultiplexing point = for different flows in RTP, that's the role of the SSRC. An a=3Dssrc: = line, or an RTCP SDES item, can then be used to bind the SSRC to an m=3D = line, or some other higher-layer identifier.=20 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_F773D11D-2737-4C8F-B832-30AC26EA1C1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 =20 =20
The paragraph that worries me most is this one:

   Offerers conformant to this specification MUST do one of =
the
   following:

   o  Use non-overlapping PT values for each m-line in any given bundle
      group.

   o  Provide distinct a=3Dssrc attributes for each m-line which uses
      overlapping PT values with any other m-line.  [Technically, this
      is a general case of the previous point.]

To put a blunt point on it: Either send less than ~32 streams, or give a=3Dssrc attributes.

To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=3Dssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover = point.

It would seem to me to be architecturally cleaner to insist that a=3Dssrc be used = always.

I agree: the PT was = never intended to be used as a demultiplexing point for different flows = in RTP, that's the role of the SSRC. An a=3Dssrc: line, or an RTCP SDES = item, can then be used to bind the SSRC to an m=3D line, or some other = higher-layer identifier. 

http://csperkins.org/



= --Apple-Mail=_F773D11D-2737-4C8F-B832-30AC26EA1C1A-- From csp@csperkins.org Wed May 8 04:37:34 2013 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 EF35A21F90B9 for ; Wed, 8 May 2013 04:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbRBppPkvPwn for ; Wed, 8 May 2013 04:37:29 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id BB85721F8E56 for ; Wed, 8 May 2013 04:37:29 -0700 (PDT) Received: from [130.209.247.112] (port=63011 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ua2gT-0008DQ-Lq; Wed, 08 May 2013 12:37:28 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Wed, 8 May 2013 12:37:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com>, <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu>, <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:37:35 -0000 On 7 May 2013, at 23:33, Bernard Aboba wrote: > Roni said:=20 >=20 >> I think that this mode can work in plan B as an additional case, = multiple RTP streams in an m-line but the SSRC or mapping to media = capture is done via RTP header extension.=20 >>=20 > [BA] Support for RTP extensions is supposed to be optional. So if the = RTP extension is there to help the receiver deal with the anonymous SSRC = until an SDP Answer or RTP SDES packet shows up to clarify things, I can = live with it. But if supporting the RTP extension is necessary to = process every RTP packet I would not be favorably inclined toward this = approach.=20 Agree: if we define an RTP header extension for this, it should only be = used to speed-up acquisition of the relevant information that's sent in = an RTCP SDES item (much like we did with RFC 6051).=20 --=20 Colin Perkins http://csperkins.org/ From prvs=484031e1b9=stefan.lk.hakansson@ericsson.com Wed May 8 05:38:45 2013 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 A39EA21F9352; Wed, 8 May 2013 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJCJ3QGfEzNc; Wed, 8 May 2013 05:38:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2D21F8F0A; Wed, 8 May 2013 05:38:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-6d-518a474cb831 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C6.3D.32006.C474A815; Wed, 8 May 2013 14:38:37 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 14:38:36 +0200 Message-ID: <518A474C.5020200@ericsson.com> Date: Wed, 8 May 2013 14:38:36 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic@ietf.org References: <51894846.3090102@nostrum.com> In-Reply-To: <51894846.3090102@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvra6ve1egwacZZhZTlz9msVj7r53d gcljyZKfTAGMUdw2SYklZcGZ6Xn6dgncGU2TbzAXfOev+PV7E0sDYwNvFyMnh4SAiUTT+/9M ELaYxIV769lAbCGBU4wSa2fkdzFyAdlrGCV+XvkDVsQroC2x9cRksCIWARWJr8uus4LYbAKB Etf//wKrERWIkvj3djcjRL2gxMmZT1hAbBGg+tn3TwDFOTiEgezDl8sgdmlJrP/1AKyEE2j8 vUVrmEFsZgFbiQtzrrNA2PIS29/OYYao15V49/oe6wRGgVlINsxC0jILScsCRuZVjOy5iZk5 6eVGmxiBAXdwy2/VHYx3zokcYpTmYFES503magwUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwQki uKQaGG3Tjkxf6XDK9uNzvchDIvol6zz/5K1yfqbU0qx1n6Fd9/azjP2Fq2N+CiUI5RzN6Deq ZThvZFMuc2f1V6O0piNlNj+rzQ/d/tfrNGume/XJTu6Fs3RzLi0/97t+j/6z4xfD1vm+7JHj 4XRe9OTqyvkC6wL09100nibN9d/Lc8maheseHlrzlEOJpTgj0VCLuag4EQA+6+CyCwIAAA== Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:38:45 -0000 A couple of questions (and sorry for the rtcweb/webrtc centric perspective) for clarification: * How would the info about PC-track and PC-stream id's be conveyed (I assume the msid draft)? * What is your thinking regarding mapping between PC-tracks and m-lines? For example, if Alice's app initiates a session with two video PC-track's flowing to Bob's app, that would presumable create a session with two sendonly m-lines. If, at a later stage, Bob's app upgrades the session by sending three video PC-tracks to Alice's app. How would the Bob -> Alice video PC-tracks be allocated to the existing m-lines (becoming sendrecv), and how would pick which one to use a new m-line? E.g., would it be random, or should the app decide, and based on what in that case? Stefan On 2013-05-07 20:30, Adam Roach wrote: > In order to facilitate discussion between the two SDP format > alternatives we're considering, I've put together a document that more > clearly spells out the Plan A approach as we originally envisioned it. > Note that this is a slightly different approach than Cullen outlined in > Orlando. I fear the Orlando approach may have suffered from its attempts > to incorporate some elements of Plan B in an attempt to appease > proponents of that approach; and, in doing so, lost some of its clean > architecture. > > The cleaned up, new-and-improved description of the Plan A approach is > available here: > > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > > Note that we've omitted discussion of glare reduction from that > document, as I believe that mid-session glare can be completely avoided > by applications implementing a set of non-normative behaviors. These > behaviors are described in the a separate companion document: > > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > Thanks. > > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From prvs=484031e1b9=stefan.lk.hakansson@ericsson.com Wed May 8 06:06:47 2013 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 905BB21F9054 for ; Wed, 8 May 2013 06:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPhR0ek35D1c for ; Wed, 8 May 2013 06:06:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 089A021F901F for ; Wed, 8 May 2013 06:06:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-71-518a4de0d556 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 06.BE.28165.0ED4A815; Wed, 8 May 2013 15:06:40 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 15:06:40 +0200 Message-ID: <518A4DE0.2040306@ericsson.com> Date: Wed, 8 May 2013 15:06:40 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> In-Reply-To: <518A474C.5020200@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMJMWRmVeSWpSXmKPExsUyM+Jvre4D365Ag2WvTCzW/mtnd2D0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8aKux3sBffFKubNXM7YwLhbqIuRk0NCwERi1s39rBC2mMSF e+vZuhi5OIQETjFKPH9zngUkISSwhlGi87oaiM0roC2x+ew0sAYWARWJ6SumMYLYbAKBEtf/ /2ICsUUFoiT+vd3NCFEvKHFy5hOwOSICwhJbX/UC1XBwCAP1Hr5cBjHeS2Jfyw42EJtTQEei +fxDsFZmAVuJC3Ous0DY8hLNW2czQ9TrSrx7fY91AqPALCQbZiFpmYWkZQEj8ypG9tzEzJz0 csNNjMAwO7jlt+4OxlPnRA4xSnOwKInzJnE1BgoJpCeWpGanphakFsUXleakFh9iZOLgBBFc Ug2MzQ16S42V8vaePxwlEfhQgG/ujC2sFgcNNlXvOWw3adVdjbpqiwgJG0vviuiiKYuEV5V+ X8d9uvrLzPeL/hkVPJje/31XdGBjz1anLes3hb7+zfBrQ9+pJQ8mlS87ualiwdXoF9Pv2MYw BHx/98W+rFtK/a+odbSDoWKC3PaHd66u63Gz3nK+SomlOCPRUIu5qDgRAPpHriUGAgAA Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:06:47 -0000 One more question (and I think this one is applicable to Plan B as well). It has to do with devices with HW encoders. If I have a system that supports video encoding and decoding of format X and Y it is pretty obvious what the offer should look like. But if I add a camera that can also encode in format Z, what should the offer look like? The camera would not decode, so for sendrecv m-lines format Z could not be included in an offer. Does this mean that to utilize camera encoders (if the corresponding decoders are not available in the system), we'd be limited to sendonly m-lines? Stefan On 2013-05-08 14:38, Stefan Håkansson LK wrote: > A couple of questions (and sorry for the rtcweb/webrtc centric > perspective) for clarification: > > * How would the info about PC-track and PC-stream id's be conveyed (I > assume the msid draft)? > > * What is your thinking regarding mapping between PC-tracks and m-lines? > For example, if Alice's app initiates a session with two video > PC-track's flowing to Bob's app, that would presumable create a session > with two sendonly m-lines. If, at a later stage, Bob's app upgrades the > session by sending three video PC-tracks to Alice's app. How would the > Bob -> Alice video PC-tracks be allocated to the existing m-lines > (becoming sendrecv), and how would pick which one to use a new m-line? > E.g., would it be random, or should the app decide, and based on what in > that case? > > Stefan > > > > On 2013-05-07 20:30, Adam Roach wrote: >> In order to facilitate discussion between the two SDP format >> alternatives we're considering, I've put together a document that more >> clearly spells out the Plan A approach as we originally envisioned it. >> Note that this is a slightly different approach than Cullen outlined in >> Orlando. I fear the Orlando approach may have suffered from its attempts >> to incorporate some elements of Plan B in an attempt to appease >> proponents of that approach; and, in doing so, lost some of its clean >> architecture. >> >> The cleaned up, new-and-improved description of the Plan A approach is >> available here: >> >> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >> >> Note that we've omitted discussion of glare reduction from that >> document, as I believe that mid-session glare can be completely avoided >> by applications implementing a set of non-normative behaviors. These >> behaviors are described in the a separate companion document: >> >> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >> >> Thanks. >> >> /a >> _______________________________________________ >> 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 jonathan@vidyo.com Wed May 8 08:03:38 2013 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 3470F21F9352 for ; Wed, 8 May 2013 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[AWL=1.477, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cDHQoHcgc83 for ; Wed, 8 May 2013 08:03:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30E21F9301 for ; Wed, 8 May 2013 08:03:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 52D738BF5AA; Wed, 8 May 2013 10:39:10 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id EF1348BF350; Wed, 8 May 2013 10:39:09 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Wed, 8 May 2013 11:02:12 -0400 From: Jonathan Lennox To: Adam Roach Date: Wed, 8 May 2013 11:03:31 -0400 Thread-Topic: [rtcweb] Plan A, respun Thread-Index: Ac5L/SSFRfdKDbCZQY+YD1IoT40hPQ== Message-ID: <520C76B2-825D-4FEA-B174-6E5F5EBE907D@vidyo.com> References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> <51898653.1010907@nostrum.com> In-Reply-To: <51898653.1010907@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_520C76B2825D4FEAB1746E5F5EBE907Dvidyocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:03:38 -0000 --_000_520C76B2825D4FEAB1746E5F5EBE907Dvidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On May 7, 2013, at 6:55 PM, Adam Roach wrote: I want to re-iterate the most important part of my answer to Paul, since it= allows anyone who can apply apply critical thinking skills to arrive at th= e correct conclusion about what we are proposing. Here is the crux of my an= swer again, from which the remainder of my answer was derived: Looking at basic principles, the intention here is that the semantics would= be identical to non-webrtc, non-bundle clients receiving multiple SSRCs on= the same port. Which would be great, if the community actually had a common understanding = of what those semantics are. -- Jonathan Lennox jonathan@vidyo.com --_000_520C76B2825D4FEAB1746E5F5EBE907Dvidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On May 7, 20= 13, at 6:55 PM, Adam Roach wrote:

I want to re-iterate the most important part of my answer to Paul, since it allows anyone who can apply apply critical thinking skills to arrive at the correct conclusion about what we are proposing. Here is the crux of my answer again, from which the remainder of my answer was derived:
Looking at basic principles, the intention here is that the semantics would be identical to non-webrtc, non-bundle clients receiving multiple SSRCs on the same port.
Which would be great, if the community actually had a common= understanding of what those semantics are.

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_520C76B2825D4FEAB1746E5F5EBE907Dvidyocom_-- From martin.thomson@gmail.com Wed May 8 08:38:03 2013 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 A279721F90B9 for ; Wed, 8 May 2013 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3UW2gbnWp-9 for ; Wed, 8 May 2013 08:38:03 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2421F9352 for ; Wed, 8 May 2013 08:38:02 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fk20so1914128lab.33 for ; Wed, 08 May 2013 08:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R4jLVbNL71GDMjx0TDVPDd31V8rbt6w/o+NmkIrjZ1w=; b=YYXJCQ1PJGcPYvpjwKr/Nkh0k+Ihc6smlzZ/U4aR/Cm7yoLqRFeXL47UJLC/CgOzIM 01a/O8YHPHY2odMZiDsgEcKDf7+mp9lHKJD2tJ50S5NzshCGw3xfl/WvU07QcyJAkoP6 8a9+lTBAjGgAQGY1yPumzQ4X8NVVE5LrXvZ07HBa9ZJTFy9WRfAbnEKG9UtnhomDFzXz NbgE5EIJN9vwPvpRErTTYeseFR9f7l88caypYJonNxVRS66rRXsFmINFp1nifvgIqHnW SMtwouHo4YE4voiDnlx0DKySafueazPF3w900w7oEdfFTw8XMQUPfNqOwHxZPhqnnWkc bIJA== MIME-Version: 1.0 X-Received: by 10.112.125.232 with SMTP id mt8mr603198lbb.55.1368027480569; Wed, 08 May 2013 08:38:00 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 08:38:00 -0700 (PDT) In-Reply-To: <518A304A.1030609@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> Date: Wed, 8 May 2013 08:38:00 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:38:03 -0000 On 8 May 2013 04:00, Harald Alvestrand wrote: > To put a blunt point on it: Either send less than ~32 streams, or give > a=ssrc attributes. This doesn't worry me in the slightest. Legacy endpoints and those that have trouble accessing SSRC information wont be able to use lots of streams. But it's interoperation with those endpoints that is why this provision exists. Requiring a=ssrc is as bad as my suggestion to move to v=1. (Which I still stand by, if you were wondering.) From martin.thomson@gmail.com Wed May 8 08:43:27 2013 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 A4B0F21F9380; Wed, 8 May 2013 08:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=-3.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5MRfIy8gC5a; Wed, 8 May 2013 08:43:22 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 121B021F8FE9; Wed, 8 May 2013 08:43:21 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id w20so2070151lbh.6 for ; Wed, 08 May 2013 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=N9ihVS0ZXB0UU37MQNXmnVfu26qNip0AT4Tt2ltMEq8=; b=hNpPGfFzeXZp0IHUD6v/hhIVQj0NnnQ0n1YO9eRgSABBMYQcSf+iQrQcDHy1anqCK+ 61h7Q+jR6SfM7Ed7Mk++CsbEX0O6jml08nGQo1EOoO4dIqQof4CaLA8JJNlIDNZ/6sVW izXmivgeaXfrJmc2sSyL41rPYLpnazlfwfCYBeSFqZyuA41RarxWBB0JjvBlkqxIHSkH aTrKn6cMHGDkR+eTHULbryfqQ20esZ98g2cIxZSqAJntL0tn9Js+eZ4rhHElHcwZ45hk ZEs6eI/snrJIZZXl6zpZWpCR2Y5G47NtCp3gqEVcrTJR6paB2msl54/WCP31vgUhFOvQ gZpA== MIME-Version: 1.0 X-Received: by 10.152.5.37 with SMTP id p5mr3498669lap.13.1368027800947; Wed, 08 May 2013 08:43:20 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 08:43:20 -0700 (PDT) In-Reply-To: <518A474C.5020200@ericsson.com> References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> Date: Wed, 8 May 2013 08:43:20 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:43:27 -0000 On 8 May 2013 05:38, Stefan H=C3=A5kansson LK wrote: > A couple of questions (and sorry for the rtcweb/webrtc centric perspectiv= e) > for clarification: > > * How would the info about PC-track and PC-stream id's be conveyed (I ass= ume > the msid draft)? Yes, that's a solved problem. No sense reiterating it in the draft (it's orthogonal to what the draft actually addresses). > * What is your thinking regarding mapping between PC-tracks and m-lines? = For > example, if Alice's app initiates a session with two video PC-track's > flowing to Bob's app, that would presumable create a session with two > sendonly m-lines. If, at a later stage, Bob's app upgrades the session by > sending three video PC-tracks to Alice's app. How would the Bob -> Alice > video PC-tracks be allocated to the existing m-lines (becoming sendrecv), > and how would pick which one to use a new m-line? E.g., would it be rando= m, > or should the app decide, and based on what in that case? Alice's offer would contain at least two m-lines. Those would not necessarily be sendonly. If she was capable of receiving more than 2 inbound, the offer could contain recvonly lines too (I believe that this fits with the OfferToReceiveVideo=3Dn constraint). Of course, if those lines were not compatible with what Bob wanted to send (too much, different codecs, different constraints, etc...), then Bob is required to send another offer to get his media out. From martin.thomson@gmail.com Wed May 8 08:47:41 2013 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 793A721F8EBD for ; Wed, 8 May 2013 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.124 X-Spam-Level: X-Spam-Status: No, score=-5.124 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhSLcyp8ldVz for ; Wed, 8 May 2013 08:47:35 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 221F421F8ECB for ; Wed, 8 May 2013 08:47:33 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id d10so2065704lbj.24 for ; Wed, 08 May 2013 08:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Q88QzYAAq9+6yqRvBYVq7R4pppu/U2z2Fr1UQAshGls=; b=PG11Cc6UdvUrDIZmxgW+3GunJeQ5fXlVxz0N9ZJwsFLjdDQYl93vLBdaO+jCG57QgD vioD8U75A2EbeFv1sCLy7rg9TNAkKc3nYWrLhLUzDYr+TViHjhHzYTTBXBDDGWyBwQzb I6F9Bes3sKFEHF1l1A/HXtlL4NlYeooGD7YCS3x3rFO3THJYFZ0sgNxFdX7PokIJn2d7 KlY9vPKqvD4RmO0bbiWvQa27MPUtDMEoYbGOdwCrHFm3/Cjw9Hyi+EKnVJp79ITVsOG4 zOtqi4rmTtOTIOr5/61or+rXrmoF+0E6S3si/kYi4WgFovLHV1u/EObENJyb3rez2XPn 1f3Q== MIME-Version: 1.0 X-Received: by 10.112.160.1 with SMTP id xg1mr3464108lbb.110.1368028053042; Wed, 08 May 2013 08:47:33 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 08:47:32 -0700 (PDT) In-Reply-To: <518A4DE0.2040306@ericsson.com> References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> <518A4DE0.2040306@ericsson.com> Date: Wed, 8 May 2013 08:47:32 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:47:41 -0000 This is a pretty complicated example, but I agree that it is quite relevant= . If the camera that can produce Z is attached (to the RTCPeerConnection), then an offer would include X, Y and Z, but it would probably have to be marked sendonly. Other m-lines could be used to offer to receive X and Y. I don't see this being solved very well by SDP at all. Regardless of the option chosen. On 8 May 2013 06:06, Stefan H=C3=A5kansson LK wrote: > One more question (and I think this one is applicable to Plan B as well).= It > has to do with devices with HW encoders. > > If I have a system that supports video encoding and decoding of format X = and > Y it is pretty obvious what the offer should look like. > > But if I add a camera that can also encode in format Z, what should the > offer look like? > > The camera would not decode, so for sendrecv m-lines format Z could not b= e > included in an offer. > > Does this mean that to utilize camera encoders (if the corresponding > decoders are not available in the system), we'd be limited to sendonly > m-lines? > > Stefan > > > > On 2013-05-08 14:38, Stefan H=C3=A5kansson LK wrote: >> >> A couple of questions (and sorry for the rtcweb/webrtc centric >> perspective) for clarification: >> >> * How would the info about PC-track and PC-stream id's be conveyed (I >> assume the msid draft)? >> >> * What is your thinking regarding mapping between PC-tracks and m-lines? >> For example, if Alice's app initiates a session with two video >> PC-track's flowing to Bob's app, that would presumable create a session >> with two sendonly m-lines. If, at a later stage, Bob's app upgrades the >> session by sending three video PC-tracks to Alice's app. How would the >> Bob -> Alice video PC-tracks be allocated to the existing m-lines >> (becoming sendrecv), and how would pick which one to use a new m-line? >> E.g., would it be random, or should the app decide, and based on what in >> that case? >> >> Stefan >> >> >> >> On 2013-05-07 20:30, Adam Roach wrote: >>> >>> In order to facilitate discussion between the two SDP format >>> alternatives we're considering, I've put together a document that more >>> clearly spells out the Plan A approach as we originally envisioned it. >>> Note that this is a slightly different approach than Cullen outlined in >>> Orlando. I fear the Orlando approach may have suffered from its attempt= s >>> to incorporate some elements of Plan B in an attempt to appease >>> proponents of that approach; and, in doing so, lost some of its clean >>> architecture. >>> >>> The cleaned up, new-and-improved description of the Plan A approach is >>> available here: >>> >>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>> >>> Note that we've omitted discussion of glare reduction from that >>> document, as I believe that mid-session glare can be completely avoided >>> by applications implementing a set of non-normative behaviors. These >>> behaviors are described in the a separate companion document: >>> >>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>> >>> Thanks. >>> >>> /a >>> _______________________________________________ >>> 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From prvs=2840dbfb96=stefan.lk.hakansson@ericsson.com Wed May 8 08:49:18 2013 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 06B4621F93B3 for ; Wed, 8 May 2013 08:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYYFJ33Ud7YM for ; Wed, 8 May 2013 08:49:12 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6631521F8FE9 for ; Wed, 8 May 2013 08:49:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-54-518a73f71402 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AE.65.32006.7F37A815; Wed, 8 May 2013 17:49:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Wed, 8 May 2013 17:49:10 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson Thread-Topic: [rtcweb] Plan A, respun Thread-Index: AQHOS1D4NLK2KMGfIU2obh1wmIQUTZj7O0gAgAAH2ACAAAtrAIAAIf2A Date: Wed, 8 May 2013 15:49:09 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C66C3@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvre734q5Ag5cbZSyunfnHaLH2Xzu7 A5PHzll32T2WLPnJFMAUxW2TlFhSFpyZnqdvl8CdsWsqT8F6uYof32+yNjA+l+hi5OCQEDCR 2P2tqouRE8gUk7hwbz1bFyMXh5DAYUaJC98/QTmLGSXWfGtmBqliEwiU2LpvARuILSKgK7Ho 7AN2EJtZQF3izuJz7CBDhQVUJA5fLgMxRQRUJab+54KodpPY8eAiC0iYBahiy0WwRl4BX4kb U9aygticQMMP9x5gArEZgc75fmoNE8RwcYlbT+YzQZwpILFkz3lmCFtU4uXjf2C9ogJ6EjfP tLBCxJUkGpc8YYXo1ZO4MXUKG4RtLXHnUiMjhK0tsWzha2aIGwQlTs58wjKBUXwWknWzkLTP QtI+C0n7LCTtCxhZVzGy5yZm5qSXG21iBEbTwS2/VXcw3jkncohRmoNFSZw3masxUEggPbEk NTs1tSC1KL6oNCe1+BAjEwcniOCSamA0E4rp/yfwuuCwY6+g+XShhZ+VGjgzZO32/H19fNnu SM5VbcI+jD6y4b8THc7w234/FH9d9VPXi/S5CUc/cedOePHrp+SHDXGlOXUffO+0vFG/cf1n 3ssfH70+znRy2hSpeKrBbPuxGS+3LDwus1G+v3/31Milit/+/PwQ15YmkW6+JFBrgc5cJZbi jERDLeai4kQAIypXdXkCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:49:18 -0000 On 5/8/13 5:47 PM, "Martin Thomson" wrote: >This is a pretty complicated example, but I agree that it is quite >relevant. > >If the camera that can produce Z is attached (to the >RTCPeerConnection), then an offer would include X, Y and Z, but it >would probably have to be marked sendonly. Other m-lines could be >used to offer to receive X and Y. > >I don't see this being solved very well by SDP at all. Regardless of >the option chosen. That's in line with my conclusion. > >On 8 May 2013 06:06, Stefan H=E5kansson LK > wrote: >> One more question (and I think this one is applicable to Plan B as >>well). It >> has to do with devices with HW encoders. >> >> If I have a system that supports video encoding and decoding of format >>X and >> Y it is pretty obvious what the offer should look like. >> >> But if I add a camera that can also encode in format Z, what should the >> offer look like? >> >> The camera would not decode, so for sendrecv m-lines format Z could not >>be >> included in an offer. >> >> Does this mean that to utilize camera encoders (if the corresponding >> decoders are not available in the system), we'd be limited to sendonly >> m-lines? >> >> Stefan >> >> >> >> On 2013-05-08 14:38, Stefan H=E5kansson LK wrote: >>> >>> A couple of questions (and sorry for the rtcweb/webrtc centric >>> perspective) for clarification: >>> >>> * How would the info about PC-track and PC-stream id's be conveyed (I >>> assume the msid draft)? >>> >>> * What is your thinking regarding mapping between PC-tracks and >>>m-lines? >>> For example, if Alice's app initiates a session with two video >>> PC-track's flowing to Bob's app, that would presumable create a session >>> with two sendonly m-lines. If, at a later stage, Bob's app upgrades the >>> session by sending three video PC-tracks to Alice's app. How would the >>> Bob -> Alice video PC-tracks be allocated to the existing m-lines >>> (becoming sendrecv), and how would pick which one to use a new m-line? >>> E.g., would it be random, or should the app decide, and based on what >>>in >>> that case? >>> >>> Stefan >>> >>> >>> >>> On 2013-05-07 20:30, Adam Roach wrote: >>>> >>>> In order to facilitate discussion between the two SDP format >>>> alternatives we're considering, I've put together a document that more >>>> clearly spells out the Plan A approach as we originally envisioned it. >>>> Note that this is a slightly different approach than Cullen outlined >>>>in >>>> Orlando. I fear the Orlando approach may have suffered from its >>>>attempts >>>> to incorporate some elements of Plan B in an attempt to appease >>>> proponents of that approach; and, in doing so, lost some of its clean >>>> architecture. >>>> >>>> The cleaned up, new-and-improved description of the Plan A approach is >>>> available here: >>>> >>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>> >>>> Note that we've omitted discussion of glare reduction from that >>>> document, as I believe that mid-session glare can be completely >>>>avoided >>>> by applications implementing a set of non-normative behaviors. These >>>> behaviors are described in the a separate companion document: >>>> >>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>> >>>> Thanks. >>>> >>>> /a >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Wed May 8 08:51:23 2013 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 8D30E21F8F20 for ; Wed, 8 May 2013 08:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3uTCuN+EXWF for ; Wed, 8 May 2013 08:51:23 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7421F8960 for ; Wed, 8 May 2013 08:51:22 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r48FpLc6057296 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 8 May 2013 10:51:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <518A7479.10208@nostrum.com> Date: Wed, 08 May 2013 10:51:21 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> In-Reply-To: <518A304A.1030609@alvestrand.no> Content-Type: multipart/alternative; boundary="------------050501080803050108050606" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:51:23 -0000 This is a multi-part message in MIME format. --------------050501080803050108050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/8/13 06:00, Harald Alvestrand wrote: > To put a blunt point on it: Either send less than ~32 streams, or give > a=ssrc attributes. Let's call it 96, just to keep reality involved in the conversation (cf. RFC 3551, section 3, para 7; as updated by RFC 5761, section 4, para 10). I'll also point out that you can always have more than one bundle; so, if you're willing to burn two ports rather than just one, you can double this to 192. Repeat as necessary. > To me, that measn we're mandating one mechanism (PT values) for small > numbers of flows... Uh... no? Small numbers of flows can use a=ssrc. They just lose some flexibility by doing so. > ...and another mechanism (a=ssrc) for large numbers of flows - such > mechanism changes usually have "interesting" properties in what > happens at the changeover point. Given the actual limit here is 96 *per* *port*, I'd be more inclined to characterize it as: * One very flexible mechanism for small, medium, and moderately large numbers of streams, and * Another less flexible mechanism for sessions of arbitrary size, including small numbers of streams /a --------------050501080803050108050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/8/13 06:00, Harald Alvestrand wrote:
To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes.

Let's call it 96, just to keep reality involved in the conversation (cf. RFC 3551, section 3, para 7; as updated by RFC 5761, section 4, para 10).

I'll also point out that you can always have more than one bundle; so, if you're willing to burn two ports rather than just one, you can double this to 192. Repeat as necessary.

To me, that measn we're mandating one mechanism (PT values) for small numbers of flows...

Uh... no? Small numbers of flows can use a=ssrc. They just lose some flexibility by doing so.

...and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover point.

Given the actual limit here is 96 *per* *port*, I'd be more inclined to characterize it as:

  • One very flexible mechanism for small, medium, and moderately large numbers of streams, and
  • Another less flexible mechanism for sessions of arbitrary size, including small numbers of streams

/a
--------------050501080803050108050606-- From emil@sip-communicator.org Wed May 8 08:51:49 2013 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 AFDCE21F93BC for ; Wed, 8 May 2013 08:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nAwPewbiB-P for ; Wed, 8 May 2013 08:51:49 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFD621F90C4 for ; Wed, 8 May 2013 08:51:48 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id jc3so982083bkc.28 for ; Wed, 08 May 2013 08:51:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ZwN+QUjXJOiMhOgAEicuM7hyqiNYhHg8B0FGZJoMsXc=; b=avZj+1Z3XhD5UVO2B65N+g5m7yk7P1QCJm78HddNQg524ohvkvxQreSNuIA8vmfp5g MAqkSEJIY755zPeMA6hn5S6oGw9gYEX9r2wVC//VD1SXvPh6ye/XKSQ4Z4vSwlJ9sztq FpOPNF+pWX17Kmi4a/yNzODen7taaGA6iIl2SVg0m5OK3cTpfEw/F5pYibmqLzthc0E4 JnmFuJ8PnsrzuFtfgZ9zLbKM5ejZOWltmofrRbLq2fuy9kXXCRxL+XBES6qF+nxmIw1a T8Qq40NVTXZAaaFYZoTRcZCj9Eay3Dr3+0gR8hB8yf9/S/1KnLoCJKfGO84xxyWrco+b v4zw== X-Received: by 10.204.51.200 with SMTP id e8mr2016273bkg.131.1368028307445; Wed, 08 May 2013 08:51:47 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id fh8sm8074843bkc.10.2013.05.08.08.51.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 08:51:46 -0700 (PDT) Message-ID: <518A748D.9020806@jitsi.org> Date: Wed, 08 May 2013 18:51:41 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> In-Reply-To: <518A304A.1030609@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmaOZPmCCJ3qpgD5TYRSpQ4o/5860LIY2hM9XgyWr7mKw1nlfJAZeCAg2LymMxeXCpXm6Sk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:51:49 -0000 On 08.05.13, 14:00, Harald Alvestrand wrote: > To put a blunt point on it: Either send less than ~32 streams, or give > a=ssrc attributes. I might be missing something ... probably even a lot, but why do we need the above limitation? Why is it not an option to just let the application provide the relationship with the MediaStream? Requiring that all SSRCs be known in advance or imposing re-offer/answer exchanges seems like waaay too heavy a requirement that can add severe restrictions on the way applications and topologies are designed. Emil -- https://jitsi.org From emil@sip-communicator.org Wed May 8 08:56:08 2013 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 48F7721F8E74 for ; Wed, 8 May 2013 08:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRFpyiSLT-sq for ; Wed, 8 May 2013 08:56:07 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9834421F91CE for ; Wed, 8 May 2013 08:55:58 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji2so982967bkc.24 for ; Wed, 08 May 2013 08:55:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Yy8lETZ/Cmlbn39M07aYMgYLSX/+Kkz1PB5xowLJEvk=; b=Nj22djFzAokZsNU9Y/+u89IA/yxjGPhSig1DPXJOKxu99cd3eWNMMzmCsbR5P3rmRZ S5g74XgudBtYTLeE/CaX+Un3WkfVSu7g84Ufk5YoLDm4t/Tjf7Tm53qeWHd25KP28nsF KblUTt2PpEZLEMFXBArhT4kCw5peFtNrzt3+eJ2q8EdRIfwlellOGg14iX/gzl/XEdlH zg1y9CXz8TlOL4k+ZCz63GHGKMYPqWxG7sfXV9szNwfI0F/NUXtLmP2omv9GWR/CZV6C W/HMFAG+441hLm/Gy07j1ZmNvnzDds+VYvnwIqbUEaqkoNi9OeFYhay1KagFg9OJjvDE 3cWw== X-Received: by 10.204.245.201 with SMTP id lv9mr2009172bkb.102.1368028557516; Wed, 08 May 2013 08:55:57 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id tc9sm8074546bkb.18.2013.05.08.08.55.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 08:55:56 -0700 (PDT) Message-ID: <518A7588.8060300@jitsi.org> Date: Wed, 08 May 2013 18:55:52 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk9ZAI9oF+HYxa5sCatffNGyPnhKOXM2FosfJwqUN0nx7/s+4+DAdgC3NR/bGNpkGVlhiLD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:56:08 -0000 On 08.05.13, 18:38, Martin Thomson wrote: > On 8 May 2013 04:00, Harald Alvestrand wrote: >> To put a blunt point on it: Either send less than ~32 streams, or give >> a=ssrc attributes. > > > This doesn't worry me in the slightest. Legacy endpoints and those > that have trouble accessing SSRC information wont be able to use lots > of streams. I don't agree with this. Unavailable SSRC information could mean a bunch of things and not only "I am a legacy application and I don't know how to talk to my media stack". There's also the case of de-coupled applications for example. I may want to invite you into a conference that's hosted on an RTP translator. I don't necessarily know who else will be connecting to that translator and requiring that I learn this is 1) unnecessary 2) potentially extremely complicated in many cases. Emil -- https://jitsi.org From martin.thomson@gmail.com Wed May 8 08:56:44 2013 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 5EA7821F91CE for ; Wed, 8 May 2013 08:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLlcu7vXP2GT for ; Wed, 8 May 2013 08:56:43 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 113BF21F94A4 for ; Wed, 8 May 2013 08:56:41 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so1937423lab.0 for ; Wed, 08 May 2013 08:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VHDIeUAwNTLAJHHx+lmL6RpFtLNwJvlNJVOmB3jNl4w=; b=Qny6jZ3KkA/bUxUsFIWlK0DXO1S+hz5wlrXsZD8edpbLYSea62EOCpIT5PTHAp9Ra4 AYDWsQ0aPqfESCV7C/bo9MFVwzK91alcLJUaEoFHQ1wVgR4GnKK0RqniHhc7uijWZcVz 6gD2QcRIK2HR/nK84XQJszgEGCEMjR/PH6kijUrfF9gUXedNR5NTVbFPSjNVa3vfWb/B 9uVeSH1zYpCtxBciMh8zqK4+5hBHLFaqFIYv/LDqyoEeczHNMn640bCpSLcKhOSyCmIV MVMdjMtl4Zp8GaDHeGCye+aL0hxOUGVljPD7hpAk/Jm48DFeabe6BwRCF/niAiDY/Zjs KvWw== MIME-Version: 1.0 X-Received: by 10.152.5.2 with SMTP id o2mr3493334lao.31.1368028600729; Wed, 08 May 2013 08:56:40 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 08:56:40 -0700 (PDT) In-Reply-To: <518A3106.1070107@alvestrand.no> References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <518A3106.1070107@alvestrand.no> Date: Wed, 8 May 2013 08:56:40 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:56:44 -0000 On 8 May 2013 04:03, Harald Alvestrand wrote: > There's a paragraph in draft-ietf-mmusic-msid about this: > > 4.1. Handling of non-signalled tracks > > Pre-WebRTC entities will not send msid. This means that there will > be some incoming RTP packets with SSRCs where the recipient does not > know about a corresponding MediaStream id. > > Handling will depend on whether or not any SSRCs are signaled in the > relevant m-line(s). There are two cases: > > o No SSRC is signaled with an msid attribute. The SDP session is > assumed to be a backwards-compatible session. All incoming SSRCs, > on all m-lines that are part of the SDP session, are assumed to > belong to independent media streams, each with one track. The > identifier of this media stream and of the media stream track is a > randomly generated string; the label of this media stream will be > set to "Non-WMS stream". > > So for the non-msid case, we already have this signal in the WebRTC API - > it's called "onaddstream". This always confused me, so I ignored it. Why is the IETF making proscriptive statements about API behavior? I'm pretty sure that when rtcweb did that it was wrong, but now mmusic has done it. I don't think that this specific behavior is correct on a couple of levels. For the ones that we are expected to discuss in the IETF, this relates to the point Adam raised about how multiple SSRCs are rendered. The ramifications for the API are something I'd rather discuss in the W3C, preferably after the first issue is resolved. From martin.thomson@gmail.com Wed May 8 09:08:03 2013 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 6A82821F93C6 for ; Wed, 8 May 2013 09:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1GWZ9ydtUyq for ; Wed, 8 May 2013 09:08:02 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6578621F93C4 for ; Wed, 8 May 2013 09:08:02 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so1947643lab.0 for ; Wed, 08 May 2013 09:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VD+2OtPwYHG0XGATku+lSA9t9VmjgGw7huSf6S5j8m0=; b=bxwn2hRWYLrYHqIdgqfXF8YiFhbzCJpAb3Z1Zs4jg6PAiqOaO/Bkt0scx07i/5Jo3H cs1SStwiqXunfFgh+h/bcCHbEozDfh8A+99IarRLX8iOevmbPPvTvYI6VTChhddshu+c 6yqm26ei+e19Be4ICC0H2FXpz6/N7BIy4IBFod3j5B9fhHW72MAQ3GpSB6aoa7SbQ4Rd BmXlVo6UloHzc5Njb7IByjdPmbxYjEYNkrI+qnODJ/+V5mlnQBVvyIr+hoOwfi35CZwi 3p+007CEmd8lhKLN0eCemeO5fgRGNq/MPxzzWtb1Vy7M+i/IushZhXQjofXGduI0OGRX kN1g== MIME-Version: 1.0 X-Received: by 10.112.160.1 with SMTP id xg1mr3500137lbb.110.1368029281269; Wed, 08 May 2013 09:08:01 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 09:08:01 -0700 (PDT) In-Reply-To: <518A7588.8060300@jitsi.org> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518A7588.8060300@jitsi.org> Date: Wed, 8 May 2013 09:08:01 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:08:03 -0000 On 8 May 2013 08:55, Emil Ivov wrote: >> This doesn't worry me in the slightest. Legacy endpoints and those >> that have trouble accessing SSRC information wont be able to use lots >> of streams. > > I don't agree with this. Unavailable SSRC information could mean a bunch > of things and not only "I am a legacy application and I don't know how > to talk to my media stack". > > There's also the case of de-coupled applications for example. I may want > to invite you into a conference that's hosted on an RTP translator. I > don't necessarily know who else will be connecting to that translator > and requiring that I learn this is 1) unnecessary 2) potentially > extremely complicated in many cases. I separated the two classes. There are legacy apps that don't produce SSRC. And there are apps that find it difficult to get SSRC info. In both cases, PT demux is not going to be an option beyond a certain scale. From emil@sip-communicator.org Wed May 8 09:13:20 2013 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 495A121F958A for ; Wed, 8 May 2013 09:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK+MnT9oe-lV for ; Wed, 8 May 2013 09:13:15 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id C280221F9588 for ; Wed, 8 May 2013 09:13:14 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id b57so1066568eek.19 for ; Wed, 08 May 2013 09:13:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1ZXuR5soB6KIhqpQ58dZX7X2o5zXdR95dinNjb9vIo8=; b=Zw94QSnse3ZByUzMVePuenjEYaFrn97QnTVr+rIUZG7ZZD6E/mNhHi9/cyPuyZk+5L Dxs6vmjynhpSVbBgK7vJ7KNttR1dleXeV39OKY4a1zmDZWOFzI0LOny4H3TStZGoddpM anQYwYBWkOI0zo6mnmBczLgYXKFSmRlnniD1d+jfJh5Ubm5iS+C6j8sYtSBdqYZ4iWTq 4aokhUy94rz/vIrR+ctFBNi/Cs5YyrTmm0Z/IYClg/N36uGEt43s+mjy07F1fl6lZcLC afLbwT2xbbYmigybWuJeFrIiBtvuBjo7gRCabwbSQVfOXHLqTa0qxog5vyq50TKi7UWa z6Mg== X-Received: by 10.14.203.73 with SMTP id e49mr18447871eeo.20.1368029593599; Wed, 08 May 2013 09:13:13 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id k43sm46271379een.2.2013.05.08.09.13.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 09:13:12 -0700 (PDT) Message-ID: <518A7994.8040303@jitsi.org> Date: Wed, 08 May 2013 19:13:08 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518A7588.8060300@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlXuosTLhyQ7cFlEKW/h30HzMWb6+UflXxGB0aLnHnrpARLtLBqZBP5lgv7HOEV9pdxNF6A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:13:20 -0000 On 08.05.13, 19:08, Martin Thomson wrote: > On 8 May 2013 08:55, Emil Ivov wrote: >>> This doesn't worry me in the slightest. Legacy endpoints and those >>> that have trouble accessing SSRC information wont be able to use lots >>> of streams. >> >> I don't agree with this. Unavailable SSRC information could mean a bunch >> of things and not only "I am a legacy application and I don't know how >> to talk to my media stack". >> >> There's also the case of de-coupled applications for example. I may want >> to invite you into a conference that's hosted on an RTP translator. I >> don't necessarily know who else will be connecting to that translator >> and requiring that I learn this is 1) unnecessary 2) potentially >> extremely complicated in many cases. > > I separated the two classes. There are legacy apps that don't produce > SSRC. And there are apps that find it difficult to get SSRC info. In > both cases, PT demux is not going to be an option beyond a certain > scale. Well in that case the "won't be able to use lots of streams" part doesn't necessarily apply. In the RTP translator case described above one could easily have hundreds of SSRCs and hundreds of streams. This would actually be all the more reason not to mandate SSRCs during O/A. -- https://jitsi.org From worley@shell01.TheWorld.com Wed May 8 09:18:09 2013 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 4144021F95EC for ; Wed, 8 May 2013 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVCtY+SVMsan for ; Wed, 8 May 2013 09:18:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4B98E21F95EF for ; Wed, 8 May 2013 09:18:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r48GHkgh032760 for ; Wed, 8 May 2013 12:17:48 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r48GHkW74373147 for ; Wed, 8 May 2013 12:17:46 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r48GHkcx4369224; Wed, 8 May 2013 12:17:46 -0400 (EDT) Date: Wed, 8 May 2013 12:17:46 -0400 (EDT) Message-Id: <201305081617.r48GHkcx4369224@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: (ted.ietf@gmail.com) Subject: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:18:09 -0000 I see that draft-roach-rtcweb-glareless-add-00 eliminates glare a the SDP offer/answer level, but it seems to do so by having glare at the higher "solicitation" level -- the designated answer can discover that it has received an offer that is not correspondent with the solicitation that it has sent. The result is that the proposal includes a bunch of logic which has the structure of glare-resolution logic. The benefit of the proposal is that it avoids "When [glare] happens mid-session, user experience can be negatively impacted." But I don't fully understand what the negative user experience impact is or how this proposal eliminates it -- given that glare can still happen. As far as I can tell so far, the core advantage is that this proposal resolves glare faster than the RFC 3261 (section 14) procedure because the designated answerer is required to process the updated offer it receives even if that is not the updated offer it has solicited. After that, its solicitation is expected to be acted upon by the designated offerer. I haven't thought through the details, but it seems to me that the same effect could probably be achieved by negotiating an amendment to the RFC 3261 glare-recovery procedure with similar properties, e.g., (1) designating one endpoint as the being required to process a received re-INVITE even if it has a re-INVITE outstanding, and (2) allowing the other endpoint to immediately send a new re-INVITE after processing a received re-INVITE. There's also the question how this gets negotiated across a gateway to SIP. Dale From ekr@rtfm.com Wed May 8 09:26:05 2013 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 813A521F8ED8 for ; Wed, 8 May 2013 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.825 X-Spam-Level: X-Spam-Status: No, score=-99.825 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEJYeLrYcHte for ; Wed, 8 May 2013 09:26:00 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 35D0221F8ECA for ; Wed, 8 May 2013 09:26:00 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id c10so1129380qcz.27 for ; Wed, 08 May 2013 09:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=2Sfd6lEkxOQHSyjiWmEZVZKSx8ZwbGIuXUNJKzuFHvU=; b=eUdngE+4DYjEHOuoCwRLBZn/d8JNM6eoqTX81yvjxQgx/EWU2BXetL90gm9A5GWz0n bjGM63QJYht8/BIm9QUR6ILdfnPlaccFvG3Zj6GP1Qz+0c6EcHymXdN335L7gqLP3W/U WLkIIRumvp5ACNMK4qE37Y8nudX12y/JKcGUMGuV97q8dfUL9KmKcpRe8IxdzSyaEVo7 kCX/Hs5gTh9uhvSMg3ZqQ2a+SLghRf6hsnoCm0tBiXpzAVvI3w42JSl9RyRlNt0IrDvN A26M8ff4DQUIH1ZlUTk3iXrdQJGvNs1qzVUPu4D7sYHXXaIwNe7se4SshUQezNZF6LTy 51RA== X-Received: by 10.224.182.136 with SMTP id cc8mr5644570qab.10.1368030359514; Wed, 08 May 2013 09:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.18.231 with HTTP; Wed, 8 May 2013 09:25:18 -0700 (PDT) X-Originating-IP: [173.196.220.110] In-Reply-To: <518A304A.1030609@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> From: Eric Rescorla Date: Wed, 8 May 2013 09:25:18 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf30363d3f9f380a04dc3763c1 X-Gm-Message-State: ALoCoQmd1Wn1NcpNCACXRQGAJi4XQFflJ4Ry+lq7yn7qbXS9zWSmkG7i4Xt6i63TzdVVpbnLmV/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:26:05 -0000 --20cf30363d3f9f380a04dc3763c1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 8, 2013 at 4:00 AM, Harald Alvestrand wrote: > The paragraph that worries me most is this one: > > > Offerers conformant to this specification MUST do one of the > following: > > o Use non-overlapping PT values for each m-line in any given bundle > group. > > o Provide distinct a=ssrc attributes for each m-line which uses > overlapping PT values with any other m-line. [Technically, this > is a general case of the previous point.] > > > > To put a blunt point on it: Either send less than ~32 streams, or give > a=ssrc attributes. > > To me, that measn we're mandating one mechanism (PT values) for small > numbers of flows, and another mechanism (a=ssrc) for large numbers of flows > - such mechanism changes usually have "interesting" properties in what > happens at the changeover point. > That doesn't sound *quite* right to me. As I read the document, implementations are free to: (a) offer entirely disjoint PTs for all the m-lines in a given bundle, in which case they must consume in total less than about 96 PTs (b) offer a=ssrc in which case they must only guarantee that each m-line doesn't internally repeat PTs (i.e., the current guarantee that you don't say that 102 is both VP8 and H.264 on the same m-line.) I would think that a smart implementation would try to use disjoint PTs to the extent possible (thus allowing early demuxing) but also offer a=ssrc, so that if they ran out of PTs, the transition was smooth. Obviously there is potential for bugs here, but this seems like code that would get fairly well tested in the field, no? > It would seem to me to be architecturally cleaner to insist that a=ssrc > be used always. > But in that case, I have a very large difficulty seeing the important > advantage this has over Plan B. > Isn't the argument that Plan A preserves all the existing SDP negotiation mechanisms but allows them to be used with a high level of muxing, rather than reinventing some subset of them at the SDP level? -Ekr > --20cf30363d3f9f380a04dc3763c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 8, 2013 at 4:00 AM, Harald A= lvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
The paragraph that worries me most is this one:

=20 

   Offerers conformant to this specification MUST do one of the
   following:

   o  Use non-overlapping PT values for each m-line in any given bundle
      group.

   o  Provide distinct a=3Dssrc attributes for each m-line which uses
      overlapping PT values with any other m-line.  [Technically, this
      is a general case of the previous point.]

To put a blunt point on it: Either send less than ~32 streams, or give a=3Dssrc attributes.

To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=3Dssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover = point.

That doesn't sound *= quite* right to me.

As I read the document, implem= entations are free to:

(a) offer entirely disjoint PTs for all the m-lines in = a given bundle, in
=A0 =A0 =A0 which case they must consume in to= tal less than about 96 PTs
(b) offer a=3Dssrc in which case they = must only guarantee that each
=A0 =A0 =A0 m-line doesn't internally repeat PTs (i.e., the curren= t guarantee
=A0 =A0 =A0 that you don't say that 102 is both V= P8 and H.264 on the same
=A0 =A0 =A0 m-line.)

I would think that a smart implementation would try to use disjoint
PTs to the extent possible (thus allowing early demuxing) but
also offer a=3Dssrc, so that if they ran out of PTs, the transition was
smooth. Obviously there is potential for bugs here, but this seems=
like code that would get fairly well tested in the field, no?

=A0
It would seem to me to be architecturally cleaner to insist that a=3Dssrc be used always.
But in that case, I have a very large difficulty seeing the important advantage this has over Plan B.

Isn't the argument that Plan A preserves all the exist= ing SDP negotiation
mechanisms but allows them to be used with a = high level of muxing,
rather than reinventing some subset of them at the SDP level?

-Ekr

=A0
--20cf30363d3f9f380a04dc3763c1-- From martin.thomson@gmail.com Wed May 8 09:26:35 2013 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 0504421F93BA for ; Wed, 8 May 2013 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.666 X-Spam-Level: X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahR89QOm9f3I for ; Wed, 8 May 2013 09:26:30 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9913421F93B4 for ; Wed, 8 May 2013 09:26:29 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id w10so2105351lbi.26 for ; Wed, 08 May 2013 09:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PuzPaA+dVkyZlktGMcrEJXTLZTC9VN7evA5mel32Ylo=; b=c5oz5uxmy8MNTKHccqsb+nyaM1+kmsrdpm+vhtmE9wJ9+E4KfQx0Fck3qRJtMVCtYy 2tC2BO3y4dnjzuxK5BsKpntGFJ6CldFQRslLU7QzHAan79wNjQshspZielImE7LUOsYq 9LOSexJa2DBXDcCLm5RJwSECYQ3NlZy4hje62WEJdXRoLLDrrs1o8ro1TBPrDfdebdt8 6D8qbLrsWAT1toc+/1cYTNqgTEKpUToZYovdeUJkl2LYTyqm5YQOK2+5C6EEUXmfkapD wmoKmcCmRtdwg3n2QuN8ESaKVVRWLADMLPF33eTzC+IH2jqH7M1QIloP/lklx4N3/GDG c9+Q== MIME-Version: 1.0 X-Received: by 10.112.159.1 with SMTP id wy1mr3542470lbb.80.1368030388426; Wed, 08 May 2013 09:26:28 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 09:26:28 -0700 (PDT) In-Reply-To: <518A7994.8040303@jitsi.org> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518A7588.8060300@jitsi.org> <518A7994.8040303@jitsi.org> Date: Wed, 8 May 2013 09:26:28 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:26:35 -0000 On 8 May 2013 09:13, Emil Ivov wrote: > Well in that case the "won't be able to use lots of streams" part > doesn't necessarily apply. In the RTP translator case described above > one could easily have hundreds of SSRCs and hundreds of streams. Yeah, I wouldn't recommend the use of SDP for signaling that sort of session. > This would actually be all the more reason not to mandate SSRCs during O/A. If you plan to a) add lots and lots of streams to the same RTP session and b) can't know ahead of time what the SSRCs are going to be. Then no current SDP proposal is going to work for you. From emcho@sip-communicator.org Wed May 8 09:44:31 2013 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 77E4021F92CF for ; Wed, 8 May 2013 09:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyN1l9NVEfc6 for ; Wed, 8 May 2013 09:44:31 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DE61221F9253 for ; Wed, 8 May 2013 09:44:30 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so1726857vbe.19 for ; Wed, 08 May 2013 09:44:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=grm20ZBmCVniuw4CGV7N5kjMFwdTPqfLUkLRUK77mLU=; b=QeCIZO2cPJScDk3Fxwvc5a7FffyUbPhGWa+qVuloQvxZmBN+Mx7C3a7UIOoCFK197L 86Apb50aVTLizxnLETBj59AHdBD7abQGFPYk0eadUwGwVmxb4V7fKZ4HVHuxerJ3RZQ2 EzAYvhR9bXbk8Qop+i3pyCPzehoveoxb14OUQVvu/4316iHgF9tOhlZoEQ3KiY6UEoui 46Q54xxxXycmj0cjBKNtkgX67MsC8F7YzCOBa60DjyzTqDlONgQAhsZEHhky6m4HtJdN tZ4dFpSYfzZlhaTZV1JXvNzUe1XBRaG1obgVE0+6o7Bt7Z9NRPEwMZdxKaJ/2KBXH7PG gWWA== X-Received: by 10.220.168.71 with SMTP id t7mr2146607vcy.39.1368031470255; Wed, 08 May 2013 09:44:30 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [2607:f8b0:400c:c01::229]) by mx.google.com with ESMTPSA id nr3sm7894708veb.4.2013.05.08.09.44.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 09:44:30 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jz10so2032613veb.0 for ; Wed, 08 May 2013 09:44:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.221.4.131 with SMTP id oc3mr5213595vcb.46.1368031016319; Wed, 08 May 2013 09:36:56 -0700 (PDT) Received: by 10.220.97.129 with HTTP; Wed, 8 May 2013 09:36:55 -0700 (PDT) Received: by 10.220.97.129 with HTTP; Wed, 8 May 2013 09:36:55 -0700 (PDT) In-Reply-To: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518A7588.8060300@jitsi.org> <518A7994.8040303@jitsi.org> Date: Wed, 8 May 2013 19:36:55 +0300 Message-ID: From: Emil Ivov To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01293fe2c52df604dc378a39 X-Gm-Message-State: ALoCoQk0uAkurN4183ax070jCx/c2Iuc0vBTviaien9x3g8D6A8aH3ASuAuGTbdK7Hvv7e+oZr9M Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:44:31 -0000 --089e01293fe2c52df604dc378a39 Content-Type: text/plain; charset=ISO-8859-1 On May 8, 2013 7:26 PM, "Martin Thomson" wrote: > > On 8 May 2013 09:13, Emil Ivov wrote: > > Well in that case the "won't be able to use lots of streams" part > > doesn't necessarily apply. In the RTP translator case described above > > one could easily have hundreds of SSRCs and hundreds of streams. > > Yeah, I wouldn't recommend the use of SDP for signaling that sort of session. Wouldn't be my first choice either ... or last. Fortunately SDP is only necessary to signal the m-line. SSRCs could be handled out of band if only browsers would allow for it. > > This would actually be all the more reason not to mandate SSRCs during O/A. > > If you plan to a) add lots and lots of streams to the same RTP session > and b) can't know ahead of time what the SSRCs are going to be. Then > no current SDP proposal is going to work for you. Why not? To me this issue is orthogonal to SDP. If the browser would only let the application provide the m-line to SSRC relation in cases where it isn't in the SDP, then we should be fine. --sent from my mobile --089e01293fe2c52df604dc378a39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 8, 2013 7:26 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 8 May 2013 09:13, Emil Ivov <= emcho@jitsi.org> wrote:
> > Well in that case the "won't be able to use lots of stre= ams" part
> > doesn't necessarily apply. In the RTP translator case describ= ed above
> > one could easily have hundreds of SSRCs and hundreds of streams.<= br> >
> Yeah, I wouldn't recommend the use of SDP for signaling that sort = of session.

Wouldn't be my first choice either ... or last. Fortunat= ely SDP is only necessary to signal the m-line. SSRCs could be handled out = of band if only browsers would allow for it.

> > This would actually be all the more reason not to = mandate SSRCs during O/A.
>
> If you plan to a) add lots and lots of streams to the same RTP session=
> and b) can't know ahead of time what the SSRCs are going to be. = =A0Then
> no current SDP proposal is going to work for you.

Why not? To me this issue is orthogonal to SDP. If the brows= er would only let the application provide the m-line to SSRC relation in ca= ses where it isn't in the SDP, then we should be fine.

--sent from my mobile

--089e01293fe2c52df604dc378a39-- From adam@nostrum.com Wed May 8 11:24:58 2013 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 9993E21F90B9 for ; Wed, 8 May 2013 11:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU0A207eBTdl for ; Wed, 8 May 2013 11:24:57 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A80F421F8F41 for ; Wed, 8 May 2013 11:24:57 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r48IOpud074344 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 May 2013 13:24:51 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <518A9872.8060100@nostrum.com> Date: Wed, 08 May 2013 13:24:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201305081617.r48GHkcx4369224@shell01.TheWorld.com> In-Reply-To: <201305081617.r48GHkcx4369224@shell01.TheWorld.com> Content-Type: multipart/alternative; boundary="------------040307040603070207080708" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:24:58 -0000 This is a multi-part message in MIME format. --------------040307040603070207080708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/8/13 11:17, Dale R. Worley wrote: > I see that draft-roach-rtcweb-glareless-add-00 eliminates glare a > the SDP offer/answer level, but it seems to do so by having glare at > the higher "solicitation" level -- the designated answer can discover > that it has received an offer that is not correspondent with the > solicitation that it has sent. The result is that the proposal > includes a bunch of logic which has the structure of > glare-resolution logic. The logic is actually much, much simpler in that it only requires queuing of an outstanding operation rather than the relatively messy (and time consuming) business of backing off and running timers. I will also emphasize that the condition you're describing arises far, far less frequently than general glare. In the vast majority of the cases (where the number of m= sections is not changing), the queuing isn't even necessary. The only cases requiring queuing are those in which the offerer isn't trying to add streams but the answerer is. > The benefit of the proposal is that it avoids "When [glare] happens > mid-session, user experience can be negatively impacted." But I > don't fully understand what the negative user experience impact is or > how this proposal eliminates it -- given that glare can still > happen. I don't think it's really fair to characterize the situation you're describing as glare. It's more of a system-wide enforcement of event ordering according to the order in which they occur at a cannonical observer. We've just arbitrarily chosen that observer to be whichever party offers first. > As far as I can tell so far, the core advantage is that this > proposal resolves glare faster than the RFC 3261 (section 14) > procedure because the designated answerer is required to process the > updated offer it receives even if that is not the updated offer it > has solicited. I think the core advantage is that the situation in which any exceptional behavior arises is several orders of magnitude more rare than the situation in which generalized glare can arise. > I haven't thought through the details, but it seems to me that the > same effect could probably be achieved by negotiating an amendment > to the RFC 3261 glare-recovery procedure with similar properties... Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :) > There's also the question how this gets negotiated across a gateway > to SIP. Section 3. /a --------------040307040603070207080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/8/13 11:17, Dale R. Worley wrote:
> I see that draft-roach-rtcweb-glareless-add-00 eliminates glare a
> the SDP offer/answer level, but it seems to do so by having glare at
> the higher "solicitation" level -- the designated answer can discover
> that it has received an offer that is not correspondent with the
> solicitation that it has sent.  The result is that the proposal
> includes a bunch of logic which has the structure of
> glare-resolution logic.

The logic is actually much, much simpler in that it only requires queuing of an outstanding operation rather than the relatively messy (and time consuming) business of backing off and running timers.

I will also emphasize that the condition you're describing arises far, far less frequently than general glare. In the vast majority of the cases (where the number of m= sections is not changing), the queuing isn't even necessary. The only cases requiring queuing are those in which the offerer isn't trying to add streams but the answerer is.

> The benefit of the proposal is that it avoids "When [glare] happens
> mid-session, user experience can be negatively impacted."  But I
> don't fully understand what the negative user experience impact is or
> how this proposal eliminates it -- given that glare can still
> happen.

I don't think it's really fair to characterize the situation you're describing as glare. It's more of a system-wide enforcement of event ordering according to the order in which they occur at a cannonical observer. We've just arbitrarily chosen that observer to be whichever party offers first.

> As far as I can tell so far, the core advantage is that this
> proposal resolves glare faster than the RFC 3261 (section 14)
> procedure because the designated answerer is required to process the
> updated offer it receives even if that is not the updated offer it
> has solicited.

I think the core advantage is that the situation in which any exceptional behavior arises is several orders of magnitude more rare than the situation in which generalized glare can arise.

> I haven't thought through the details, but it seems to me that the
> same effect could probably be achieved by negotiating an amendment
> to the RFC 3261 glare-recovery procedure with similar properties...

Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :)

> There's also the question how this gets negotiated across a gateway
> to SIP.

Section 3.

/a

--------------040307040603070207080708-- From harald@alvestrand.no Wed May 8 11:55:48 2013 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 901BE21F8203 for ; Wed, 8 May 2013 11:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGgdlyLe+eh0 for ; Wed, 8 May 2013 11:55:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9786121F902D for ; Wed, 8 May 2013 11:55:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50E3739E1C8; Wed, 8 May 2013 20:55:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXGjrDh6bjeg; Wed, 8 May 2013 20:55:39 +0200 (CEST) Received: from [10.10.0.212] (unknown [212.17.135.146]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6953D39E058; Wed, 8 May 2013 20:55:39 +0200 (CEST) Message-ID: <518A9FAB.3090107@alvestrand.no> Date: Wed, 08 May 2013 20:55:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <518A3106.1070107@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:55:48 -0000 On 05/08/2013 05:56 PM, Martin Thomson wrote: > On 8 May 2013 04:03, Harald Alvestrand wrote: >> There's a paragraph in draft-ietf-mmusic-msid about this: >> >> 4.1. Handling of non-signalled tracks >> >> Pre-WebRTC entities will not send msid. This means that there will >> be some incoming RTP packets with SSRCs where the recipient does not >> know about a corresponding MediaStream id. >> >> Handling will depend on whether or not any SSRCs are signaled in the >> relevant m-line(s). There are two cases: >> >> o No SSRC is signaled with an msid attribute. The SDP session is >> assumed to be a backwards-compatible session. All incoming SSRCs, >> on all m-lines that are part of the SDP session, are assumed to >> belong to independent media streams, each with one track. The >> identifier of this media stream and of the media stream track is a >> randomly generated string; the label of this media stream will be >> set to "Non-WMS stream". >> >> So for the non-msid case, we already have this signal in the WebRTC API - >> it's called "onaddstream". > > This always confused me, so I ignored it. Why is the IETF making > proscriptive statements about API behavior? I'm pretty sure that when > rtcweb did that it was wrong, but now mmusic has done it. Well .... the statement needs to be made. The API document says that MediaStreams that get added to a PeerConnection get signalled with an onaddstream() - you will notice that the quoted text doesn't mention that detail. The decision that when a certain event happens in the protocol, a certain API function happens ... needs to be documented somewhere. Whether that's a protocol document or an API document depends on how far down you consider the coupling to be API, and how far up it's protocol. > > I don't think that this specific behavior is correct on a couple of > levels. For the ones that we are expected to discuss in the IETF, > this relates to the point Adam raised about how multiple SSRCs are > rendered. The ramifications for the API are something I'd rather > discuss in the W3C, preferably after the first issue is resolved. I'm confused. How can we "discuss how multiple SSRCs are rendered" without discussing what the API events that are caused by the protocol events are? This seems wrong to me. We need to have the discussion. The text I quoted is in a document. Let's discuss. From pkyzivat@alum.mit.edu Wed May 8 12:23:28 2013 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 12BE521F8B5F for ; Wed, 8 May 2013 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Ht8XvuM1TQ for ; Wed, 8 May 2013 12:23:23 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1021F89E2 for ; Wed, 8 May 2013 12:23:23 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id ZU3q1l00516LCl055XPNPD; Wed, 08 May 2013 19:23:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ZXPN1l00Y3ZTu2S3SXPNQP; Wed, 08 May 2013 19:23:22 +0000 Message-ID: <518AA629.2090907@alum.mit.edu> Date: Wed, 08 May 2013 15:23:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> <518A4DE0.2040306@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368041002; bh=jFaX3eTyVEZtqur/0ELJ3yqROnIC8meKZIE8viVDXeM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Sr4jWUln3El9ZIA3vxzDDLqIDOdWXCPsTYGOYxfKXOAeLmfXZUsm6oz9rtP5rMh62 1n25/jUV2n8sN+ZStfAyGtoICyRrtAOXXi4k5Dwk6EItOs+kWsrUDDjRChSuh4JBzi hKyuNXeTze2xViTxAbviFHibY5j0p9azyJotcP0KDBASdf/jPFhD0rISo5QXFgGfxr v8T4E8b7WrNeoXj/yHbsuuTIb2UuSfy2UPOFVr7hbZ3a2J+tl4Q5iwWu5k05cPCcJL fP0hmv3CITC5Nn8A2iZC7qBvEEORLzkzKIhltwC4KcdqqmOFIsyhgo2cEMZYKbUrvB Y5IsWexL5GX0Q== Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:23:28 -0000 On 5/8/13 11:47 AM, Martin Thomson wrote: > This is a pretty complicated example, but I agree that it is quite relevant. > > If the camera that can produce Z is attached (to the > RTCPeerConnection), then an offer would include X, Y and Z, but it > would probably have to be marked sendonly. Other m-lines could be > used to offer to receive X and Y. > > I don't see this being solved very well by SDP at all. Regardless of > the option chosen. There are multiple ways to skin this cat: - there could be separate m-lines for sendonly and recvonly (and flipped at the peer). To be safe, you could make everything that way - no sendrecv m-lines. Each stream would be assigned to an m-line with the appropriate directionality. (But this doesn't work well if you want to change the directionality to reflect hold.) - we could make the extension to support a=ssrc:nnn sendonly, etc. That way you can signal the directionality of each individual stream. Presumably in that case an a=sendonly/recvonly/... for the same m-line would apply to any ssrc's that didn't have their own. Thanks, Paul > On 8 May 2013 06:06, Stefan HĆ„kansson LK > wrote: >> One more question (and I think this one is applicable to Plan B as well). It >> has to do with devices with HW encoders. >> >> If I have a system that supports video encoding and decoding of format X and >> Y it is pretty obvious what the offer should look like. >> >> But if I add a camera that can also encode in format Z, what should the >> offer look like? >> >> The camera would not decode, so for sendrecv m-lines format Z could not be >> included in an offer. >> >> Does this mean that to utilize camera encoders (if the corresponding >> decoders are not available in the system), we'd be limited to sendonly >> m-lines? >> >> Stefan >> >> >> >> On 2013-05-08 14:38, Stefan HĆ„kansson LK wrote: >>> >>> A couple of questions (and sorry for the rtcweb/webrtc centric >>> perspective) for clarification: >>> >>> * How would the info about PC-track and PC-stream id's be conveyed (I >>> assume the msid draft)? >>> >>> * What is your thinking regarding mapping between PC-tracks and m-lines? >>> For example, if Alice's app initiates a session with two video >>> PC-track's flowing to Bob's app, that would presumable create a session >>> with two sendonly m-lines. If, at a later stage, Bob's app upgrades the >>> session by sending three video PC-tracks to Alice's app. How would the >>> Bob -> Alice video PC-tracks be allocated to the existing m-lines >>> (becoming sendrecv), and how would pick which one to use a new m-line? >>> E.g., would it be random, or should the app decide, and based on what in >>> that case? >>> >>> Stefan >>> >>> >>> >>> On 2013-05-07 20:30, Adam Roach wrote: >>>> >>>> In order to facilitate discussion between the two SDP format >>>> alternatives we're considering, I've put together a document that more >>>> clearly spells out the Plan A approach as we originally envisioned it. >>>> Note that this is a slightly different approach than Cullen outlined in >>>> Orlando. I fear the Orlando approach may have suffered from its attempts >>>> to incorporate some elements of Plan B in an attempt to appease >>>> proponents of that approach; and, in doing so, lost some of its clean >>>> architecture. >>>> >>>> The cleaned up, new-and-improved description of the Plan A approach is >>>> available here: >>>> >>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>> >>>> Note that we've omitted discussion of glare reduction from that >>>> document, as I believe that mid-session glare can be completely avoided >>>> by applications implementing a set of non-normative behaviors. These >>>> behaviors are described in the a separate companion document: >>>> >>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>> >>>> Thanks. >>>> >>>> /a >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 worley@shell01.TheWorld.com Wed May 8 12:38:12 2013 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 4B51F21F8F27 for ; Wed, 8 May 2013 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfpUaIpNj9UD for ; Wed, 8 May 2013 12:38:06 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9621F21F8EFC for ; Wed, 8 May 2013 12:38:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r48Jb7YZ024758; Wed, 8 May 2013 15:37:09 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r48Jb7VS4381222; Wed, 8 May 2013 15:37:07 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r48Jb4Yr4376144; Wed, 8 May 2013 15:37:04 -0400 (EDT) Date: Wed, 8 May 2013 15:37:04 -0400 (EDT) Message-Id: <201305081937.r48Jb4Yr4376144@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-reply-to: <51898653.1010907@nostrum.com> (adam@nostrum.com) References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> <51898653.1010907@nostrum.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:38:12 -0000 > From: Adam Roach > > I want to re-iterate the most important part of my answer to Paul, since > it allows anyone who can apply apply critical thinking skills to arrive > at the correct conclusion about what we are proposing. Here is the crux > of my answer again, from which the remainder of my answer was derived: > > Looking at basic principles, the intention here is that the > semantics would be identical to non-webrtc, non-bundle clients > receiving multiple SSRCs on the same port. Echoing Jonathan, I don't think that there is a consistent rule for those semantics now. Some devices consider multiple SSRCs to be data from multiple captures, and others consider multiple SSRCs to be alternative representations of the same capture (either simultaneous in time or alternating in time). Or perhaps there is a consistent rule, but there are inconsistent implementations. In which case we should document the correct behavior -- and worry about interoperability. Or perhaps we should define an SDP extension (or tighten the semantics of an existing syntax) to remove the ambiguities. Dale From worley@shell01.TheWorld.com Wed May 8 12:38:13 2013 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 7FBBE21F8F27 for ; Wed, 8 May 2013 12:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krjtazwquTPn for ; Wed, 8 May 2013 12:38:07 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 706B121F8F11 for ; Wed, 8 May 2013 12:38:05 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r48JbRQD015087; Wed, 8 May 2013 15:37:29 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r48JbQbi4380871; Wed, 8 May 2013 15:37:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r48JbQsp4388201; Wed, 8 May 2013 15:37:26 -0400 (EDT) Date: Wed, 8 May 2013 15:37:26 -0400 (EDT) Message-Id: <201305081937.r48JbQsp4388201@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-reply-to: <51896824.2000705@nostrum.com> (adam@nostrum.com) References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:38:13 -0000 This is a promising proposal, but I think a lot more care needs to be taken in defining how port numbers are to be used in this technique. I can't tell what particular uses of port numbers are allowed and what ones are not allowed. And it seems that the intended patterns could result in problematic behaviors from intermediate devices. Erratum: You state "you can always have more than one bundle", but the example in section 6 does not contain an "a=group" attribute. It seems that an offered bundle consists of: - one or more m= lines offering non-zero ports - zero or more m= lines offering zero ports but with "a=bundle-only" Question: Is it true that there must be at least one m= line with a non-zero port, or can *all* the m= lines be bundle-only (if the UA is willing to have none of the media streams if the other UA doesn't support bundling)? If all may have zero ports, what port is to be used for transport? Question: If there is more than one m= line offering non-zero ports, are identical port numbers required/permitted/forbidden? It would appear from backward-compatibility considerations that the answer is "forbidden", but that is not stated. An answered bundle consists of: - zero or more m= lines that are rejected by containing a zero port - one or more m= lines that are accepted by containing a non-zero port Question: If there is more than one m= line offering non-zero ports, are identical port numbers required/permitted/forbidden? You state that the answer is "permitted", but that seems problematic: Question: It is clear what the intended transport association is if both the offer and answer contain only one non-zero port number. What is the intended transport association(s) in other cases? Question: It is possible that the only accepted m= lines in the bundle are ones that were offered with zero ports and "a=bundle-only". This results in an intended packet flow that does not correspond to the offered/answered port for any single one of the m= lines. This may cause problems with intermediate devices. Question: If several m= lines are offered with different ports and they are accepted (with the same port), what is the intended transport association? It seems that in any case, there will be an m= line with an offered/answered port pair that will not receive any traffic, which may cause problems with intermediate devices. Question: There can be an m= line offered with a zero port that is answered with a non-zero port. This contravenes the legacy offern/answer rules and may cause problems with intermediate devices. As an additional matter, there is this statement: An old endpoint simply rejects the bundle-only m-lines by responding with a 0 port. (This isn't a normative statement, just a description of the way the older endpoints are expected to act.) Why is this characterized as "isn't a normative statement"? By legacy offer/answer rules, the endpoint is *required* to respond to an offered zero port with a zero port. Dale From pkyzivat@alum.mit.edu Wed May 8 12:43:54 2013 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 53EE521F8F27 for ; Wed, 8 May 2013 12:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqS+5lXK6w6A for ; Wed, 8 May 2013 12:43:49 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C504F21F8F25 for ; Wed, 8 May 2013 12:43:47 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id ZPNB1l0040xGWP851XjnNK; Wed, 08 May 2013 19:43:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id ZXjn1l0063ZTu2S3YXjnWF; Wed, 08 May 2013 19:43:47 +0000 Message-ID: <518AAAF2.5000207@alum.mit.edu> Date: Wed, 08 May 2013 15:43:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368042227; bh=FKnS2B8Y7L+pAPFeAkHUwNjy93D1g6cpnVz4BiuB5uY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=C6RyReH5sqybutlViFPcy0ABWGRHIjOCyhjRhR06p6QOK+xKBW9A/ek8am2dsb9W6 TQA/Rs6hi3uzsiKNP53C2tXLtXM6cpx2+MsnqPhEuRBlph2btuxq9VQqf3ve9swdor ggQxpbu21F4ogAt7GuRs3N9q+hmQTaVG+mnoLBhHL0Ij82pWDNx6ESULQilcSCchdt cXCHsqxpPX9gd0l1LPyjxbXyGdH+21VXMvuKn0d3dMjxTf47GwULWrxYOfuXHeVc0a axDByVqc/WOhgcNQSmokpnBpa4TsEIS2MnvWGDivuTNEqnI1/2D3hRd9Ibe7r3b//o Xqbvsif6/vMww== Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:43:54 -0000 On 5/7/13 5:56 PM, Bernard Aboba wrote: > Roni said: > > > 3.The draft, as far as I can tell, is discussing point to point calls > and full meshed conferences. I think we need to look at other topologies > including a centralized MCU doing video switch, for example. > > > [BA] There should be an evaluation against the RTP topology bis draft > which would include assessment of compatibility. In addition to "video > switch" I would be interested in RTP translator compatibility as well. > > > 4.In section 4.1 you suggest using the MSID as an indication for > supporting plan B. I think that this may be RTCWEB specific and other > usages like CLUE may use a different way to associate an SSRC to a Media > Capture. My proposal is to use maxssrc. *I* think it is important that clue and rtcweb to be able to coexist in a single endpoint, and for a clue+rtcweb client to interoperate with either another clue+rtcweb client or a pure clue client. Using different indicators in the two environments doesn't help with that. I don't know what MSID would mean in a pure clue environment. If it can serve as an identifier for a clue capture-encoding, then maybe all is well. But I don't know that yet. AFAIK maxssrc has its own meaning, independent of rtcweb or clue or Plan B. Conflating it to mean one of those things seems like a bad idea. I'll change my mind if Plan B ends up meaning nothing more that allowing multiple RTP streams within the m-line. Thanks, Paul From pkyzivat@alum.mit.edu Wed May 8 13:08:09 2013 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 7476A21F8AF8 for ; Wed, 8 May 2013 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1moQMnLyQguZ for ; Wed, 8 May 2013 13:07:52 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 8E92121F85C3 for ; Wed, 8 May 2013 13:07:51 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id ZNDw1l00427AodY55Y7qgo; Wed, 08 May 2013 20:07:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id ZY7q1l00m3ZTu2S3fY7qoQ; Wed, 08 May 2013 20:07:50 +0000 Message-ID: <518AB095.7010401@alum.mit.edu> Date: Wed, 08 May 2013 16:07:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51897B11.60004@nostrum.com> In-Reply-To: <51897B11.60004@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368043670; bh=77bf+j3RU/Rkir62zsOcFyAK4TVi8AH5XHZ8ZS0k5Xg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DNM3Lqb1s2hVZozKvu7X616NGuRUr5Eqgq81XnBEUCXBQR7oNtQeaQEOQVqklmb/n cTJI8LSH2pMuPMnWsnZh4LElxkT5fVxejv3G0otCZk9XqnfpGYPP4VK2U35NEGLJGE jJBAPqjea7pTv+jnfgiCoJuNuoeCALP+ok0KeCqF9RramIEZX/3neBZwhV+VdKTeRN w3rOd0AlsC+Je4CWeywntbwGpLZQgXS151nLS0klLZYG6WM7e4v5IDEU+DgIFCtXMx GPlkPKADK8HluvEqnTx8AIAD7klEtd+k42Ty15stD08HF5AbbGrnWDcHhT97HLksgd LdGkSLMQWSAQw== Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:08:09 -0000 On 5/7/13 6:07 PM, Adam Roach wrote: >> Second, it seems like the avoidance of glare by having a single >> offer/answerer at a time would work in most cases, but I'm wondering >> why the initial exchange isn't simply a request to change roles? If >> the initial offer role is determined by time, one of the options seems to >> be to accede to a request by the other client to become the offerer. > > That's an interesting approach that certainly works just fine. It's > probably worth documenting as an alternative. One thing to note is that > the technique described in my draft is something applications can apply > unilaterally without any standardization work; whether they choose to > perform a solicitation/offer/answer or role-switch/offer/answer is > something implementors can decide to do as they see fit. Implementations > can even do both, with the decision about which approach to use at any > given moment dictated by which works best for the current application > behavior. > > The only real twist this introduces is for the work described in section > 3. If we think this role switching behavior is useful, then it's > probably something that we would want to include in any equivalent SIP > mechanisms. If find the approach in the draft very unappealing. The persistent answerer must send a solicitation that describes the offer it wants the persistent offerer to make on its behalf. You don't explain how this would be encoded, but in general it must be like a delta on the last offer it received. So it will be at least as complex as SDP itself, but different. I expect that defining that will be difficult. But its further complicated because there is no defined signaling to carry it. At least with what we have so far the signaling *can* carry SDP offers and answers. (Though something else can be used.) Switching to the scheme Ted suggests makes it much simpler, since the only new thing required is a signal to request the role change. Note that the "change roles" request is just a variation on token passing. The relationship between single-offerer+change-roles and normal O/A is like that between token ring and ethernet. We know how that battle turned out. I remain dubious that this glare situation is a problem that needs to be fixed. How often will it occur in practice? Is it really worth totally changing the model, and debugging the new one, to fix? And what happens when you interoperate with a traditional O/A app? Thanks, Paul From pkyzivat@alum.mit.edu Wed May 8 13:14:51 2013 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 CFE5C21F8ECA for ; Wed, 8 May 2013 13:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0wAL77QK3tq for ; Wed, 8 May 2013 13:14:47 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5D21F8EBF for ; Wed, 8 May 2013 13:14:46 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id ZPup1l0041uE5Es55YEm3m; Wed, 08 May 2013 20:14:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id ZYEm1l0063ZTu2S3cYEmuS; Wed, 08 May 2013 20:14:46 +0000 Message-ID: <518AB235.3040205@alum.mit.edu> Date: Wed, 08 May 2013 16:14:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Roni Even References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> In-Reply-To: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368044086; bh=oWAwtzZVtUYCCLdWtCXTvaIoQkf2F5u92YaX7AyM88w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eA0ZZluWasBtDxJVmJyEkIatlD71ZaTajf3hGgyjRXID+lIfWSdp8Gb+7tfuEQVbg mTQWGkS+2+NJGxfNvbYaPvpDkcDpgualjuEGut/gBwWPDJA5aedKUuPVkKu1i95ehm XCXiGD4bftQkc6oMasqLiN0mu3+pYg0FbrqD5kUC7d5gYlJxgw0LY8Wd79Ob7mPgmv Vq1hHNOVrdkRVfMO07b95W3CVfJT/chiSMJRziSuRIjyjTLaqii+rM/4rOTgTTYH7c OMYh4sG7HqOzs/fsOyFJNkIzdsH2JioDkykVVIFHv7EdeMgFRnLOrce7xlUV1AChRv oQ9i5V5uODGyw== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:14:51 -0000 On 5/7/13 6:16 PM, Roni Even wrote: > Hi Paul, > The problem in the CLUE case in the example you gave is that the receiver > will get an RTP stream with a new SSRC not in the SDP to the same port and > will need to know how to map it to one of the media capture replacing the > previous one. My assumption was that each m-line would correspond to a capture, and according to what Adam specified, it would have to be demuxed by payload type. And also, according to Adam's assumptions, whatever SSRCs are received would all be assumed to be part of the same capture. So it works in a limited way, without a header extension, used PT demux. But its limited by the number of PTs. > I think that this mode can work in plan B as an additional case, multiple > RTP streams in an m-line but the SSRC or mapping to media capture is done > via RTP header extension. For plan A it works only if it will allow multiple > RTP streams based on the same m-line. The assumption in both cases is that > both sides identify that they understand this specific usage, for example, > by support of the specific header extension Either scheme can be *made* to work for the clue dynamic capture case using a header extension. But we have to work out the details of how. Thanks, Paul > Roni > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 08 May, 2013 12:10 AM > To: Adam Roach > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan A, respun > > On 5/7/13 4:00 PM, Adam Roach wrote: >> On 5/7/13 14:29, Paul Kyzivat wrote: >>> If I bundle an m-line without a=ssrc, and with unique PTs, do you >>> consider it ok if there are multiple "anonymous" flows each complying >>> to the attributes of the m-line? >> >> I presume, by "multiple anonymous flows," you mean multiple series of >> packets with the same PT, but with different SSRC values. >> >>> Or do you assume that all packets with that PT are treated as one >>> flow, switching from one SSRC to another as they are received? >> >> In the example you gave, all of those packets are defined to be >> associated with the same media line. Looking at basic principles, the >> intention here is that the semantics would be identical to non-webrtc, >> non-bundle clients receiving multiple SSRCs on the same port. >> Admittedly, those semantics have never been crystal clear, but my >> experience is that most systems would use this approach to send >> multiple streams that are semantically the same "thing" and should be >> rendered as one "thing" (e.g., window, speaker, etc). >> >> Specifically, we are *not* trying to allow the situation in which (1) >> the SDP has no SSRC for the m-lines in a bundle group; (2) the party >> who generated the SDP receives multiple streams (distinguished, >> presumably, by SSRC) with the same PT, and (3) the recipient then >> deduces that there should be two different rendering outputs (e.g., > windows) as a result. >> That is specifically and intentionally one of the behaviors we removed >> from the Orlando proposal, since it severely dilutes the value of >> preserving existing SDP semantics. >> >> Does that answer the question you're answering? > > Yes, that exactly answers the question I was asking. > > It fits a clue case, of a "dynamic switched capture", where a single logical > flow (capture) may be conveyed via unknown SSRCs. > > But it doesn't cope well with a case where there a several of those, because > each will require distinct PTs, and that may not work. > > To adequately cover that, I think we need the potential to signal a > *different* demux algorithm, instead of PT or SSRC. (We are assuming a new > RTP header extension). > > Bottom line, instead of saying the demux is by ssrc if present, and > otherwise by PT, I suggest that we explicitly signal the demux mechanism, > with options being at least those, plus another one once we get it defined. > > Otherwise I think what you are proposing can work for CLUE. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From pkyzivat@alum.mit.edu Wed May 8 13:22:18 2013 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 09FC821F8F2E for ; Wed, 8 May 2013 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1mdJ5knFQEE for ; Wed, 8 May 2013 13:22:11 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 9570821F8F25 for ; Wed, 8 May 2013 13:22:11 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id ZUG31l0040mv7h051YNAgM; Wed, 08 May 2013 20:22:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id ZYNA1l00c3ZTu2S3XYNAZq; Wed, 08 May 2013 20:22:10 +0000 Message-ID: <518AB3F1.5040109@alum.mit.edu> Date: Wed, 08 May 2013 16:22:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eric Rescorla References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368044530; bh=STc9vLSO7eGQsRFk4JTo46xNfS6jFKqTU7GMZUmOQIY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fahuDpqLTI7W4LgCh34z7YKc6N+eJ+xWTlQXTci39QjNo3r0VJxLXfz5toDH/BXk7 XQtzuuVw6laQxHHAnySb4Tj+gDyUyI0d4tR9bPU/ipO2Ay17T4dv/A0NGnP0AIKop8 3VcQ/CE283HnUsLa3j5VjLQ/fJyhAU21hIHJWwXPqGFf8ftplZ0+kX3l8DEIS4Kh6w zn90aNFpdJU2+X4Lrtg/PGlVAI0mlGLA+PBvJwiBt6SBW0ZW/48S+3h1EfatlU/THs +wf0w0KABkupbxXwBc+f80F/lmTHEAIhFzK0mbiyOUctLivq31hWT0PsT2V+LFfxi1 TpZ5lSU76Zovw== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:22:18 -0000 On 5/7/13 5:12 PM, Eric Rescorla wrote: > > > On Tue, May 7, 2013 at 2:09 PM, Paul Kyzivat > wrote: > > Yes, that exactly answers the question I was asking. > > It fits a clue case, of a "dynamic switched capture", where a single > logical flow (capture) may be conveyed via unknown SSRCs. > > But it doesn't cope well with a case where there a several of those, > because each will require distinct PTs, and that may not work. > > To adequately cover that, I think we need the potential to signal a > *different* demux algorithm, instead of PT or SSRC. (We are assuming > a new RTP header extension). > > > So your thinking is that the offerer would say something like > > m=audio > a=demux-token:ABC > > m=video > a=demux-token:DEF > > > And then at that point he would need to be prepared to demux > RTP packets with header extension [demux=ABC], etc.? I haven't thought about the specific syntax, but it would require *some* new marking associated with each m-line. In principle, a different demux algorithm can be selected for each m-line. But each algorithm imposes some constraints on usage within the bundle. For instance, demux by PT implies that the PTs of the m-line that selects this must be disjoint from those of all other m-lines in the bundle. Demux for a DTLS/SCTP m-line only works for one of those, unless we provide a way to specify specify SCTP port for a DTLS/SCTP m-line. Thanks, Paul From adam@nostrum.com Wed May 8 14:19:03 2013 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 5536721F8B90 for ; Wed, 8 May 2013 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmIWBbHiNNtL for ; Wed, 8 May 2013 14:19:02 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E421F8B65 for ; Wed, 8 May 2013 14:19:01 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r48LIxtk093327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 May 2013 16:19:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <518AC143.2010006@nostrum.com> Date: Wed, 08 May 2013 16:18:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> In-Reply-To: <518AB095.7010401@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------050004060201060706030001" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:19:03 -0000 This is a multi-part message in MIME format. --------------050004060201060706030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/8/13 15:07, Paul Kyzivat wrote: > The persistent answerer must send a solicitation that describes the > offer it wants the persistent offerer to make on its behalf. You don't > explain how this would be encoded, but in general it must be like a > delta on the last offer it received. Sorry, I thought I'd spelled this out relatively clearly: So, for example, if the "persistent answerer" wishes to add a new audio-visual element, it sends a solicitation to the "persistent offerer" indicating that it requires one new audio m-line section and one new video m-line section. What I was trying to say above is that the only information you would need to convey is literally one, two, or three pairs. You don't say what you're planning to do with them, just that you need them. I intentionally left syntax out of the document because giving a non-normative exemplary syntax seems to encourage infinite bikeshedding rather than the high-level discussion that is necessary to form consensus. So, at the risk of encouraging bikeshedders to complain about dictionary key names or XML attributes versus cdata, I'm envisioning something that looks roughly like this (using JSON format): { 'newAudioStreams': 1, 'newVideoStreams': 1, 'newDataChannels': 0 } ...or like this (in XML): (Given that this isn't necessarily subject to standardization -- at least for the WebRTC-only cases -- implementations could really send something as minimal as "[1,1,0]" to get the same point across.) > I remain dubious that this glare situation is a problem that needs to > be fixed. So am I, but Justin seems to be obsessed with it. That's why I'm proposing a non-normative recipe that allows people who are unnecessarily preoccupied with the issue to indulge their peccadillos. The rest of us are free to ignore it. /a --------------050004060201060706030001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/8/13 15:07, Paul Kyzivat wrote:
The persistent answerer must send a solicitation that describes the offer it wants the persistent offerer to make on its behalf. You don't explain how this would be encoded, but in general it must be like a delta on the last offer it received.

Sorry, I thought I'd spelled this out relatively clearly:

   So, for example, if the
   "persistent answerer" wishes to add a new audio-visual element, it
   sends a solicitation to the "persistent offerer" indicating that it
   requires one new audio m-line section and one new video m-line
   section.

What I was trying to say above is that the only information you would need to convey is literally one, two, or three <mediatype,ordinality> pairs. You don't say what you're planning to do with them, just that you need them.

I intentionally left syntax out of the document because giving a non-normative exemplary syntax seems to encourage infinite bikeshedding rather than the high-level discussion that is necessary to form consensus.

So, at the risk of encouraging bikeshedders to complain about dictionary key names or XML attributes versus cdata, I'm envisioning something that looks roughly like this (using JSON format):

{
  'newAudioStreams': 1,
  'newVideoStreams': 1,
  'newDataChannels': 0
}

...or like this (in XML):

<solicitation>
  <newAudio count="1"/>
  <newVideo count="1"/>
  <newData count="0"/>
</solicitiation>


(Given that this isn't necessarily subject to standardization -- at least for the WebRTC-only cases --  implementations could really send something as minimal as "[1,1,0]" to get the same point across.)

I remain dubious that this glare situation is a problem that needs to be fixed.

So am I, but Justin seems to be obsessed with it. That's why I'm proposing a non-normative recipe that allows people who are unnecessarily preoccupied with the issue to indulge their peccadillos. The rest of us are free to ignore it.

/a
--------------050004060201060706030001-- From martin.thomson@gmail.com Wed May 8 14:53:52 2013 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 8991521F90FD for ; Wed, 8 May 2013 14:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPIStGnMOpEW for ; Wed, 8 May 2013 14:53:52 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id BD31121F90FC for ; Wed, 8 May 2013 14:53:51 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id ey16so2438934wid.2 for ; Wed, 08 May 2013 14:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CBJ2wWKYYUYk4nGFseaEoKaTJcpCNJHuYKJeIwDxXAI=; b=pioTWlaoeW1rWvQ3HnsGsLnYhom9r4uBKpZEpTgXRnPqXp4Mkc23QYCIwD7Vvhh4o8 KpQrSHAPdrMcnzHzNv9G0njWpL33D73crjbKspeST3krtBPscGD2h2MwcDluJ0al/W4X pxxStkvIBYfh8jcd7MVqID2HtB9gx2J3W0tK6O14ttrIXF4j65ErlmD85rgnHTeKTXi+ qXoK4qZxni2ZaK0ILhFx6+Bg/W991xs72mDLXX7mQiOQ/Rka1XT6/V6LXDgBQVuRv64k GgwxnwMzwy5TMLdSRA//Lp+iVC9GP2+zzJI/Z2vrbgopZiU+ewX8riSERrh4+t2SIxqp bOOw== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr13264103wic.32.1368050030937; Wed, 08 May 2013 14:53:50 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Wed, 8 May 2013 14:53:50 -0700 (PDT) In-Reply-To: <518A9FAB.3090107@alvestrand.no> References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <518A3106.1070107@alvestrand.no> <518A9FAB.3090107@alvestrand.no> Date: Wed, 8 May 2013 14:53:50 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:53:52 -0000 On 8 May 2013 11:55, Harald Alvestrand wrote: > This seems wrong to me. We need to have the discussion. The text I quoted is > in a document. Let's discuss. How about we start that discussion in mmusic. From martin.thomson@gmail.com Wed May 8 14:56:12 2013 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 47AA521F8C33 for ; Wed, 8 May 2013 14:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lZJEF9OjPyX for ; Wed, 8 May 2013 14:56:11 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9512B21F85EF for ; Wed, 8 May 2013 14:56:11 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so2322501wes.13 for ; Wed, 08 May 2013 14:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zxrVVAxd3RaipA+p1/zUW/OMrQdNhJ11zKgKR9f5G4Y=; b=V4zYpspT3QcXrnIcBgodUI2FnN82VBetQiq9zMUnmr9ODf7nZAJQwraUoMI9nFDdpY PiO61JCXHOb5y/LLkj8+jiKxfD74acqKGdgPiwj++mirClPofPXItSEVs5s26LcQ8KDz dMf/cLNonE5UIhdTVjbe8ajyjQpqY/+IL4ym/vRGvNZUl8nbc+IzniogoU6n5iztvVeZ E4VrOoU9oRWesie9GyVhGvOzmDJq/wMC9h9MHPoMlfQ+oOAdmFiKXmNYd1ZSbD6AoTh/ zK82gOrQ0f3adFYn2ZBS+qfjpBG2pTVqsfn6hNd32DBqkpvoBV1dBZw7dSi7KKdu/Cbb pkIw== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr24716591wic.32.1368050170701; Wed, 08 May 2013 14:56:10 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Wed, 8 May 2013 14:56:10 -0700 (PDT) In-Reply-To: <201305081937.r48JbQsp4388201@shell01.TheWorld.com> References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> <201305081937.r48JbQsp4388201@shell01.TheWorld.com> Date: Wed, 8 May 2013 14:56:10 -0700 Message-ID: From: Martin Thomson To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:56:12 -0000 On 8 May 2013 12:37, Dale R. Worley wrote: > This is a promising proposal, but I think a lot more care needs to be > taken in defining how port numbers are to be used in this technique. > I can't tell what particular uses of port numbers are allowed and what > ones are not allowed. And it seems that the intended patterns could > result in problematic behaviors from intermediate devices. Thankfully, that's a problem that bundle is going to solve, not this document. The only statements that this draft needs to make is with respect to zero vs. non-zero port numbers, and only in the context of a=bundle-only. From ted.ietf@gmail.com Wed May 8 15:01:48 2013 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 3B22121F91D8 for ; Wed, 8 May 2013 15:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDGKIZ5a1lmi for ; Wed, 8 May 2013 15:01:47 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9016E21F8FE9 for ; Wed, 8 May 2013 15:01:47 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so4169270ief.40 for ; Wed, 08 May 2013 15:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fuOAkOLybZ80Vu5VdXWZC1KGysEwLFlhCIxhwLZlZ7c=; b=PykXvBg4eAgCqCei5GCcKSGFz04zq/s/gZwZBBDTrOOn74+IP3/Yh4esToUsvnWZgu +P6fh9zLj73HC+L0bqfgvM8xj3BBXPDGYigFJrdRLGFgUnKCN5Hi5wEZaXxyJpN6ymNd u2kaXBZ9PrGBA+rH7ArawGcprH+Lgad2EvtPz3HGmvX2gWouSyph2yp3S1jq5D0ggt9B fMkNoKOYaECaB/NB2ZD3QsQrHGzF07KKNpl7EAZyNOqjns1WXc7knY1npA3hh5zc/jET e5hS+OM/vKmnhJmLbuE0O6iosBY84c3+SCpQtGlRE3mUBAzi73YXgZa7vQVo63NBmbwS KsQA== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr6657370igj.96.1368050507144; Wed, 08 May 2013 15:01:47 -0700 (PDT) Received: by 10.42.211.16 with HTTP; Wed, 8 May 2013 15:01:47 -0700 (PDT) In-Reply-To: <518AAAF2.5000207@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> Date: Wed, 8 May 2013 15:01:47 -0700 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: multipart/alternative; boundary=14dae934032b83677404dc3c14db Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:01:48 -0000 --14dae934032b83677404dc3c14db Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 8, 2013 at 12:43 PM, Paul Kyzivat < > *I* think it is important that clue and rtcweb to be able to coexist in a > single endpoint, and for a clue+rtcweb client to interoperate with either > another clue+rtcweb client or a pure clue client. Using different > indicators in the two environments doesn't help with that. > > So, can you unpack "coexist"? A single endpoint could certainly have either a clue client or an rtcweb client active at a single moment in time--do you want to say that you want them both to be active and share the same cameras, microphones, etc? regards, Ted > I don't know what MSID would mean in a pure clue environment. If it can > serve as an identifier for a clue capture-encoding, then maybe all is well. > But I don't know that yet. > > AFAIK maxssrc has its own meaning, independent of rtcweb or clue or Plan > B. Conflating it to mean one of those things seems like a bad idea. I'll > change my mind if Plan B ends up meaning nothing more that allowing > multiple RTP streams within the m-line. > > Thanks, > Paul > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --14dae934032b83677404dc3c14db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 8, 2013 at 12:43 PM, Paul Kyzivat <=
*I* think it is important that clue and rtcweb to be able to coexist in a s= ingle endpoint, and for a clue+rtcweb client to interoperate with either an= other clue+rtcweb client or a pure clue client. Using different indicators = in the two environments doesn't help with that.


So, can you unpack "coexist"?=A0 A sing= le endpoint could certainly have either a clue client or an rtcweb client a= ctive at a single moment in time--do you want to say that you want them bot= h to be active and share the same cameras, microphones, etc?=A0

regards,

Ted


=A0
I don't know what MSID would mean in a pure clue environment. If it can= serve as an identifier for a clue capture-encoding, then maybe all is well= . But I don't know that yet.

AFAIK maxssrc has its own meaning, independent of rtcweb or clue or Plan B.= Conflating it to mean one of those things seems like a bad idea. I'll = change my mind if Plan B ends up meaning nothing more that allowing multipl= e RTP streams within the m-line.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

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

--14dae934032b83677404dc3c14db-- From fandreas@cisco.com Wed May 8 18:59:33 2013 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 2B87921F9048 for ; Wed, 8 May 2013 18:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy2BLkcdtNUg for ; Wed, 8 May 2013 18:59:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8654921F902A for ; Wed, 8 May 2013 18:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5534; q=dns/txt; s=iport; t=1368064768; x=1369274368; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=tThVFgrtEX8XYjScsN8X1fq23XgKKTMy7z+oJiro61Y=; b=EguE6QGwod+ASwGKwLRRhGYLy7tQcJ/fIvO8q5OLBBVvALcfOzf/JjRP UI0sSI9bbY335Gdf2+JfS6aC7+WOR94n+iNwUh+0IHAMUg25lW59afZuS +pGWumqOhwP/TUxmY4/tDqltNOQYfzaNEJ5rVsphv10Y1w1QMH0UV2czM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4HAC0Ci1GtJXG8/2dsb2JhbABSgwc3iRq2FnsWbQeCHwEBAQQBAQFrCg0EHAMBAgoWDwkDAgECARUmAggGDQYCAQEFiAMMwTWPFxgGg08DlyyRNYMrIA X-IronPort-AV: E=Sophos;i="4.87,638,1363132800"; d="scan'208,217";a="208129225" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 09 May 2013 01:59:28 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r491xRR2002514 for ; Thu, 9 May 2013 01:59:27 GMT Message-ID: <518B02FF.7030301@cisco.com> Date: Wed, 08 May 2013 21:59:27 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <518B0290.1070509@cisco.com> In-Reply-To: <518B0290.1070509@cisco.com> X-Forwarded-Message-Id: <518B0290.1070509@cisco.com> Content-Type: multipart/alternative; boundary="------------080702030400010208050901" Subject: [rtcweb] Fwd: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 01:59:33 -0000 This is a multi-part message in MIME format. --------------080702030400010208050901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013 Date: Wed, 8 May 2013 21:57:36 -0400 From: Flemming Andreasen To: mmusic CC: rai-ads , IESG Secretary Greetings This is to announce a virtual interim meeting for the MMUSIC Working Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: We are currently also considering having a physical interim meeting the week of June 24th, likely on the US West Coast. We will await the outcome of the virtual interim meeting before making a decision on this but wanted to give people a heads-up for now. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------080702030400010208050901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI


-------- Original Message --------
Subject: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013
Date: Wed, 8 May 2013 21:57:36 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org>
CC: rai-ads <rai-ads@tools.ietf.org>, IESG Secretary <iesg-secretary@ietf.org> 


Greetings

This is to announce a virtual interim meeting for the MMUSIC Working 
Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am 
Pacific Time. The goal of this meeting is to come to a resolution on the 
so-called "Plan A" or "Plan B" approach related to SDP signaling needed 
by RTCWeb, CLUE, etc.  (i.e. do we have potentially lots of "m=" lines 
or very few "m=" lines and to what extent is there sub-negotation and 
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately. For 
now, people should take a close look at the following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt

You may also want to look at 
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt


Thanks

-- Ari & Flemming (MMUSIC co-chairs)


PS: We are currently also considering having a physical interim meeting 
the week of June 24th, likely on the US West Coast. We will await the 
outcome of the virtual interim meeting before making a decision on this 
but wanted to give people a heads-up for now.

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


--------------080702030400010208050901-- From fluffy@iii.ca Wed May 8 19:08:57 2013 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 824BE21F9184 for ; Wed, 8 May 2013 19:08:57 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGFY5AO4KPqn for ; Wed, 8 May 2013 19:08:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D149621F8616 for ; Wed, 8 May 2013 19:08:50 -0700 (PDT) Received: from dhcp-171-68-20-68.cisco.com (unknown [171.68.20.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2F3FD50A85; Wed, 8 May 2013 22:08:48 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> Date: Wed, 8 May 2013 19:08:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 02:08:57 -0000 On May 7, 2013, at 1:39 PM, Christer Holmberg = wrote: > One more question, regarding the bundle-only attribute: >=20 > Q3: Assume the answerer supports BUNDLE, and return an SDP answer with = identical port numbers, as shown in section 7.1. I guess the second = offer will then replace the zero port lines with the actual port value = that the offerer uses for the multiplexing? Yes, I think that would be the best thing to do. It would be consisted = with our direction on allowing things looking at the SDP to get the = correct port From fluffy@iii.ca Wed May 8 19:16:13 2013 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 29FCC21F853A for ; Wed, 8 May 2013 19:16:13 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rHqSs6o-SOd for ; Wed, 8 May 2013 19:16:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6E421F8539 for ; Wed, 8 May 2013 19:16:08 -0700 (PDT) Received: from dhcp-171-68-20-68.cisco.com (unknown [171.68.20.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77B3B509B6; Wed, 8 May 2013 22:16:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <201305081937.r48JbQsp4388201@shell01.TheWorld.com> Date: Wed, 8 May 2013 19:16:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B00AE7C-7BC1-4AA0-8B2B-1D88913F26C7@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> <201305081937.r48JbQsp4388201@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 02:16:13 -0000 Hmm - most of this seems to just be the same as bundle. At least that = was how I read the draft.=20 On May 8, 2013, at 12:37 PM, Dale R. Worley wrote: > This is a promising proposal, but I think a lot more care needs to be > taken in defining how port numbers are to be used in this technique. > I can't tell what particular uses of port numbers are allowed and what > ones are not allowed. And it seems that the intended patterns could > result in problematic behaviors from intermediate devices. >=20 > Erratum: You state "you can always have more than one bundle", but > the example in section 6 does not contain an "a=3Dgroup" attribute. >=20 > It seems that an offered bundle consists of: >=20 > - one or more m=3D lines offering non-zero ports >=20 > - zero or more m=3D lines offering zero ports but with "a=3Dbundle-only"= >=20 > Question: Is it true that there must be at least one m=3D line with a > non-zero port, There must be at least one is how I read the draft when coupled with = current bundle draft=20 > or can *all* the m=3D lines be bundle-only (if the UA is > willing to have none of the media streams if the other UA doesn't > support bundling)? If all may have zero ports, what port is to be > used for transport? >=20 > Question: If there is more than one m=3D line offering non-zero = ports, > are identical port numbers required/permitted/forbidden? It would > appear from backward-compatibility considerations that the answer is > "forbidden", but that is not stated. >=20 > An answered bundle consists of: >=20 > - zero or more m=3D lines that are rejected by containing a zero port >=20 > - one or more m=3D lines that are accepted by containing a non-zero = port >=20 > Question: If there is more than one m=3D line offering non-zero = ports, > are identical port numbers required/permitted/forbidden? You state > that the answer is "permitted", but that seems problematic: Uh, I read this as it is the bundle draft=20 > Question: It is clear what the intended transport association is if > both the offer and answer contain only one non-zero port number. What > is the intended transport association(s) in other cases? whatever bundle says >=20 > Question: It is possible that the only accepted m=3D lines in the > bundle are ones that were offered with zero ports and > "a=3Dbundle-only". This results in an intended packet flow that does > not correspond to the offered/answered port for any single one of the > m=3D lines. This may cause problems with intermediate devices. Seems like the clean up O/A in bundle would clean this up - so same as = bundle=20 >=20 > Question: If several m=3D lines are offered with different ports and > they are accepted (with the same port), what is the intended transport > association? It seems that in any case, there will be an m=3D line = with > an offered/answered port pair that will not receive any traffic, which > may cause problems with intermediate devices. This is the same as bundle >=20 > Question: There can be an m=3D line offered with a zero port that is > answered with a non-zero port. This contravenes the legacy > offern/answer rules and may cause problems with intermediate devices. >=20 > As an additional matter, there is this statement: >=20 > An old endpoint simply rejects the bundle-only m-lines by responding > with a 0 port. (This isn't a normative statement, just a = description > of the way the older endpoints are expected to act.) >=20 > Why is this characterized as "isn't a normative statement"? By legacy > offer/answer rules, the endpoint is *required* to respond to an > offered zero port with a zero port. >=20 > Dale > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Thu May 9 01:58:30 2013 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 255CC21F8E2C for ; Thu, 9 May 2013 01:58:30 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPkGlLucek8C for ; Thu, 9 May 2013 01:58:24 -0700 (PDT) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA5021F8CEC for ; Thu, 9 May 2013 01:58:23 -0700 (PDT) Received: (qmail 67819 invoked from network); 9 May 2013 08:58:21 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 9 May 2013 08:58:21 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id D091918A04C2; Thu, 9 May 2013 09:58:21 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id AB49318A0255; Thu, 9 May 2013 09:58:21 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_86D4F89B-0BC4-4440-9DD2-00035C76D882" From: Tim Panton In-Reply-To: Date: Thu, 9 May 2013 09:58:20 +0100 Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> To: Henry Lum X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 08:58:30 -0000 --Apple-Mail=_86D4F89B-0BC4-4440-9DD2-00035C76D882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 7 May 2013, at 15:55, Henry Lum wrote: > Does the signalling and DTLS media stream need to use the same = certificate or the certificates can be from the same organization right? = The contact center gateway and the recording element would be different = components and hence have different certificates from the same = organization. Yep, you are right - sloppy thinking on my part: same identity !=3D same certificate In my view they should both identify themselves as secure.xyzbank.com - = that doesn't mean the same certificate, just the same identity. I'm less keen on writing rules that match mediaserver.xyzbank.com up = with www.xyzbank.com and presume that these are the same entity. >=20 --Apple-Mail=_86D4F89B-0BC4-4440-9DD2-00035C76D882 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Does = the signalling and DTLS media stream need to use the same certificate or = the certificates can be from the same organization right? The contact = center gateway and the recording element would be different components = and hence have different certificates from the same = organization.

Yep, you are = right - sloppy thinking on my part:
same identity !=3D same = certificate

In my view they should both = identify themselves as secure.xyzbank.com - that doesn't = mean the same certificate, just the same identity.
I'm less = keen on writing rules that match mediaserver.xyzbank.com up = with www.xyzbank.com  and = presume that these are the same entity.



<= br>= --Apple-Mail=_86D4F89B-0BC4-4440-9DD2-00035C76D882-- From stefan.lk.hakansson@ericsson.com Thu May 9 04:41:56 2013 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 6139B21F8E6B; Thu, 9 May 2013 04:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVI5uTR8ocOm; Thu, 9 May 2013 04:41:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7705B21F8E51; Thu, 9 May 2013 04:41:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-dc-518b8b7bb3d3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CF.B1.28165.B7B8B815; Thu, 9 May 2013 13:41:48 +0200 (CEST) Received: from [153.88.16.182] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 9 May 2013 13:41:47 +0200 Message-ID: <518B8B7A.3050509@ericsson.com> Date: Thu, 9 May 2013 13:41:46 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3VremuzvQ4PFrDotrZ/4xWkxd/pjF Yu2/dnYHZo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PQ1yPMBZcFK770vmVqYJzC18XI ySEhYCKx899hVghbTOLCvfVsXYxcHEICpxgl1h9eyAjhrGKUWHDrOhtIFa+AtsSxX/uZQGwW ARWJC+fWMoPYbALBEvuXrwerERWIkvj3djcjRL2gxMmZT1hAbBEBXYlFZx+wg9jMAv4S567s B6rh4BAGmnP4chnErn5GiUW/L7KDxDkFAiVeL3KBKLeQWPzmIFSrvETz1tlga4WARr57fY91 AqPgLCTbZiFpmYWkZQEj8ypG9tzEzJz0csNNjMDgPLjlt+4OxlPnRA4xSnOwKInzJnE1BgoJ pCeWpGanphakFsUXleakFh9iZOLglGpglOPTKpzzKzD58/w0UxXxc9ZrI40mHtwtL673NkSv d7Pbm/98qkmVqzlcX2ubhPoc1lSZ61CuK3REg+tNJuujucLbmDScuaObD63IXiD1fjnLf8ZH +adNZrOJvsmal34nKShLr9Vhs6dm1tuNi+fNaFHQcTrns3+v6YuyTVoTGVyZF/d8MbJVYinO SDTUYi4qTgQAoHP9ChwCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 11:41:56 -0000 On 2013-05-08 17:43, Martin Thomson wrote: > On 8 May 2013 05:38, Stefan HĆ„kansson LK > wrote: >> A couple of questions (and sorry for the rtcweb/webrtc centric perspective) >> for clarification: >> >> * How would the info about PC-track and PC-stream id's be conveyed (I assume >> the msid draft)? > > Yes, that's a solved problem. No sense reiterating it in the draft > (it's orthogonal to what the draft actually addresses). Right, just wanted it clarified. > >> * What is your thinking regarding mapping between PC-tracks and m-lines? For >> example, if Alice's app initiates a session with two video PC-track's >> flowing to Bob's app, that would presumable create a session with two >> sendonly m-lines. If, at a later stage, Bob's app upgrades the session by >> sending three video PC-tracks to Alice's app. How would the Bob -> Alice >> video PC-tracks be allocated to the existing m-lines (becoming sendrecv), >> and how would pick which one to use a new m-line? E.g., would it be random, >> or should the app decide, and based on what in that case? > > Alice's offer would contain at least two m-lines. Those would not > necessarily be sendonly. If she was capable of receiving more than 2 > inbound, the offer could contain recvonly lines too (I believe that > this fits with the OfferToReceiveVideo=n constraint). OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines would be sendonly, 1 would give one sendrecv and one sendonly and so on. So, if OfferToReceiveVideo=0 was used (or was even the default), we would in the case of a symmetric service (Alices's and Bob's apps intending to send the same amount of audio and video tracks, and doing it from the start of the session) actually end up with the same 3-way handshake as in Plan B (since sendonly/recvonly can't be upgraded to sendrecv without a new offer)? (I have no problem with that behavior, I just want to understand) > Of course, if > those lines were not compatible with what Bob wanted to send (too > much, different codecs, different constraints, etc...), then Bob is > required to send another offer to get his media out. ...because new m-lines are required. > From worley@shell01.TheWorld.com Thu May 9 08:13:14 2013 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 5A62D21F90BB for ; Thu, 9 May 2013 08:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RwEYpLkrXbb for ; Thu, 9 May 2013 08:13:08 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5972C21F8FDD for ; Thu, 9 May 2013 08:13:07 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r49FCRtr028446; Thu, 9 May 2013 11:12:29 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r49FCQBY4426003; Thu, 9 May 2013 11:12:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r49FCQZh4436322; Thu, 9 May 2013 11:12:26 -0400 (EDT) Date: Thu, 9 May 2013 11:12:26 -0400 (EDT) Message-Id: <201305091512.r49FCQZh4436322@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Martin Thomson In-reply-to: (martin.thomson@gmail.com) References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> <201305081937.r48JbQsp4388201@shell01.TheWorld.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:13:14 -0000 > From: Martin Thomson > > On 8 May 2013 12:37, Dale R. Worley wrote: > > This is a promising proposal, but I think a lot more care needs to be > > taken in defining how port numbers are to be used in this technique. > > I can't tell what particular uses of port numbers are allowed and what > > ones are not allowed. And it seems that the intended patterns could > > result in problematic behaviors from intermediate devices. > > Thankfully, that's a problem that bundle is going to solve, not this > document. The only statements that this draft needs to make is with > respect to zero vs. non-zero port numbers, and only in the context of > a=bundle-only. OK, I hadn't grasped the degree to which draft-roach-rtcweb-plan-a is intended to be just an amendment to draft-ietf-mmusic-sdp-bundle-negotiation. But it still does introduce new patterns of use of port numbers in m= lines (e.g., an answer can have a non-zero port number for an m= line which had a zero port number in the offer), so we can't just wave our hands and say "draft-bundle-negotiation will solve that" -- it's a substantial change to what bundle-negotiation is proposing and solving the problems that are apparent in bundle-negotiation won't solve all the problems that result if draft-roach-rtcweb-plan-a is added to it. Dale From pkyzivat@alum.mit.edu Thu May 9 08:18:11 2013 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 53CC321F9049 for ; Thu, 9 May 2013 08:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui9e9FWLSBE9 for ; Thu, 9 May 2013 08:18:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1421F8FA5 for ; Thu, 9 May 2013 08:18:03 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id Zn2V1l0060Fqzac53rJ3Ea; Thu, 09 May 2013 15:18:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id ZrJ31l00G3ZTu2S3UrJ33M; Thu, 09 May 2013 15:18:03 +0000 Message-ID: <518BBE2A.4060102@alum.mit.edu> Date: Thu, 09 May 2013 11:18:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> In-Reply-To: <518AC143.2010006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368112683; bh=q4oBfdsBDxxSR7aL4rdaqf5xJjHcuAZpXcbSIVy2B3A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=L0gwDWo6+zlfu3EEdJJtaru2h9y371tvBX9iVhIWDf1GMjO6Hsfpb9Mfd4/fmL8yS D9/n852uC5tWuTAD+cmbemkWCxkm20+olxKZY1rmEPnJgaJ2oPGPljamwXhM0EbJ3T OwuDnZ4P/DNDRMEwSBMCrbl9E8mhA2T6QHdXc9QrwjNvrfS/TtPvxhdfbHoH48IJzp 6voiFirMIzs6Bzis5k2OH3mjWwmtcSJ7viW7NvHDPjdAyX14IYYPYWMq3EQDjJPkVp 5lkzcy6gzcOuktJ9WtH0Mp48qERNgHnOCSEAQ0Q1YITz4IFriaLzDgJpKKboKvsfA7 oTvIJFesblwWw== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:18:11 -0000 On 5/8/13 5:18 PM, Adam Roach wrote: > On 5/8/13 15:07, Paul Kyzivat wrote: >> The persistent answerer must send a solicitation that describes the >> offer it wants the persistent offerer to make on its behalf. You don't >> explain how this would be encoded, but in general it must be like a >> delta on the last offer it received. > > Sorry, I thought I'd spelled this out relatively clearly: > > So, for example, if the > "persistent answerer" wishes to add a new audio-visual element, it > sends a solicitation to the "persistent offerer" indicating that it > requires one new audio m-line section and one new video m-line > section. > > > What I was trying to say above is that the only information you would > need to convey is literally one, two, or three > pairs. You don't say what you're planning to do with them, just that you > need them. How is that possibly enough? What codecs and codec parameters/optons? What bandwidth? What bundling options? The list goes on. > I intentionally left syntax out of the document because giving a > non-normative exemplary syntax seems to encourage infinite bikeshedding > rather than the high-level discussion that is necessary to form consensus. > > So, at the risk of encouraging bikeshedders to complain about dictionary > key names or XML attributes versus cdata, I'm envisioning something that > looks roughly like this (using JSON format): > > { > 'newAudioStreams': 1, > 'newVideoStreams': 1, > 'newDataChannels': 0 > } > > ...or like this (in XML): > > > > > > > > > (Given that this isn't necessarily subject to standardization -- at > least for the WebRTC-only cases -- implementations could really send > something as minimal as "[1,1,0]" to get the same point across.) > >> I remain dubious that this glare situation is a problem that needs to >> be fixed. > > So am I, but Justin seems to be obsessed with it. That's why I'm > proposing a non-normative recipe that allows people who are > unnecessarily preoccupied with the issue to indulge their peccadillos. > The rest of us are free to ignore it. Well, I agree that if somebody wants to do this on their own, then that is their business. If applied in a sufficiently constrained environment the amount of info that needs to be conveyed can be reduced, as you suggest. And of course the token passing approach requires very little to be passed. But I don't want to standardize any of this. Thanks, Paul From pkyzivat@alum.mit.edu Thu May 9 08:32:21 2013 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 0C9BB21F86BB for ; Thu, 9 May 2013 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqFdGie7TmAS for ; Thu, 9 May 2013 08:32:15 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1355921F84F5 for ; Thu, 9 May 2013 08:32:14 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id ZmgP1l0040bG4ec53rYEnH; Thu, 09 May 2013 15:32:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id ZrYD1l0183ZTu2S3PrYEx6; Thu, 09 May 2013 15:32:14 +0000 Message-ID: <518BC17C.7030806@alum.mit.edu> Date: Thu, 09 May 2013 11:32:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Hardie References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368113534; bh=ksa50ghvNzEurrTpPx8RFBNZbqDPZ9QvU442QsxdhZk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HlHV52KepzV0UH2DH4rpwpGiAg6j9C+4gscQJaphAeHImFGhGZlKzDwrIcJquXiDL 2D+SMrGrIwI5kaeTh6oMlf4FzkOl4rn+zdi+D1vFKwa0L7FFhOtqdwcAGslsx2LEkW ZwQreY18vwo8UzRR1KAe9WoXWQYKyRvYeyp/rM1Yf5cLiogRSWoOFI7JJQx45tD0Nv MUQ1R+kXdHGBPuWOFwyY81pWmfVeUVU2Of3hvAKz7CUKXHskCPHiHH4umtDDv43gp0 Hsgou/J4ElAOVPLy48QBWj2Mow0QlkQCP6n0rGCpt1eX6Nn+VOy3yP6WdLVuwUK74a DiAhGN9ojojMg== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:32:21 -0000 On 5/8/13 6:01 PM, Ted Hardie wrote: > On Wed, May 8, 2013 at 12:43 PM, Paul Kyzivat < > > *I* think it is important that clue and rtcweb to be able to coexist > in a single endpoint, and for a clue+rtcweb client to interoperate > with either another clue+rtcweb client or a pure clue client. Using > different indicators in the two environments doesn't help with that. > > > So, can you unpack "coexist"? A single endpoint could certainly have > either a clue client or an rtcweb client active at a single moment in > time--do you want to say that you want them both to be active and share > the same cameras, microphones, etc? What I mean is that I want the capability to *implement* a clue client in a browser, with the media going directly to the peer clue client (or MCU), whether the peer is also a browser or is a native sip clue implementation. Since clue isn't done yet, we can impose some constraints on it to help with that. Within reason. Clue will have its own control protocol, which we intend to define to run over DTLS/SRTP. It should be possible for a browser client to use an RTCWEB data channel for that. And of course clue has needs for many media "flows" (captures in clue-speak), so those need to map directly onto MediaStreamTracks, or something like that in the webrtc world. Whatever signaling is used to indicate bundling usage in SDP in RTCWEB should be consistent with what is used in clue. It would be unpleasant if we had to have a translator in the web server that must translate one SDP notation to another. Thanks, Paul From ted.ietf@gmail.com Thu May 9 08:39:08 2013 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 7767C21F918C for ; Thu, 9 May 2013 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSVisUF8COdE for ; Thu, 9 May 2013 08:39:07 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id CDF0221F8EBC for ; Thu, 9 May 2013 08:39:07 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id b11so5572172iee.23 for ; Thu, 09 May 2013 08:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xsGQrcyKCBrOxrhBsSewdMi1ASUuEmpXMBKIeqRqW7o=; b=bjMMXuT46L3PKs/jfXFZcolIiCykwDfnL0L3eWiexoLCQb4o5M95bQXeKn54uVRCEm 7N0PKLvury28M8Dpp09LrP8jAL3ddnR6HI4F05Saf+u8/4rmKp3lec3BsmLS2f/CvbX9 gfxFo5PUjHWVJYsGL7cL63v7xkkfAESvgnyK74krpbC0eAdQRx/XPtu0rPz0RUGDLvUC wE0hZGgrThlm1F+WIr/onI/12Ra0p8Rbzv2VEvT72Huuf9RG/jNhTiP6/kNFL0HTK9yQ wMf5nhiMqpByFd3jxmCjNjvqfhDyohHILXAGvJFj+wgMBXLupa4Oh4wnnlZlgrQfZduO Vmag== MIME-Version: 1.0 X-Received: by 10.50.18.74 with SMTP id u10mr5535990igd.42.1368113945798; Thu, 09 May 2013 08:39:05 -0700 (PDT) Received: by 10.42.79.73 with HTTP; Thu, 9 May 2013 08:39:05 -0700 (PDT) Date: Thu, 9 May 2013 08:39:05 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e01494736c1febf04dc4ad9fc Subject: [rtcweb] Virtual Interim for SDES will be rescheduled X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:39:08 -0000 --089e01494736c1febf04dc4ad9fc Content-Type: text/plain; charset=ISO-8859-1 Howdy, Given the MMUSIC working group virtual interim is now scheduled for May 23rd, the RTCWEB chairs plan to push back the SDES-focused virtual interim we'd previously announced, so that folks can focus on the Plan A and Plan B discussion to happen there. We will put out a new doodle poll early next week with dates in June. The current plan is that the virtual interim will include discussion of the base security properties, EKT, and some of the other issues which have come up in working group discussion. regards, Ted, Cullen, and Magnus --089e01494736c1febf04dc4ad9fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howdy,

Given the MMUSIC working group virtual interim is now schedul= ed for May 23rd, the RTCWEB chairs plan to push back the SDES-focused virtu= al interim we'd previously announced, so that folks can focus on the Pl= an A and Plan B discussion to happen there.=A0

We will put out a new doodle poll early next week with dates in June.= =A0 The current plan is that the virtual interim will include discussion of= the base security properties, EKT, and some of the other issues which have= come up in working group discussion.

regards,

Ted, Cullen, and Magnus
--089e01494736c1febf04dc4ad9fc-- From adam@nostrum.com Thu May 9 08:39:53 2013 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 B533821F925A for ; Thu, 9 May 2013 08:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewHXnLIc5Jsl for ; Thu, 9 May 2013 08:39:53 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2068921F905F for ; Thu, 9 May 2013 08:39:53 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r49Fdngp019099 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 May 2013 10:39:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <518BC345.6060807@nostrum.com> Date: Thu, 09 May 2013 10:39:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "rtcweb@ietf.org" , Paul Kyzivat References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <518BBE2A.4060102@alum.mit.edu> In-Reply-To: <518BBE2A.4060102@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:39:53 -0000 On 5/9/13 10:18, Paul Kyzivat wrote: > On 5/8/13 5:18 PM, Adam Roach wrote: >> >> What I was trying to say above is that the only information you would >> need to convey is literally one, two, or three >> pairs. You don't say what you're planning to do with them, just that you >> need them. > > How is that possibly enough? What codecs and codec parameters/optons? > What bandwidth? What bundling options? The list goes on. I apologize. I must have done a really poor job in the prose in my draft, since I clearly didn't communicate the fundamental mechanism that I had in mind at all. Let me try with a ladder diagram to see whether that helps illuminate what I'm proposing. Offerer Answerer | | |<----------Solicitation-------------| | (I need 1 new audio 1 new video) | | | | | |-------------SDP Offer------------->| | (Contains two more m-line sections | | than the current session; one | | audio, one video. Both recvonly.) | | | | | |<------------SDP Answer-------------| | (Makes use of the two new m-line | | sections by populating them with | | codec parameters, options, ssrc | | bandwidth, bundling, etc, etc.) | /a From martin.thomson@gmail.com Thu May 9 08:45:49 2013 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 411D621F85CB; Thu, 9 May 2013 08:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeoG4iK3Zqth; Thu, 9 May 2013 08:45:48 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6B45721F85BF; Thu, 9 May 2013 08:45:48 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w60so3168008wes.3 for ; Thu, 09 May 2013 08:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ukWSpKbf6MM2KQxhC7ZTnjmZ76kgr2Ey1KEPLeOf19o=; b=la5YERbAM26xEtVQZKJ4C4tCrqu6ZTKrmBs5swxfDHKsswvBSkB654zwmTCh+2WCvN FJFNKHspVC03cWcogZEByw5N/sW+4GKLb4UHb80pSEZ/f0gPrX6veheIJJL1vjulY+I1 i1j/Hg0iMbzZmJZJ9GOMNN/L7jtbnKAwk0JE0h7L406UhqpUrMNefh8+d+Fx4g3BC76U exI7dpPEF+mD5rU7WiiYK2+BKCaowFEjMrxNBHcXWr76NCJ6tUjtBHiyBtt0BszgmAaO qQ1GWZ3iR/J2E/7Z06Ru37AMZ9hP/ngFL+N/rEvSJSvNi4hlG+jqSF2jfERbnJhO8CvN Umtg== MIME-Version: 1.0 X-Received: by 10.194.61.10 with SMTP id l10mr18964247wjr.32.1368114347411; Thu, 09 May 2013 08:45:47 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 9 May 2013 08:45:47 -0700 (PDT) In-Reply-To: <518B8B7A.3050509@ericsson.com> References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> <518B8B7A.3050509@ericsson.com> Date: Thu, 9 May 2013 08:45:47 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:45:49 -0000 On 9 May 2013 04:41, Stefan H=C3=A5kansson LK wrote: >> Alice's offer would contain at least two m-lines. Those would not >> necessarily be sendonly. If she was capable of receiving more than 2 >> inbound, the offer could contain recvonly lines too (I believe that >> this fits with the OfferToReceiveVideo=3Dn constraint). > > > OK. So if Alice's app used OfferToReceiveVideo=3D0, then both m-lines wou= ld be > sendonly, 1 would give one sendrecv and one sendonly and so on. > > So, if OfferToReceiveVideo=3D0 was used (or was even the default), we wou= ld in > the case of a symmetric service (Alices's and Bob's apps intending to sen= d > the same amount of audio and video tracks, and doing it from the start of > the session) actually end up with the same 3-way handshake as in Plan B > (since sendonly/recvonly can't be upgraded to sendrecv without a new offe= r)? > > (I have no problem with that behavior, I just want to understand) I think that you have it understood. >> Of course, if >> those lines were not compatible with what Bob wanted to send (too >> much, different codecs, different constraints, etc...), then Bob is >> required to send another offer to get his media out. > > > ...because new m-lines are required. Yep. From fluffy@cisco.com Thu May 9 08:49:52 2013 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 B1A2121F9305; Thu, 9 May 2013 08:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmyTl50THxJ5; Thu, 9 May 2013 08:49:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C737F21F90F1; Thu, 9 May 2013 08:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=557; q=dns/txt; s=iport; t=1368114587; x=1369324187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z+9lviSorJsEo7S5ZmyVnkCoNr0nEc1cJYjzM4+bxqE=; b=mWsuhH/nV7qFGLBZSKgbKhq8eL9XngCtsggxMxqpQnyPQDESaf5F8Jfg sJABIcR4aJitZkCZN+rJXVQvfDQfG4nEiH7HlOe8sbY2zBs5Zjk0zk8OV eM68vlKCPQKMS+M0vM7M3AXoglNC6XKapvAG2yDVZqNa5NrxfpQdCbzmb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAOHEi1GtJXHA/2dsb2JhbABSgweDLL0SehZ0gh8BAQEDATouDwIFCwIBCA4UFBAyJQIEDgUIh34FAb17jnUCMQeCdGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208388537" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 09 May 2013 15:49:46 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r49FnkkX029273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:49:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:49:45 -0500 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOTMzUZ6qA2ycCEU+xahGCAxHFJg== Date: Thu, 9 May 2013 15:49:45 +0000 Message-ID: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FE03FE977CBB546B4A57423082B5009@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:49:52 -0000 On May 2, 2013, at 11:08 PM, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as "Pl= an B" - a way to signal multiple MediaStreamTracks in SDP without needing a= separate m=3D line for each. >=20 > Hopefully this will make discussion of this topic easier. I think my largest questions was does an endpoint have to know when it care= ts an offer if that is going to be sent to a legacy end point or not. I'm p= articularly interested in multiscreen video conferences systems.=20 From fluffy@cisco.com Thu May 9 08:55:57 2013 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 C10BF21F8651; Thu, 9 May 2013 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngHOuV1qCxRQ; Thu, 9 May 2013 08:55:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C219421F85E8; Thu, 9 May 2013 08:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2166; q=dns/txt; s=iport; t=1368114947; x=1369324547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x8zslPkmsuXnk0Tx6gT5XTo1DLjXW/+ywzfkF7er9Gs=; b=QDWWea99FVlmhsV9P608/VF3SOVHHFW8Vy7E+4krUvKpDSOXwG6RZURA OCDnrDOZ1n7bM8e2e1ReLhapbMvtoOsjazNGvkHnHdSgDPjHsL0+Vj+UN vKrbmH/7+xenhIcXJP4VrMzFvvOmoD+37CnoNkr+fp6LYAhrWE198OH+g A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAH7Gi1GtJV2Z/2dsb2JhbABSgwc3wAd6FnSCHwEBAQMBAQEBJEcLBQsCAQgiJCcLJQIEDgUIh34FAQy9egSOdQIxB4J0YQOoYYMPgic X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208407207" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 May 2013 15:55:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r49Ftk0k011974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:55:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:55:45 -0500 From: "Cullen Jennings (fluffy)" To: "Mo Zanaty (mzanaty)" Thread-Topic: [MMUSIC] Is bundle just a port override? Thread-Index: AQHOTM2qLSobb9TZDkGuVuUzGWRiZA== Date: Thu, 9 May 2013 15:55:45 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.68] Content-Type: text/plain; charset="Windows-1252" Content-ID: <851923EC09F7454FBB300324ADEB3ACC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:56:00 -0000 Mo,=20 I think the key part of the grouping was it gave a way to say which m-line = to use that still allowed that m-line to later be set to zero. I'm not sayi= ng the grouping adds much but keep in mind it is not really just the port y= ou are selecting. It's all the ICE transport stuff in the candidates so we= would have to more than just a=3Dport, you would also need the a=3Dbundle-= ice-candiaate and perhaps some DTLS info but I'm not sure. It seems somethi= ng like this could work. not sure it would change too much.=20 my 2 cents.. On Mar 18, 2013, at 9:19 PM, Mo Zanaty (mzanaty) wrote: > Does bundle imply anything beyond a simple port override of the m-line po= rt? If not, then why not just directly signal the port override in an attri= bute without any grouping semantics? > =20 > Offer to mux audio and video on the same port: > m=3Daudio 10000 RTP/AVP 0 > m=3Dvideo 10002 RTP/AVP 31 > a=3Dport 10000 > i=3DI really want 10000, but lied on the m-line for fear of confusing you= . Confused yet? > =20 > Answer supports the port override attribute and agrees to mux audio and v= ideo: > m=3Daudio 40000 RTP/AVP 0 > m=3Dvideo 40000 RTP/AVP 31 > a=3Dport 40000 > =85so audio and video ports are 10000<->40000. > =20 > Answer supports the port override attribute but doesn=92t want to demux o= n his end: > m=3Daudio 40000 RTP/AVP 0 > m=3Dvideo 40002 RTP/AVP 31 > a=3Dport 40002 > =85so audio ports are 10000<->40000 and video ports are 10000<->40002. > =20 > Answer doesn=92t support the port override attribute, or doesn=92t want e= ither end to mux: > m=3Daudio 40000 RTP/AVP 0 > m=3Dvideo 40002 RTP/AVP 31 > =85so audio ports are 10000<->40000 and video ports are 10002<->40002. > =20 > Either end can re-offer without lies about ports on the m-line after conf= irming the peer is not confused by muxing, if they want to avoid confusing = intermediaries. > =20 > Has this approach been tried yet? Dismissed? > =20 > Mo > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Thu May 9 08:56:25 2013 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 92BBD21F941D; Thu, 9 May 2013 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0I2pczsw4XX; Thu, 9 May 2013 08:56:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D857821F8FB6; Thu, 9 May 2013 08:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=457; q=dns/txt; s=iport; t=1368114978; x=1369324578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sH+Ra7Www1YXksbNBBmytqz/ao9hiDn7iPUCdnqxmr0=; b=Ai2/xqiL9gBTZ+LtYwONb9Qw50huDrBi2bKQKDjFJNBPiHsQjmmo3EnJ U3eOkjFihGWMCWgCtbQT2YcNhcFK+Xtfal3wqC329Swmbn2X2pDOJRGdA G0xwiw7LI0TPHhF7u/mgBS56KbyKqHiNwjmfKQT2pgigamCgg2f4K5pmv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAN/Fi1GtJXG+/2dsb2JhbABSgweDLL0SehZ0gh8BAQEDATo/EAIBCBUNFBAyJQIEDgUIh34FAb4JjnUCMQeCdGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208483206" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 09 May 2013 15:56:05 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r49Fu5d9010339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:56:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:56:05 -0500 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [MMUSIC] [rtcweb] Is bundle just a port override? Thread-Index: AQHOTM21I5ApWExVKkWVb2vtaIzXwA== Date: Thu, 9 May 2013 15:56:04 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com> <201303221928.r2MJSOvW960763@shell01.TheWorld.com> In-Reply-To: <201303221928.r2MJSOvW960763@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:56:25 -0000 On Mar 22, 2013, at 12:28 PM, Dale R. Worley wrote: >> From: "Mo Zanaty (mzanaty)" >>=20 >> BTW, has anyone actually observed failures? >=20 > My memory is that Cullen Jennings knows of a significant installed > base of SBCs that choke on SDP that contains duplicated port > references. >=20 > Dale Some of them are using the port as the think to uniquely key into the activ= e data structures.=20 From martin.thomson@gmail.com Thu May 9 08:58:43 2013 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 2C1A821F9428 for ; Thu, 9 May 2013 08:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-UUymCk88zn for ; Thu, 9 May 2013 08:58:42 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61121F8F4D for ; Thu, 9 May 2013 08:58:42 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id j13so3128750wgh.4 for ; Thu, 09 May 2013 08:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WYJaDc84kTWhuXXDSznl/JwWuG6OBvSA/heflb1tZcY=; b=x1wNg0awSuiGiwD74qsX3eo/OdyABKh+jjLMON6PgLw6xi8jZzmjR60prfUWGdn9iA KiGeZ5dfHXXZ+X5lzsTbRqeimP4PXKN8bcnWvrFDrF3FilfiRkmO9jFynDLdgWPyQxL0 wDUl+TslmTDiyjW3J5rvS9/+UBUZle+EwbUkb6pfxyj+dJe1PgLDZZd8LBtSVVBxMsqK ay6IALoN+1nwRmKyFMx3tnHp04UnL5QvZ35XF+EP0WgJYiKE/AtmvLAmuK7XQpDTCFyV 2w0m7+Jf/iRu13RaD0b7PNaXJ1BoRUDUSiftDMXajV7qe2b4joxIq2Zj4bLDdArj1haI ZuXw== MIME-Version: 1.0 X-Received: by 10.180.198.49 with SMTP id iz17mr29951200wic.19.1368115119121; Thu, 09 May 2013 08:58:39 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 9 May 2013 08:58:39 -0700 (PDT) In-Reply-To: <201305091512.r49FCQZh4436322@shell01.TheWorld.com> References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> <201305081937.r48JbQsp4388201@shell01.TheWorld.com> <201305091512.r49FCQZh4436322@shell01.TheWorld.com> Date: Thu, 9 May 2013 08:58:39 -0700 Message-ID: From: Martin Thomson To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 15:58:43 -0000 On 9 May 2013 08:12, Dale R. Worley wrote: >> From: Martin Thomson >> >> On 8 May 2013 12:37, Dale R. Worley wrote: >> > This is a promising proposal, but I think a lot more care needs to be >> > taken in defining how port numbers are to be used in this technique. >> > I can't tell what particular uses of port numbers are allowed and what >> > ones are not allowed. And it seems that the intended patterns could >> > result in problematic behaviors from intermediate devices. >> >> Thankfully, that's a problem that bundle is going to solve, not this >> document. The only statements that this draft needs to make is with >> respect to zero vs. non-zero port numbers, and only in the context of >> a=bundle-only. > > OK, I hadn't grasped the degree to which draft-roach-rtcweb-plan-a is > intended to be just an amendment to > draft-ietf-mmusic-sdp-bundle-negotiation. But it still does introduce > new patterns of use of port numbers in m= lines (e.g., an answer can > have a non-zero port number for an m= line which had a zero port > number in the offer), so we can't just wave our hands and say > "draft-bundle-negotiation will solve that" -- it's a substantial > change to what bundle-negotiation is proposing and solving the > problems that are apparent in bundle-negotiation won't solve all the > problems that result if draft-roach-rtcweb-plan-a is added to it. Right. I didn't intend to trivialize this, but I'd prefer to try to keep the issues as separate as possible. That probably means that we solve bundle first. From jonathan@vidyo.com Thu May 9 11:20:12 2013 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 77BCC21F8470 for ; Thu, 9 May 2013 11:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v1VuC8dDJcd for ; Thu, 9 May 2013 11:20:07 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id DCDEC21F9180 for ; Thu, 9 May 2013 11:20:05 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 3476D554FC3; Thu, 9 May 2013 14:20:05 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7139F554E55; Thu, 9 May 2013 14:20:04 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 9 May 2013 14:18:46 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Thu, 9 May 2013 14:20:05 -0400 Thread-Topic: [rtcweb] Plan A, respun Thread-Index: Ac5M4cPj9Z3SizxsTq2R5k6eY+/1KQ== Message-ID: References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> <518A4DE0.2040306@ericsson.com> <518AA629.2090907@alum.mit.edu> In-Reply-To: <518AA629.2090907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 18:20:12 -0000 On May 8, 2013, at 3:23 PM, Paul Kyzivat wrote: > - we could make the extension to support a=3Dssrc:nnn sendonly, etc. > That way you can signal the directionality of each individual stream. > Presumably in that case an a=3Dsendonly/recvonly/... for the same > m-line would apply to any ssrc's that didn't have their own. >=20 > Thanks, > Paul a=3Dssrc attributes are inherently unidirectional -- they talk about what y= ou can send. In draft-lennox-mmusic-source-selection, I defined an additio= nal a=3Dremote-ssrc attribute to talk about what you want to receive. That draft defines a=3Dssrc:send and a=3Dremote-ssrc:recv source attributes= , which allow on/off control for individual source hold. -- Jonathan Lennox jonathan@vidyo.com From andrew.hutton@siemens-enterprise.com Thu May 9 11:43:17 2013 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 26C7121F914C; Thu, 9 May 2013 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_110=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn+2NU3HWcZj; Thu, 9 May 2013 11:43:12 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 021A521F90D2; Thu, 9 May 2013 11:43:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9E09A1EB8534; Thu, 9 May 2013 20:43:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 9 May 2013 20:43:10 +0200 From: "Hutton, Andrew" To: "Cullen Jennings (fluffy)" , Justin Uberti Thread-Topic: [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOTMzUZ6qA2ycCEU+xahGCAxHFJpj9LqVA Date: Thu, 9 May 2013 18:43:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11591D10@MCHP04MSX.global-ad.net> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 18:43:17 -0000 ON: 09 May 2013 16:50 Cullen Jennings (fluffy) Wrote: >=20 > I think my largest questions was does an endpoint have to know when it > carets an offer if that is going to be sent to a legacy end point or > not. I'm particularly interested in multiscreen video conferences > systems. >=20 The same question also seems relevant to the respun plan A given that the t= emptation will be to use a=3Dbundleonly which greatly simplifies the offer = (i.e. less confusion over candidates etc.) but at the cost of interoperabil= ity with legacy multiscreen systems. Don't you agree? Andy=20 From petithug@acm.org Thu May 9 14:46:14 2013 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 569F521F8511 for ; Thu, 9 May 2013 14:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYpyA1cy8MEd for ; Thu, 9 May 2013 14:46:13 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 96FA421F84F8 for ; Thu, 9 May 2013 14:46:13 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:29:a838:d0f7:fd6:917f] (unknown [IPv6:2601:9:4bc0:29:a838:d0f7:fd6:917f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0DD2E20375 for ; Thu, 9 May 2013 23:46:11 +0200 (CEST) Message-ID: <518C1921.1010606@acm.org> Date: Thu, 09 May 2013 14:46:09 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 21:46:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I read the various security drafts and it looks like they all reference DTLS 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will the references being updated to use DTLS 1.2 as the base version, or will DTLS 1.0 stay as the base version, with possibility of negotiation to 1.2 and higher? Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRjBkcAAoJECnERZXWan7Ee8wQAIpsc2/SoM+Kho7ESzZGIBVK 83z5uLT66YW96TX46lXoO5peuG+hJBF29yHXNe6UoAkMGhyPzEEJjbAkT4uD9X9d 3UVGuVyUAYtyF9QdmwOHyadBcVq9Ljd60oMoi1InPNnAnOafIVXczWOz2NlthEf3 n/KupaXDYXbJ1M/RHBEOpmIngpN0uGUNForns7NAm3ksMoHxdI6h0Xka23/Co9F7 vI1gJBix3KMl11bO6eqdD23EIYuFKkMDSr+sEX2ubyZghIa7gqQNVewj0MxteSXe QudGIMt7vwwFFMfGd+nQNFYtudiNd3+X+9B1zg/Qlp4j6FfOxVVI5Zf5kWIZRKX4 YLs9t36eLjGV5kaiBq7lpt0eTA6bAzP0qSYK5R2GXdkwxTi75lubomeU9tEzkZJ5 AM6qmskFhp49gAsU5T5QsKf5sdfY4qDaPoDdXo7nXnG4bTj5N6UkZ2tgdSQ2VNMi Gnkd2dOs92eNq8koTbLNtQfLMJkx7dPo3K7vQZr3Eoy+1/jGhRJOISmsNi7PhQEH ZlTInLgdFZlQCOw62UQl+3E8Ks8rE13av+HJRiWPL26goL1spmuXY9s/0r3NeGSK gw6v19yJiydFpERRv4d13KU0PQjitwpBi8tkXWNbKKKQUyf2LhJJ7AvjwdoAJgUw PDXRoadwWd3jEvk8lail =b/cm -----END PGP SIGNATURE----- From worley@shell01.TheWorld.com Thu May 9 19:02:08 2013 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 627AD21F8F27 for ; Thu, 9 May 2013 19:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13TdHj2NMt2Z for ; Thu, 9 May 2013 19:02:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60321F8F17 for ; Thu, 9 May 2013 19:02:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4A21NWT015376; Thu, 9 May 2013 22:01:25 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4A21LtB4453016; Thu, 9 May 2013 22:01:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4A21KI34460779; Thu, 9 May 2013 22:01:20 -0400 (EDT) Date: Thu, 9 May 2013 22:01:20 -0400 (EDT) Message-Id: <201305100201.r4A21KI34460779@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Martin Thomson In-reply-to: (martin.thomson@gmail.com) References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> <201305081937.r48JbQsp4388201@shell01.TheWorld.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 02:02:08 -0000 > From: Martin Thomson > > On 8 May 2013 12:37, Dale R. Worley wrote: > > This is a promising proposal, but I think a lot more care needs to be > > taken in defining how port numbers are to be used in this technique. > > I can't tell what particular uses of port numbers are allowed and what > > ones are not allowed. And it seems that the intended patterns could > > result in problematic behaviors from intermediate devices. > > Thankfully, that's a problem that bundle is going to solve, not this > document. The only statements that this draft needs to make is with > respect to zero vs. non-zero port numbers, and only in the context of > a=bundle-only. OK, I hadn't grasped the degree to which draft-roach-rtcweb-plan-a is intended to be just an amendment to draft-ietf-mmusic-sdp-bundle-negotiation. But it still does introduce new patterns of use of port numbers in m= lines (e.g., an answer can have a non-zero port number for an m= line which had a zero port number in the offer), so we can't just wave our hands and say "draft-bundle-negotiation will solve that" -- it's a substantial change to what bundle-negotiation is proposing and solving the problems that are apparent in bundle-negotiation won't solve all the problems that result if draft-roach-rtcweb-plan-a is added to it. Dale From pkyzivat@alum.mit.edu Thu May 9 19:21:50 2013 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 1E66C21F8F25 for ; Thu, 9 May 2013 19:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdIidNjxytZn for ; Thu, 9 May 2013 19:21:44 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 2572121F8B5F for ; Thu, 9 May 2013 19:21:43 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id a1Y11l0050cZkys512MiC5; Fri, 10 May 2013 02:21:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id a2Mi1l00P3ZTu2S3W2Mid7; Fri, 10 May 2013 02:21:42 +0000 Message-ID: <518C59B5.7050200@alum.mit.edu> Date: Thu, 09 May 2013 22:21:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <518BBE2A.4060102@alum.mit.edu> <518BC345.6060807@nostrum.com> In-Reply-To: <518BC345.6060807@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368152502; bh=45zlzLjPyAYyUJmhwZHrp95Bg/HlO36+dyqV0fJ7vBo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BaP+wcQ6M08LBMDYutW9esrJo7N1TB3CLx5LNJMTbx9/uOWSOy4DH0vjUOjDzT0fQ N9uFRIuKHCasdkro0C7Fo7uKw/04DKxKAawvNbfB3xro4hxTvtXcHobhdK6oCz5ujs 2mClGe7iCMy1C4RIUPU310J8EW3HWXpsMBrVFerjdGWoP2gB5wky66EUTCbcInH9ZG gP4il/y3q+fn5/FIOyLntKa9BNZapznfzNPsWJCmfp+fN4Isrx74hHMY1nEQRUgJxS yNfnfrqovyvVjvDX1sldZx3oesQvjAVWGzz2Xg4gGnw03oogCsy/keW/aJpM8vLvWe h0/GAb/q6MbyQ== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 02:21:50 -0000 On 5/9/13 11:39 AM, Adam Roach wrote: > On 5/9/13 10:18, Paul Kyzivat wrote: >> On 5/8/13 5:18 PM, Adam Roach wrote: >>> >>> What I was trying to say above is that the only information you would >>> need to convey is literally one, two, or three >>> pairs. You don't say what you're planning to do with them, just that you >>> need them. >> >> How is that possibly enough? What codecs and codec parameters/optons? >> What bandwidth? What bundling options? The list goes on. > > I apologize. I must have done a really poor job in the prose in my > draft, since I clearly didn't communicate the fundamental mechanism that > I had in mind at all. > > Let me try with a ladder diagram to see whether that helps illuminate > what I'm proposing. > > > Offerer Answerer > | | > |<----------Solicitation-------------| > | (I need 1 new audio 1 new video) | > | | > | | > |-------------SDP Offer------------->| > | (Contains two more m-line sections | > | than the current session; one | > | audio, one video. Both recvonly.) | > | | > | | > |<------------SDP Answer-------------| > | (Makes use of the two new m-line | > | sections by populating them with | > | codec parameters, options, ssrc | > | bandwidth, bundling, etc, etc.) | > Yeah, I figured that from the last message. But the answer is constrained by the offer. So the answer may only have codecs that are listed in the offer. I guess the offerer can just include everything it is capable of supporting. But that would be especially unpleasant if the goal is to use payload type demux, because it will use up a bunch of PT numbers. Also, I guess you presume that the answerer wants to send, not receive. But if this were to be used for CLUE, it could well be that the answerer wants to receive, and will be using the clue channel to indicate what it wants to receive over that m-line. The bandwidth in the offer is what the offerer wants to receive, but it doesn't know the intent of the stream yet, so it doesn't really know this. So presumably it would need to put the maximum it can handle. With more than one m-line, it could be difficult to apportion bw if there is concern about the total. The bandwidth in the answer applies to media from offerer to answerer, which is irrelevant if media is assumed to only flow the other way. You also mention bundling. But as currently proposed bundling must be proposed in the offer and accepted or rejected in the answer. But the offerer won't know what to propose. If there is already a single bundle I suppose it could propose that the new m-lines be in that one, and the answerer could agree or not. But if there is more than one bundle that won't work. This just goes on and on. To make this work in general is going to require sending the moral equivalent of a delta to the last offer. Token passing to negotiate who is offerer would not have these problems. For something to offer up that doesn't require any standardization, that would make more sense. Thanks, Paul From stefan.lk.hakansson@ericsson.com Thu May 9 23:37:44 2013 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 2086E21F8E8F; Thu, 9 May 2013 23:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mh-tlfysoXo; Thu, 9 May 2013 23:37:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CB66121F8FA5; Thu, 9 May 2013 23:37:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-18-518c95a25c72 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EB.CE.01956.2A59C815; Fri, 10 May 2013 08:37:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 10 May 2013 08:37:22 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Adam Roach Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w== Date: Fri, 10 May 2013 06:37:21 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6iqT2BBmf2q1ns+buI3WLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXxs3721gLevkq TnT+YWxgXMrdxcjJISFgInFm22kmCFtM4sK99WxdjFwcQgKHGSXWbF3ECOEsYZQ41viVEaSK TSBQYuu+BWwgtoiAokTb4ZvMIDazQInE25NHWEFsYQFviW0bFjJD1PhIrL95iB3C1pNo6d0C VsMioCrxZP5TsM28Ar4Sx9evgFq2gVHiysujYA2MQCd9P7WGCWKBuMStJ/OhThWQWLLnPDOE LSrx8vE/VghbSeLHhkssEPV6EjemTmGDsLUlli18zQyxTFDi5MwnLBMYRWchGTsLScssJC2z kLQsYGRZxciem5iZk15uvokRGC0Ht/w22MG46b7YIUZpDhYlcd5krsZAIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYyBDdzWXXkST/wm7+IX51LTLqt0COX1O79FZnZbjcGKmY2Mki1qPWUv c3Pqk9QevHs+cVFD3qu/k+cu3Z108ciLU4XfPpy89/BThPt3Z8WjnBIa6j8dGtYH7VELZeCI WFo0U91zu/N2heOPMgNk7mYoyjje5NWxvhLjv3dj2n5bEX8VI0GXhUosxRmJhlrMRcWJAC0x PJtkAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 06:37:44 -0000 On 5/8/13 11:19 PM, Adam Roach wrote:=0A= > On 5/8/13 15:07, Paul Kyzivat wrote:=0A= =0A= >> I remain dubious that this glare situation is a problem that needs to=0A= >> be fixed.=0A= >=0A= > So am I, but Justin seems to be obsessed with it. That's why I'm=0A= > proposing a non-normative recipe that allows people who are=0A= > unnecessarily preoccupied with the issue to indulge their peccadillos.=0A= > The rest of us are free to ignore it.=0A= =0A= I think that glare coming from simultaneous add or remove of media may =0A= not be that common.=0A= =0A= But I can easily think of other situations that would lead to glare for =0A= Plan A.=0A= =0A= Just as an example, think about a conference scenario with a centralized = =0A= node. Now, one of the participants wants to mute her/his audio, and as a = =0A= result the audio m-line would go from sendrecv to recvonly. At roughly =0A= the same time the server wants to disable the high res video and enable =0A= the low res video (because this user will be moved, based e.g. on the =0A= recent audio activity, from being displayed in the main video window to =0A= be in a thumbnail on the screen of the other participants in the =0A= conference), so it wants to manipulate the direction attribute of other =0A= m-lines.=0A= =0A= So there would be two offers sent at roughly the same time, which means =0A= we would have glare.=0A= =0A= I think the result would be similar if the server would instead ask for =0A= another resolution using the imageattr.=0A= =0A= You could argue that all control should be left to one end-point, but it = =0A= is sort of clumsy.=0A= =0A= Plan B, with the individual control of sources, seems better fitted to =0A= handle this kind of situations.=0A= =0A= >=0A= > /a=0A= =0A= From tim@phonefromhere.com Fri May 10 02:09:01 2013 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 DF51921F88EA for ; Fri, 10 May 2013 02:08:59 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGhYvKPkysVO for ; Fri, 10 May 2013 02:08:52 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4B94E21F884F for ; Fri, 10 May 2013 02:08:51 -0700 (PDT) Received: (qmail 2897 invoked from network); 10 May 2013 09:08:49 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 10 May 2013 09:08:49 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id E46FA18A0663; Fri, 10 May 2013 10:08:49 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id CE47C18A062D; Fri, 10 May 2013 10:08:49 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <518C1921.1010606@acm.org> Date: Fri, 10 May 2013 10:08:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <518C1921.1010606@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:09:01 -0000 On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > I read the various security drafts and it looks like they all = reference DTLS > 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will the > references being updated to use DTLS 1.2 as the base version, or will = DTLS 1.0 > stay as the base version, with possibility of negotiation to 1.2 and = higher? I think we should move to 1.2 - There are specific cases where 1.0 = doesn't exactly do what we want.=20 e.g. I think for a server to ask for a client cert, technically in 1.0 = you are supposed to list the CA's you are interested in and you'll only receive certs from those CAs. In = 1.2 you can leave this empty and get a list of all certs (effectively a CA wildcard).=20 T. From oej@edvina.net Fri May 10 02:12:50 2013 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 7BBA321F8A74 for ; Fri, 10 May 2013 02:12:50 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stbADsL96deH for ; Fri, 10 May 2013 02:12:50 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCF621F8A48 for ; Fri, 10 May 2013 02:12:48 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 356A393C1AF; Fri, 10 May 2013 09:12:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 10 May 2013 11:12:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> References: <518C1921.1010606@acm.org> To: Tim Panton X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:12:50 -0000 10 maj 2013 kl. 11:08 skrev Tim Panton : >=20 >=20 > On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >>=20 >> I read the various security drafts and it looks like they all = reference DTLS >> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will the >> references being updated to use DTLS 1.2 as the base version, or will = DTLS 1.0 >> stay as the base version, with possibility of negotiation to 1.2 and = higher? > I think we should move to 1.2 - There are specific cases where 1.0 = doesn't exactly do what we > want.=20 >=20 > e.g. I think for a server to ask for a client cert, technically in 1.0 = you are supposed to list the CA's > you are interested in and you'll only receive certs from those CAs. In = 1.2 you can leave this > empty and get a list of all certs (effectively a CA wildcard).=20 What? Will any server get a list of all my private certs? That sems to = me like a big fat privacy issue. /O= From oej@edvina.net Fri May 10 02:24:37 2013 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 8126921F8E04 for ; Fri, 10 May 2013 02:24:37 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4xlPKLlOz3g for ; Fri, 10 May 2013 02:24:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 6426821F850F for ; Fri, 10 May 2013 02:24:34 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 59BD093C1AF; Fri, 10 May 2013 09:24:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> Date: Fri, 10 May 2013 11:24:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A89513C-534A-44CD-914F-D2D533BF6687@edvina.net> References: <518C1921.1010606@acm.org> <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> To: Tim Panton X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:24:37 -0000 10 maj 2013 kl. 11:12 skrev "Olle E. Johansson" : >=20 > 10 maj 2013 kl. 11:08 skrev Tim Panton : >=20 >>=20 >>=20 >> On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>>=20 >>> I read the various security drafts and it looks like they all = reference DTLS >>> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will the >>> references being updated to use DTLS 1.2 as the base version, or = will DTLS 1.0 >>> stay as the base version, with possibility of negotiation to 1.2 and = higher? >> I think we should move to 1.2 - There are specific cases where 1.0 = doesn't exactly do what we >> want.=20 >>=20 >> e.g. I think for a server to ask for a client cert, technically in = 1.0 you are supposed to list the CA's >> you are interested in and you'll only receive certs from those CAs. = In 1.2 you can leave this >> empty and get a list of all certs (effectively a CA wildcard).=20 >=20 > What? Will any server get a list of all my private certs? That sems to = me like a big fat privacy issue. =46rom RFC 5246 (TLS 1.2) that DTLS 1.2 refers to: "If the certificate_authorities list is empty, then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary." This doesn't mean that you will get all, but that the client can select = any certificate in the=20 cert store to present to the server. Previously the server had to = present a list of=20 acceptable CAs. It does open for self-signed certs, really. If you by = other means have established trust for a self-signed cert, you can use it as a client = cert in TLS 1.2. The server doesn't have to trust a CA, but can trust a specific cert. This goes hand in hand with DANE. /O= From tim@phonefromhere.com Fri May 10 02:47:23 2013 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 1CCAB21F898A for ; Fri, 10 May 2013 02:47:23 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj33JTMzQ3g7 for ; Fri, 10 May 2013 02:47:16 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7470F21F8503 for ; Fri, 10 May 2013 02:47:15 -0700 (PDT) Received: (qmail 55521 invoked from network); 10 May 2013 09:47:14 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 10 May 2013 09:47:14 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C49EB18A04D6; Fri, 10 May 2013 10:47:14 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A71CE18A03C5; Fri, 10 May 2013 10:47:14 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <3A89513C-534A-44CD-914F-D2D533BF6687@edvina.net> Date: Fri, 10 May 2013 10:47:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28F36C49-E542-4AD6-9124-8325744FC5A4@phonefromhere.com> References: <518C1921.1010606@acm.org> <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> <3A89513C-534A-44CD-914F-D2D533BF6687@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:47:23 -0000 On 10 May 2013, at 10:24, Olle E. Johansson wrote: >=20 > 10 maj 2013 kl. 11:12 skrev "Olle E. Johansson" : >=20 >>=20 >> 10 maj 2013 kl. 11:08 skrev Tim Panton : >>=20 >>>=20 >>>=20 >>> On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote: >>>=20 >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>>=20 >>>> I read the various security drafts and it looks like they all = reference DTLS >>>> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will = the >>>> references being updated to use DTLS 1.2 as the base version, or = will DTLS 1.0 >>>> stay as the base version, with possibility of negotiation to 1.2 = and higher? >>> I think we should move to 1.2 - There are specific cases where 1.0 = doesn't exactly do what we >>> want.=20 >>>=20 >>> e.g. I think for a server to ask for a client cert, technically in = 1.0 you are supposed to list the CA's >>> you are interested in and you'll only receive certs from those CAs. = In 1.2 you can leave this >>> empty and get a list of all certs (effectively a CA wildcard).=20 >>=20 >> What? Will any server get a list of all my private certs? That sems = to me like a big fat privacy issue. > =46rom RFC 5246 (TLS 1.2) that DTLS 1.2 refers to: >=20 > "If > the certificate_authorities list is empty, then the client MAY > send any certificate of the appropriate ClientCertificateType, > unless there is some external arrangement to the contrary." >=20 > This doesn't mean that you will get all, but that the client can = select any certificate in the=20 > cert store to present to the server. Previously the server had to = present a list of=20 > acceptable CAs. It does open for self-signed certs, really. If you by = other means have > established trust for a self-signed cert, you can use it as a client = cert in TLS 1.2. The > server doesn't have to trust a CA, but can trust a specific cert. >=20 > This goes hand in hand with DANE. >=20 > /O But that language isn't in TLS 1.0 - the list can't be empty. T. =20 From oej@edvina.net Fri May 10 03:02:20 2013 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 6221021F8CEC for ; Fri, 10 May 2013 03:02:20 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meu5WSD-0-Tk for ; Fri, 10 May 2013 03:02:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8541321F8BBC for ; Fri, 10 May 2013 03:02:19 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 6B77093C1AF; Fri, 10 May 2013 10:02:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <28F36C49-E542-4AD6-9124-8325744FC5A4@phonefromhere.com> Date: Fri, 10 May 2013 12:02:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1133B8BC-610C-4E2C-99A2-BCAFBB301349@edvina.net> References: <518C1921.1010606@acm.org> <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> <3A89513C-534A-44CD-914F-D2D533BF6687@edvina.net> <28F36C49-E542-4AD6-9124-8325744FC5A4@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:02:20 -0000 10 maj 2013 kl. 11:47 skrev Tim Panton : >=20 > On 10 May 2013, at 10:24, Olle E. Johansson wrote: >=20 >>=20 >> 10 maj 2013 kl. 11:12 skrev "Olle E. Johansson" : >>=20 >>>=20 >>> 10 maj 2013 kl. 11:08 skrev Tim Panton : >>>=20 >>>>=20 >>>>=20 >>>> On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote: >>>>=20 >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>>=20 >>>>> I read the various security drafts and it looks like they all = reference DTLS >>>>> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will = the >>>>> references being updated to use DTLS 1.2 as the base version, or = will DTLS 1.0 >>>>> stay as the base version, with possibility of negotiation to 1.2 = and higher? >>>> I think we should move to 1.2 - There are specific cases where 1.0 = doesn't exactly do what we >>>> want.=20 >>>>=20 >>>> e.g. I think for a server to ask for a client cert, technically in = 1.0 you are supposed to list the CA's >>>> you are interested in and you'll only receive certs from those CAs. = In 1.2 you can leave this >>>> empty and get a list of all certs (effectively a CA wildcard).=20 >>>=20 >>> What? Will any server get a list of all my private certs? That sems = to me like a big fat privacy issue. >> =46rom RFC 5246 (TLS 1.2) that DTLS 1.2 refers to: >>=20 >> "If >> the certificate_authorities list is empty, then the client MAY >> send any certificate of the appropriate ClientCertificateType, >> unless there is some external arrangement to the contrary." >>=20 >> This doesn't mean that you will get all, but that the client can = select any certificate in the=20 >> cert store to present to the server. Previously the server had to = present a list of=20 >> acceptable CAs. It does open for self-signed certs, really. If you by = other means have >> established trust for a self-signed cert, you can use it as a client = cert in TLS 1.2. The >> server doesn't have to trust a CA, but can trust a specific cert. >>=20 >> This goes hand in hand with DANE. >>=20 >> /O >=20 > But that language isn't in TLS 1.0 - the list can't be empty. Right. It's a good improvement but doesn't really work as you say - that = you will et a list of all my certs... /O= From harald@alvestrand.no Fri May 10 04:12:52 2013 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 B28E721F902D for ; Fri, 10 May 2013 04:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNbx4QNj0pty for ; Fri, 10 May 2013 04:12:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 45A2521F8F25 for ; Fri, 10 May 2013 04:12:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D80039E12F; Fri, 10 May 2013 13:12:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR2wNwcUOHdM; Fri, 10 May 2013 13:12:43 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:80b5:1e2b:aee2:472] (unknown [IPv6:2001:470:de0a:27:80b5:1e2b:aee2:472]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CA25339E0D2; Fri, 10 May 2013 13:12:42 +0200 (CEST) Message-ID: <518CD62A.8090806@alvestrand.no> Date: Fri, 10 May 2013 13:12:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eric Rescorla References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020302090108030709050302" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:12:52 -0000 This is a multi-part message in MIME format. --------------020302090108030709050302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/08/2013 06:25 PM, Eric Rescorla wrote: > > > On Wed, May 8, 2013 at 4:00 AM, Harald Alvestrand > > wrote: > > The paragraph that worries me most is this one: > > Offerers conformant to this specification MUST do one of the > following: > > o Use non-overlapping PT values for each m-line in any given bundle > group. > > o Provide distinct a=ssrc attributes for each m-line which uses > overlapping PT values with any other m-line. [Technically, this > is a general case of the previous point.] > > > To put a blunt point on it: Either send less than ~32 streams, or > give a=ssrc attributes. > > To me, that measn we're mandating one mechanism (PT values) for > small numbers of flows, and another mechanism (a=ssrc) for large > numbers of flows - such mechanism changes usually have > "interesting" properties in what happens at the changeover point. > > > That doesn't sound *quite* right to me. > > As I read the document, implementations are free to: > > (a) offer entirely disjoint PTs for all the m-lines in a given bundle, in > which case they must consume in total less than about 96 PTs > (b) offer a=ssrc in which case they must only guarantee that each > m-line doesn't internally repeat PTs (i.e., the current guarantee > that you don't say that 102 is both VP8 and H.264 on the same > m-line.) > > I would think that a smart implementation would try to use disjoint > PTs to the extent possible (thus allowing early demuxing) but > also offer a=ssrc, so that if they ran out of PTs, the transition was > smooth. Obviously there is potential for bugs here, but this seems > like code that would get fairly well tested in the field, no? Well.... you WOULD think the Java spec that says that Integer(127) is a globally unique object while Integer(128) isn't (so that, when testing for object equality instead of value equality, Integer(127) == Integer(127), while Integer(128) != Integer(128)), wouldn't you? (note - I think the limit may be JVM-implementation defined, but don't quote me on that). This still bites implementors fairly far out in the deployment cycle, I hear. Obscure limits that you hit only after significant installed base is deployed is not really things that make me happy. And of course Unicode's "we'll never need more than 65.535 characters" is another fun one. > > It would seem to me to be architecturally cleaner to insist that > a=ssrc be used always. > But in that case, I have a very large difficulty seeing the > important advantage this has over Plan B. > > > Isn't the argument that Plan A preserves all the existing SDP negotiation > mechanisms but allows them to be used with a high level of muxing, > rather than reinventing some subset of them at the SDP level? That's the argument, but a) I'm not convinced that the argument holds, and b) I'm worried about the cost in terms of model complexity and richness of edge cases like this one. --------------020302090108030709050302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/08/2013 06:25 PM, Eric Rescorla wrote:


On Wed, May 8, 2013 at 4:00 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
The paragraph that worries me most is this one:

   Offerers conformant to this specification MUST do one of the
   following:

   o  Use non-overlapping PT values for each m-line in any given bundle
      group.

   o  Provide distinct a=ssrc attributes for each m-line which uses
      overlapping PT values with any other m-line.  [Technically, this
      is a general case of the previous point.]

To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes.

To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover point.

That doesn't sound *quite* right to me.

As I read the document, implementations are free to:

(a) offer entirely disjoint PTs for all the m-lines in a given bundle, in
      which case they must consume in total less than about 96 PTs
(b) offer a=ssrc in which case they must only guarantee that each
      m-line doesn't internally repeat PTs (i.e., the current guarantee
      that you don't say that 102 is both VP8 and H.264 on the same
      m-line.)

I would think that a smart implementation would try to use disjoint
PTs to the extent possible (thus allowing early demuxing) but
also offer a=ssrc, so that if they ran out of PTs, the transition was
smooth. Obviously there is potential for bugs here, but this seems
like code that would get fairly well tested in the field, no?

Well.... you WOULD think the Java spec that says that Integer(127) is a globally unique object while Integer(128) isn't (so that, when testing for object equality instead of value equality, Integer(127) == Integer(127), while Integer(128) != Integer(128)), wouldn't you? (note - I think the limit may be JVM-implementation defined, but don't quote me on that).

This still bites implementors fairly far out in the deployment cycle, I hear. Obscure limits that you hit only after significant installed base is deployed is not really things that make me happy.

And of course Unicode's "we'll never need more than 65.535 characters" is another fun one.


 
It would seem to me to be architecturally cleaner to insist that a=ssrc be used always.
But in that case, I have a very large difficulty seeing the important advantage this has over Plan B.

Isn't the argument that Plan A preserves all the existing SDP negotiation
mechanisms but allows them to be used with a high level of muxing,
rather than reinventing some subset of them at the SDP level?

That's the argument, but a) I'm not convinced that the argument holds, and b) I'm worried about the cost in terms of model complexity and richness of edge cases like this one.

--------------020302090108030709050302-- From ekr@rtfm.com Fri May 10 09:28:43 2013 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 7F74B21F89FD for ; Fri, 10 May 2013 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Imj1o0X6GIRd for ; Fri, 10 May 2013 09:28:38 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9782121F89E8 for ; Fri, 10 May 2013 09:28:38 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id f6so2535675qej.5 for ; Fri, 10 May 2013 09:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=GbFYz2hY0y6VN3a0+qtpMyEIYckb0i435PrBOChKU6c=; b=LjAMbfytyCxEUxYKb048MO1mlX01Nd28Ejq1QIUch4Tqk6VK9gs5l/G2nraoXJC5ap zE3ReIfDkWZ2TUKmdwVQ47h7tO+yUBRSpkO/G2cjrgBysukIM5QzGRWaSKM1GF/P6wji osmCwP492p3x6996c+4y+akXFACtkPeCyaZEyaCEDdANz5C3QlROZqQ8KX2GdXVoBdiQ Z3QBkNQ4cspGFShaXeYwHJtS3+IQEalL4gO96SIZ/9+fs6KECyB4sPAF2QxyHDbDtJQJ I97fv2prCEwEsUUCosUAWZEQJUZMi1df33cPlK9zAOikvVKOSa6M9tygUhM2SNlgXrP4 aTZg== X-Received: by 10.224.30.76 with SMTP id t12mr12337265qac.24.1368203318043; Fri, 10 May 2013 09:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.96.169 with HTTP; Fri, 10 May 2013 09:27:57 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <1133B8BC-610C-4E2C-99A2-BCAFBB301349@edvina.net> References: <518C1921.1010606@acm.org> <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> <3A89513C-534A-44CD-914F-D2D533BF6687@edvina.net> <28F36C49-E542-4AD6-9124-8325744FC5A4@phonefromhere.com> <1133B8BC-610C-4E2C-99A2-BCAFBB301349@edvina.net> From: Eric Rescorla Date: Fri, 10 May 2013 09:27:57 -0700 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=047d7bea37c2c0b83f04dc5fa815 X-Gm-Message-State: ALoCoQmJMm5KTFLvdUZbhk3n0XHNKE1pBT/VK7UP90FzcoDebLt+PBiKuW1/vtKUgbTkO0YR/bGP Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version for RTCweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:28:43 -0000 --047d7bea37c2c0b83f04dc5fa815 Content-Type: text/plain; charset=ISO-8859-1 In an attempt to clarify: 1. DTLS 1.0 is actually based on TLS 1.1 (it's confusing, I know.) DTLS 1.2 is based on TLS 1.2 so it won't be confusing in the future. 2. The client only ever sends one certificate chain. This is just about how the chain is selected. 3. The language Olle quotes appears in TLS 1.1 (RFC 4346) as well was TLS 1.2, so it's fine to send an empty certificate list with TLS 1.1/DTLS 1.0. In truth, people do this with TLS 1.0 though it's not officially sanctioned. To go to the bigger question: DTLS 1.2 deployment is still a work in progress, and it's possible to negotiate versions. We should mandate DTLS 1.0 (remember, there is no 1.1). -Ekr On Fri, May 10, 2013 at 3:02 AM, Olle E. Johansson wrote: > > 10 maj 2013 kl. 11:47 skrev Tim Panton : > > > > > On 10 May 2013, at 10:24, Olle E. Johansson wrote: > > > >> > >> 10 maj 2013 kl. 11:12 skrev "Olle E. Johansson" : > >> > >>> > >>> 10 maj 2013 kl. 11:08 skrev Tim Panton : > >>> > >>>> > >>>> > >>>> On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote: > >>>> > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA256 > >>>>> > >>>>> I read the various security drafts and it looks like they all > reference DTLS > >>>>> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247. So will the > >>>>> references being updated to use DTLS 1.2 as the base version, or > will DTLS 1.0 > >>>>> stay as the base version, with possibility of negotiation to 1.2 and > higher? > >>>> I think we should move to 1.2 - There are specific cases where 1.0 > doesn't exactly do what we > >>>> want. > >>>> > >>>> e.g. I think for a server to ask for a client cert, technically in > 1.0 you are supposed to list the CA's > >>>> you are interested in and you'll only receive certs from those CAs. > In 1.2 you can leave this > >>>> empty and get a list of all certs (effectively a CA wildcard). > >>> > >>> What? Will any server get a list of all my private certs? That sems to > me like a big fat privacy issue. > >> From RFC 5246 (TLS 1.2) that DTLS 1.2 refers to: > >> > >> "If > >> the certificate_authorities list is empty, then the client MAY > >> send any certificate of the appropriate ClientCertificateType, > >> unless there is some external arrangement to the contrary." > >> > >> This doesn't mean that you will get all, but that the client can select > any certificate in the > >> cert store to present to the server. Previously the server had to > present a list of > >> acceptable CAs. It does open for self-signed certs, really. If you by > other means have > >> established trust for a self-signed cert, you can use it as a client > cert in TLS 1.2. The > >> server doesn't have to trust a CA, but can trust a specific cert. > >> > >> This goes hand in hand with DANE. > >> > >> /O > > > > But that language isn't in TLS 1.0 - the list can't be empty. > > Right. It's a good improvement but doesn't really work as you say - that > you will et a list > of all my certs... > > /O > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bea37c2c0b83f04dc5fa815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In an attempt to clarify:

1. DTLS 1.0 is actually based on TLS= 1.1 (it's confusing, I know.)
DTLS 1.2 is based on TLS 1.2 s= o it won't be confusing in the
future.

2. The client only ever sends one certificate chain. This is just
about how the chain is selected.

3. The language O= lle quotes appears in TLS 1.1 (RFC 4346)
as well was TLS 1.2, so = it's fine to send an empty certificate
list with TLS 1.1/DTLS 1.0. In truth, people do this with TLS 1.0
though it's not officially sanctioned.

<= br>
To go to the bigger question:
DTLS 1.2 deployment i= s still a work in progress, and it's possible
to negotiate versions. We should mandate DTLS 1.0 (remember,
there is no 1.1).

-Ekr

<= br>



On Fri, May= 10, 2013 at 3:02 AM, Olle E. Johansson <oej@edvina.net> wrote:=

10 maj 2013 kl. 11:47 skrev Tim Panton <tim@phonefromhere.com>:

>
> On 10 May 2013, at 10:24, Olle E. Johansson wrote:
>
>>
>> 10 maj 2013 kl. 11:12 skrev "Olle E. Johansson" <oej@edvina.net>:
>>
>>>
>>> 10 maj 2013 kl. 11:08 skrev Tim Panton <tim@phonefromhere.com>:
>>>
>>>>
>>>>
>>>> On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote:
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> I read the various security drafts and it looks like t= hey all reference DTLS
>>>>> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247= . =A0So will the
>>>>> references being updated to use DTLS 1.2 as the base v= ersion, or will DTLS 1.0
>>>>> stay as the base version, with possibility of negotiat= ion to 1.2 and higher?
>>>> I think we should move to 1.2 - There are specific cases w= here 1.0 doesn't exactly do what we
>>>> want.
>>>>
>>>> e.g. I think for a server to ask for a client cert, techni= cally in 1.0 you are supposed to list the CA's
>>>> you are interested in and you'll only receive certs fr= om those CAs. In 1.2 you can leave this
>>>> empty and get a list of all certs (effectively a CA wildca= rd).
>>>
>>> What? Will any server get a list of all my private certs? That= sems to me like a big fat privacy issue.
>> From RFC 5246 (TLS 1.2) that DTLS 1.2 refers to:
>>
>> "If
>> =A0 =A0 the certificate_authorities list is empty, then the client= MAY
>> =A0 =A0 send any certificate of the appropriate ClientCertificateT= ype,
>> =A0 =A0 unless there is some external arrangement to the contrary.= "
>>
>> This doesn't mean that you will get all, but that the client c= an select any certificate in the
>> cert store to present to the server. Previously the server had to = present a list of
>> acceptable CAs. It does open for self-signed certs, really. If you= by other means have
>> established trust for a self-signed cert, you can use it as a clie= nt cert in TLS 1.2. The
>> server doesn't have to trust a CA, but can trust a specific ce= rt.
>>
>> This goes hand in hand with DANE.
>>
>> /O
>
> But that language isn't in TLS 1.0 - the list can't be empty.<= br>
Right. It's a good improvement but doesn't really work = as you say - that you will et a list
of all my certs...

/O
_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bea37c2c0b83f04dc5fa815-- From fluffy@iii.ca Fri May 10 11:44:52 2013 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 D66E021F9121 for ; Fri, 10 May 2013 11:44:52 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdyWCRlHihtw for ; Fri, 10 May 2013 11:44:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 692D221F9021 for ; Fri, 10 May 2013 11:44:42 -0700 (PDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D2A6B22E257 for ; Fri, 10 May 2013 14:44:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51894846.3090102@nostrum.com> Date: Fri, 10 May 2013 08:51:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <995DAF0B-96D8-49EB-B1DD-B45546868D65@iii.ca> References: <51894846.3090102@nostrum.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:44:53 -0000 Some folks asked me if I plan to resubmit my plan-a document and I am = not going to submit it. I think Adam's version is simpler and managed to = split the difference between what I was proposing and plan b so I think = it is a better choice for the WG than the initial draft I had worked on.=20= On May 7, 2013, at 11:30 AM, Adam Roach wrote: > In order to facilitate discussion between the two SDP format = alternatives we're considering, I've put together a document that more = clearly spells out the Plan A approach as we originally envisioned it. = Note that this is a slightly different approach than Cullen outlined in = Orlando. I fear the Orlando approach may have suffered from its attempts = to incorporate some elements of Plan B in an attempt to appease = proponents of that approach; and, in doing so, lost some of its clean = architecture. >=20 > The cleaned up, new-and-improved description of the Plan A approach is = available here: >=20 > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >=20 > Note that we've omitted discussion of glare reduction from that = document, as I believe that mid-session glare can be completely avoided = by applications implementing a set of non-normative behaviors. These = behaviors are described in the a separate companion document: >=20 > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >=20 > Thanks. >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri May 10 11:44:53 2013 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 1A2AD21F9021 for ; Fri, 10 May 2013 11:44:53 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9iZ8QmZZOgC for ; Fri, 10 May 2013 11:44:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6935921F9023 for ; Fri, 10 May 2013 11:44:42 -0700 (PDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A0C6B22E25B; Fri, 10 May 2013 14:44:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <201305081937.r48Jb4Yr4376144@shell01.TheWorld.com> Date: Fri, 10 May 2013 10:34:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> <51898653.1010907@nostrum.com> <201305081937.r48Jb4Yr4376144@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:44:53 -0000 On May 8, 2013, at 12:37 PM, Dale R. Worley wrote: >> From: Adam Roach >>=20 >> I want to re-iterate the most important part of my answer to Paul, = since=20 >> it allows anyone who can apply apply critical thinking skills to = arrive=20 >> at the correct conclusion about what we are proposing. Here is the = crux=20 >> of my answer again, from which the remainder of my answer was = derived: >>=20 >> Looking at basic principles, the intention here is that the >> semantics would be identical to non-webrtc, non-bundle clients >> receiving multiple SSRCs on the same port. >=20 > Echoing Jonathan, I don't think that there is a consistent rule for > those semantics now. Some devices consider multiple SSRCs to be data > from multiple captures, and others consider multiple SSRCs to be > alternative representations of the same capture (either simultaneous > in time or alternating in time). >=20 > Or perhaps there is a consistent rule, but there are inconsistent > implementations. In which case we should document the correct > behavior -- and worry about interoperability. >=20 > Or perhaps we should define an SDP extension (or tighten the semantics > of an existing syntax) to remove the ambiguities. I realize that opinions differ on this topic, but for the O/A SDP cases = (not the declarative SDP in RTSP), the meaning seemed to be clear and = long ago it was put in some RFC, lots of products where build. Later it = was suggested it could mean something different. =20 But let's get to the high level point, regardless of what people think = the existing RFCs say, it is a confusing topic and it needs to have = clear signaling with clear semantics or there will be interop problems. = I think that devices that want to multiple SRC on same m-line to = represent different captures need to define new SDP signaling that = clearly indicates this is the case.=20 From fluffy@iii.ca Fri May 10 11:44:57 2013 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 EA18721F901B for ; Fri, 10 May 2013 11:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjZxNeSyGUA5 for ; Fri, 10 May 2013 11:44:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DE30821F902D for ; Fri, 10 May 2013 11:44:42 -0700 (PDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1350D22E25C; Fri, 10 May 2013 14:44:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <518A304A.1030609@alvestrand.no> Date: Fri, 10 May 2013 10:37:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:44:58 -0000 On May 8, 2013, at 4:00 AM, Harald Alvestrand = wrote: > The paragraph that worries me most is this one: >=20 >=20 > Offerers conformant to this specification MUST do one of the > following: >=20 > o Use non-overlapping PT values for each m-line in any given bundle > group. >=20 > o Provide distinct a=3Dssrc attributes for each m-line which uses > overlapping PT values with any other m-line. [Technically, this > is a general case of the previous point.] >=20 >=20 >=20 > To put a blunt point on it: Either send less than ~32 streams, or give = a=3Dssrc attributes. As a slide note, as I imagine you are aware, it is not 32 but in the = roughly 100 range=20 >=20 > To me, that measn we're mandating one mechanism (PT values) for small = numbers of flows, and another mechanism (a=3Dssrc) for large numbers of = flows - such mechanism changes usually have "interesting" properties in = what happens at the changeover point. The problem is that SSRC are not a stable demux point due to collision = and early media issues so, for applications that care about theses, they = can use PT. For things that need the properties of the larger code = space, they can use SSRC or other future extension to RTP. The code is = very simple to deal with demux on both PT and SSRC . If someone wants to = later add a RTP header extensions with another tag that can be used for = demux, that is fine too. The idea is that the device will use what it = currently knows (both PT and SSRC) to do the best demux it can do given = the information at hand. This gives us the best of SSRC demux and PT = demux and actually allows a combination of the two that scales to much = larger numbers than either alone. And it's trivial to implement. >=20 > It would seem to me to be architecturally cleaner to insist that = a=3Dssrc be used always. There rare two major disadvantages to doing this=20 1) The side receiving the media can't tell the other side what SSRC to = use in the offer. That means you can not demux until after the answer is = received in the best case. This adds latency and cause media clipping. = It does not work with early media in some cases.=20 It may not matter to the use case you have in mind but it does matter to = use cases other have in mind. Note there is no problem for the use case = you are interested in just using the SSRC and not caring what happens = with the PT. For applications that want to do that, the mechanism in = this draft works just fine. =20 2) the other problem is that SSRC collide and it takes a long time to = get the the updated information about how the collision was resolved and = in that time the data may actually go the wrong place. Just sort of = curios if chrome has implemented dealing with collisions yet? I will note that using PT + SSRC in the way Adam's draft has them = actually allows for a theoretical maximum of more like 3 million RTP = flows per port.=20 > But in that case, I have a very large difficulty seeing the important = advantage this has over Plan B. >=20 >=20 >=20 > On 05/07/2013 08:30 PM, Adam Roach wrote: >> In order to facilitate discussion between the two SDP format = alternatives we're considering, I've put together a document that more = clearly spells out the Plan A approach as we originally envisioned it. = Note that this is a slightly different approach than Cullen outlined in = Orlando. I fear the Orlando approach may have suffered from its attempts = to incorporate some elements of Plan B in an attempt to appease = proponents of that approach; and, in doing so, lost some of its clean = architecture.=20 >>=20 >> The cleaned up, new-and-improved description of the Plan A approach = is available here:=20 >>=20 >> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt=20 >>=20 >> Note that we've omitted discussion of glare reduction from that = document, as I believe that mid-session glare can be completely avoided = by applications implementing a set of non-normative behaviors. These = behaviors are described in the a separate companion document:=20 >>=20 >> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt=20 >>=20 >> Thanks.=20 >>=20 >> /a=20 >> _______________________________________________=20 >> rtcweb mailing list=20 >> rtcweb@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/rtcweb=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri May 10 11:45:04 2013 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 DF94921F9048 for ; Fri, 10 May 2013 11:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQkGdXW2rF6g for ; Fri, 10 May 2013 11:44:57 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 168A821F90C3 for ; Fri, 10 May 2013 11:44:44 -0700 (PDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 08CFC22E253; Fri, 10 May 2013 14:44:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Fri, 10 May 2013 10:38:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>, <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu> To: Bernard Aboba X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:05 -0000 On May 7, 2013, at 2:44 PM, Bernard Aboba = wrote: > The "existing SDP semantics" have allowed multiplexing of RTP streams = from multiple SSRCs on the=20 > same RTP session without explicit declaration since multicast days - Right, but what it has meant to do that in Offer / Answer cases has been = that these are alternative encoding of same capture and not different = captures. I think we need to have the signaling be explicit about the = meaning if it is supposed to mean something different than that. Note, = I'm not against an extension that indicates specific semantics that are = different that the current O/A ones, but just it would need to be = defined and signaled. The plan A seem to avoid needing to argue about = this and at the same time make it easy to define theses semantics and = signal them if CLUE or someone other user of RTP needs that.= From fluffy@iii.ca Fri May 10 11:45:11 2013 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 1DDA321F91CE for ; Fri, 10 May 2013 11:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sA6a9hYi11R for ; Fri, 10 May 2013 11:45:04 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF1021F90DF for ; Fri, 10 May 2013 11:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 5BA892FD7D6 for ; Fri, 10 May 2013 14:44:51 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76C9622E259; Fri, 10 May 2013 14:44:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <518C59B5.7050200@alum.mit.edu> Date: Fri, 10 May 2013 10:54:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <518BBE2A.4060102@alum.mit.edu> <518BC345.6060807@nostrum.com> <518C59B5.7050200@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:11 -0000 On May 9, 2013, at 8:21 PM, Paul Kyzivat wrote: > On 5/9/13 11:39 AM, Adam Roach wrote: >> On 5/9/13 10:18, Paul Kyzivat wrote: >>> On 5/8/13 5:18 PM, Adam Roach wrote: >>>>=20 >>>> What I was trying to say above is that the only information you = would >>>> need to convey is literally one, two, or three = >>>> pairs. You don't say what you're planning to do with them, just = that you >>>> need them. >>>=20 >>> How is that possibly enough? What codecs and codec = parameters/optons? >>> What bandwidth? What bundling options? The list goes on. >>=20 >> I apologize. I must have done a really poor job in the prose in my >> draft, since I clearly didn't communicate the fundamental mechanism = that >> I had in mind at all. >>=20 >> Let me try with a ladder diagram to see whether that helps illuminate >> what I'm proposing. >>=20 >>=20 >> Offerer Answerer >> | | >> |<----------Solicitation-------------| >> | (I need 1 new audio 1 new video) | >> | | >> | | >> |-------------SDP Offer------------->| >> | (Contains two more m-line sections | >> | than the current session; one | >> | audio, one video. Both recvonly.) | >> | | >> | | >> |<------------SDP Answer-------------| >> | (Makes use of the two new m-line | >> | sections by populating them with | >> | codec parameters, options, ssrc | >> | bandwidth, bundling, etc, etc.) | >>=20 >=20 > Yeah, I figured that from the last message. But the answer is = constrained by the offer. So the answer may only have codecs that are = listed in the offer. >=20 > I guess the offerer can just include everything it is capable of = supporting. But that would be especially unpleasant it seem to me that we all the same problems in the initial offer. The = whole idea of an Offer/Answer is the offer has more or less has = everything you support or are willing to do so I don't really see that = being a big problem here.=20 From fluffy@iii.ca Fri May 10 11:45:11 2013 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 1370821F91CA for ; Fri, 10 May 2013 11:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoU6xlL1tzTk for ; Fri, 10 May 2013 11:45:04 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id CABA921F90CD for ; Fri, 10 May 2013 11:44:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 2B0452FD7B3 for ; Fri, 10 May 2013 14:44:45 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3846222E255; Fri, 10 May 2013 14:44:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Fri, 10 May 2013 10:39:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> To: Colin Perkins X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:11 -0000 On May 8, 2013, at 4:33 AM, Colin Perkins wrote: > I agree: the PT was never intended to be used as a demultiplexing = point for different flows in RT I'm not sure I really agree on this point. Lots of implications use the = PT along with the port received on to decide which codec to pass to the = RTP packet on to. I think, in practice, the PT has been a very key demux = pony for a long time in RTP.=20 From fluffy@iii.ca Fri May 10 11:45:15 2013 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 76D6621F91F1 for ; Fri, 10 May 2013 11:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqAIz5TuwrTR for ; Fri, 10 May 2013 11:45:11 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1121F90EA for ; Fri, 10 May 2013 11:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 2D1A42FD7D5 for ; Fri, 10 May 2013 14:44:46 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3FFE822E257; Fri, 10 May 2013 14:44:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <201305091512.r49FCQZh4436322@shell01.TheWorld.com> Date: Fri, 10 May 2013 10:48:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4BB6A3-A208-445B-B10B-08EBF090D069@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B1C36CCC8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36CDD2@ESESSMB209.ericsson.se> <51896824.2000705@nostrum.com> <201305081937.r48JbQsp4388201@shell01.TheWorld.com> <201305091512.r49FCQZh4436322@shell01.TheWorld.com> To: Dale WORLEY X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun - bundle-only attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:15 -0000 On May 9, 2013, at 9:12 AM, Dale R. Worley wrote: >> From: Martin Thomson >>=20 >> On 8 May 2013 12:37, Dale R. Worley wrote: >>> This is a promising proposal, but I think a lot more care needs to = be >>> taken in defining how port numbers are to be used in this technique. >>> I can't tell what particular uses of port numbers are allowed and = what >>> ones are not allowed. And it seems that the intended patterns could >>> result in problematic behaviors from intermediate devices. >>=20 >> Thankfully, that's a problem that bundle is going to solve, not this >> document. The only statements that this draft needs to make is with >> respect to zero vs. non-zero port numbers, and only in the context of >> a=3Dbundle-only. >=20 > OK, I hadn't grasped the degree to which draft-roach-rtcweb-plan-a is > intended to be just an amendment to > draft-ietf-mmusic-sdp-bundle-negotiation. But it still does introduce > new patterns of use of port numbers in m=3D lines (e.g., an answer can > have a non-zero port number for an m=3D line which had a zero port > number in the offer), so we can't just wave our hands and say > "draft-bundle-negotiation will solve that" -- it's a substantial > change to what bundle-negotiation is proposing and solving the > problems that are apparent in bundle-negotiation won't solve all the > problems that result if draft-roach-rtcweb-plan-a is added to it. I agree - good point to think about. I think a key part of this is that = this only happens in the case of "new" endpoints that explicitly signal = support for the new RFC that bundle would turn into. Do you think it = would be better if all the text about 0 ports in an offer, and how in = the bundle case they can change in the answer should be put in the = bundle draft?=20 From fluffy@iii.ca Fri May 10 11:45:15 2013 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 7B4B521F90DF; Fri, 10 May 2013 11:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaOe-Y2C4cDG; Fri, 10 May 2013 11:45:11 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 829A921F9104; Fri, 10 May 2013 11:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 5C03C2FD7D9; Fri, 10 May 2013 14:44:51 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 89F1F22E25C; Fri, 10 May 2013 14:44:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Fri, 10 May 2013 10:55:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com> <201303221928.r2MJSOvW960763@shell01.TheWorld.com> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:16 -0000 On May 9, 2013, at 9:56 AM, Cullen Jennings (fluffy) = wrote: >=20 > On Mar 22, 2013, at 12:28 PM, Dale R. Worley = wrote: >=20 >>> From: "Mo Zanaty (mzanaty)" >>>=20 >>> BTW, has anyone actually observed failures? >>=20 >> My memory is that Cullen Jennings knows of a significant installed >> base of SBCs that choke on SDP that contains duplicated port >> references. >>=20 >> Dale >=20 > Some of them are using the port as the think to uniquely key into the = active data structures.=20 Sorry, apple auto correct got me. I mean "thing" not "think" From fluffy@iii.ca Fri May 10 11:45:22 2013 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 000D521F92B2 for ; Fri, 10 May 2013 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca5KJxqFRHLu for ; Fri, 10 May 2013 11:45:15 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id BF3D821F9113 for ; Fri, 10 May 2013 11:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 678982FD7DD for ; Fri, 10 May 2013 14:44:51 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B361C22E2C9; Fri, 10 May 2013 14:44:49 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Fri, 10 May 2013 11:10:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> To: Ted Hardie X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:22 -0000 On May 8, 2013, at 4:01 PM, Ted Hardie wrote: > On Wed, May 8, 2013 at 12:43 PM, Paul Kyzivat < > *I* think it is important that clue and rtcweb to be able to coexist = in a single endpoint, and for a clue+rtcweb client to interoperate with = either another clue+rtcweb client or a pure clue client. Using different = indicators in the two environments doesn't help with that. >=20 >=20 > So, can you unpack "coexist"? A single endpoint could certainly have = either a clue client or an rtcweb client active at a single moment in = time--do you want to say that you want them both to be active and share = the same cameras, microphones, etc? =20 >=20 > regards, >=20 > Ted I want to be able to build a multi-screen telepresence systems that when = it constructs an Offer, that offer could be going to a webrtc compliant = browser, or it could be going to another CLUE complains endpoint. When = it constructs the offer, it does not know where it going and based on = the answer, the right thing will happen.=20= From fluffy@iii.ca Fri May 10 11:45:22 2013 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 09D0B21F92B7 for ; Fri, 10 May 2013 11:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjVTYIAmZlES for ; Fri, 10 May 2013 11:45:15 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD121F910D for ; Fri, 10 May 2013 11:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 6545F2FD7DB for ; Fri, 10 May 2013 14:44:51 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D681122E2C3; Fri, 10 May 2013 14:44:48 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <518A1268.8090107@ericsson.com> Date: Fri, 10 May 2013 11:06:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:22 -0000 On May 8, 2013, at 2:52 AM, Stefan H=E5kansson LK = wrote: > * The (3-way) handshake is well aligned with the API (where the = sending app initiates the sending of media) Interesting - I saw it sort of the opposite so perhaps you can you say = some more. I saw this as a complete change to everything we had = discussed up to this point in how the API would work and how it would = interact with Offer/Answer. I figured dealing with this change would set = back the W3C API work over 8 months so this is good news if you see a = way that it is the well alighted. Can you explain how it lines up with = the current drafts, call flows, existing example applications, and APIs = that are all based on a 2 way hand shake? From fluffy@iii.ca Fri May 10 11:45:28 2013 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 4CDDC21F9343 for ; Fri, 10 May 2013 11:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lMrL11IdtDc for ; Fri, 10 May 2013 11:45:22 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 1328D21F9021 for ; Fri, 10 May 2013 11:44:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id BE03C2FD7DE for ; Fri, 10 May 2013 14:44:53 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF2D822E2CA; Fri, 10 May 2013 14:44:50 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> Date: Fri, 10 May 2013 12:44:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:45:28 -0000 On May 6, 2013, at 8:56 AM, Dan Wing wrote: >=20 > On May 6, 2013, at 7:30 AM, Henry Lum = wrote: >=20 >> Chiming in late. >>=20 >> Speaking from a contact center perspective, a lot of calls are = required to be recorded. In order to allow active recording (such as = SIPREC), the contact center has to provide a media endpoint for bridging = media so that a copy of the media can be created. The users will have to = trust the contact center to handle the media anyways, and the media must = be decrypted and re-encrypted by some media element within the contact = center to perform recording. To me DTLS-SRTP-EKT does not provide any = additional benefit over SDES for this type of use case. >=20 > Only DTLS-SRTP proves the call is actually to the call center (bank, = stock broker, reservation company).=20 Uh, can you say a bit more about how DTLS-SRTP provides that? The topic = of how this is done and if it reduces to the same security as SDES has = been controversial and would be good to get people understanding the = issues her From csp@csperkins.org Fri May 10 11:59:40 2013 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 656ED21F8FF1 for ; Fri, 10 May 2013 11:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M96pEnXNwEJE for ; Fri, 10 May 2013 11:59:35 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B621F9012 for ; Fri, 10 May 2013 11:59:34 -0700 (PDT) Received: from [81.187.2.149] (port=37042 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UasXP-00057i-4u; Fri, 10 May 2013 19:59:28 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca> Date: Fri, 10 May 2013 19:59:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:59:40 -0000 On 10 May 2013, at 17:39, Cullen Jennings wrote: > On May 8, 2013, at 4:33 AM, Colin Perkins wrote: >> I agree: the PT was never intended to be used as a demultiplexing = point for different flows in RT >=20 > I'm not sure I really agree on this point. Lots of implications use = the PT along with the port received on to decide which codec to pass to = the RTP packet on to. I think, in practice, the PT has been a very key = demux pony for a long time in RTP.=20 To identify the codec, sure, that's what the PT is designed to do. = That's logically separate to identifying the source, which is the role = of the SSRC. --=20 Colin Perkins http://csperkins.org/ From ekr@rtfm.com Fri May 10 12:56:44 2013 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 04BD221F85C0 for ; Fri, 10 May 2013 12:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.701 X-Spam-Level: X-Spam-Status: No, score=-101.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzD1XzKFSdvf for ; Fri, 10 May 2013 12:56:39 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0921F8F6E for ; Fri, 10 May 2013 12:56:39 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id o13so519580qaj.20 for ; Fri, 10 May 2013 12:56:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=5lme8LZc2b8PDOHngiAhQkx8iMyIconjD12B7D3PZu0=; b=Kxm8StKH2GPTCRkDypez0ResRQ06vEtD+x8kzQAlIuo9ixkfLGsnTdJZ2YV3f7DgjB xbw5lcH9EkwOjfLGjhZpQdL4XPqLiZIAxgLAhMMPB0riWALHWgFQkSa9zSMLtjvG4ZPL lv2ESuE9loaxw9OJGv222JLlSUDvFl8yN/UrVv/GiNI4bBoomcKZELW1lEHPXhUrl6By /0RCt2RiG31kz3pu8JDgmZgj2K/FNaVUjdXzs+Lw0D2gXw5urqtMQuJ/g+my0odLNuKk 0TeryH2afCyqcFQCqH9uvIWXF+UoByKpUYmO49qSU+LgQMqD2vQBmoNoXEqFESApgx6o 7i0w== X-Received: by 10.229.22.138 with SMTP id n10mr5386920qcb.84.1368215799103; Fri, 10 May 2013 12:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.96.169 with HTTP; Fri, 10 May 2013 12:55:58 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca> From: Eric Rescorla Date: Fri, 10 May 2013 12:55:58 -0700 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=14dae9d70f8caea47d04dc629099 X-Gm-Message-State: ALoCoQkVYGvzRYHsLroKwtPNrrTsLEtmK3HFUPbU6tRgYRa+VwoaZtm3swL1LlWfkqnGWwIseMsB Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:56:44 -0000 --14dae9d70f8caea47d04dc629099 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 10, 2013 at 11:59 AM, Colin Perkins wrote: > On 10 May 2013, at 17:39, Cullen Jennings wrote: > > On May 8, 2013, at 4:33 AM, Colin Perkins wrote: > >> I agree: the PT was never intended to be used as a demultiplexing point > for different flows in RT > > > > I'm not sure I really agree on this point. Lots of implications use the > PT along with the port received on to decide which codec to pass to the RTP > packet on to. I think, in practice, the PT has been a very key demux pony > for a long time in RTP. > > > To identify the codec, sure, that's what the PT is designed to do. That's > logically separate to identifying the source, which is the role of the SSRC. > > I note that Bundle currently requires a totally disjoint PTs: "- The dynamic payload type values used in the "m=" lines MUST NOT overlap"' [ http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03#section-7.2 ] I had assumed this was done to allow demux. It seems to me that plan A relaxes this requirement in: http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-6.2 -Ekr --14dae9d70f8caea47d04dc629099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 10, 2013 at 11:59 AM, Colin = Perkins <csp@csperkins.org> wrote:
On 10 May 2013, at 17:39, Cullen Jennings wrote:
> On May 8, 2013, at 4:33 AM, Colin Perkins <csp@csperkins.org> wrote:
>> I agree: the PT was never intended to be used as a demultiplexing = point for different flows in RT
>
> I'm not sure I really agree on this point. Lots of implications us= e the PT along with the port received on to decide which codec to pass to t= he RTP packet on to. I think, in practice, the PT has been a very key demux= pony for a =A0long time in RTP.


To identify the codec, sure, that's what the PT is designed to do= . That's logically separate to identifying the source, which is the rol= e of the SSRC.


I note = that Bundle currently requires a totally disjoint PTs:
"- The dynamic payload type values used in the &qu= ot;m=3D" lines MUST NOT overlap"'

I had assum= ed this was done to allow demux.

It seems to me that plan A relaxes this requirement in:=

-Ekr
=A0
--14dae9d70f8caea47d04dc629099-- From fluffy@iii.ca Fri May 10 13:03:37 2013 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 58E0221F909A for ; Fri, 10 May 2013 13:03:37 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld4Cu-85HnUU for ; Fri, 10 May 2013 13:03:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7A57121F8EAD for ; Fri, 10 May 2013 13:03:31 -0700 (PDT) Received: from [10.1.4.202] (unknown [75.159.25.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8CA1B509B5; Fri, 10 May 2013 16:03:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Fri, 10 May 2013 14:03:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca> To: Colin Perkins X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:03:37 -0000 On May 10, 2013, at 12:59 PM, Colin Perkins wrote: > On 10 May 2013, at 17:39, Cullen Jennings wrote: >> On May 8, 2013, at 4:33 AM, Colin Perkins wrote: >>> I agree: the PT was never intended to be used as a demultiplexing = point for different flows in RT >>=20 >> I'm not sure I really agree on this point. Lots of implications use = the PT along with the port received on to decide which codec to pass to = the RTP packet on to. I think, in practice, the PT has been a very key = demux pony for a long time in RTP.=20 >=20 >=20 > To identify the codec, sure, that's what the PT is designed to do. = That's logically separate to identifying the source, which is the role = of the SSRC. But I am not trying to identify the source, if I wanted to do that I = agree CSRC would be one of things to use. I am trying to figure out = which codec to pass the incoming packet to. I don't mind using SSRC when = they are around but when they are not, PT seems perfectly reasonable to = use if uniquely identifiers which codec to pass the packet to. I realize = that you prefer the shim approach but when there is not a shim, I'm not = seeing the problem with using PT. Adam's draft also allows use of SSRC = for folks that want to overlap the PT from different m lines.=20 Consider a normal SIP call with only single speaker of G.711 audio with = early media where two sources are both sending to the same port and PT = on that phone. That's normal. It does not need to figure out the sources = to render the audio. Sure the codec probably might want to note that a = SSRC changed and retrain the jitter buffer but the phone does not care = about who the sources are in this case to play them. In more complicated = conferring cases the phone could use SSRC/CSRC info to map to roster = information received over some other protocol than SDP to display a name = for the active speaker or something. But thats a case where who the = sources are matters - this is just about getting the media to the right = codec on the right m line.=20 From worley@shell01.TheWorld.com Fri May 10 13:15:17 2013 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 969C521F918C for ; Fri, 10 May 2013 13:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f5Gl5z0Wt20 for ; Fri, 10 May 2013 13:15:11 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id A3D1321F8709 for ; Fri, 10 May 2013 13:15:11 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4AKEY99013821; Fri, 10 May 2013 16:14:36 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4AKEY3L4507011; Fri, 10 May 2013 16:14:34 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4AKEX6a4511811; Fri, 10 May 2013 16:14:33 -0400 (EDT) Date: Fri, 10 May 2013 16:14:33 -0400 (EDT) Message-Id: <201305102014.r4AKEX6a4511811@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-reply-to: <518AC143.2010006@nostrum.com> (adam@nostrum.com) References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:15:17 -0000 > From: Adam Roach > > What I was trying to say above is that the only information you would > need to convey is literally one, two, or three > pairs. You don't say what you're planning to do with them, just that you > need them. It seems unlikely that the situation is that simple. I see a number of issues. If the follower (= designated answerer) wants an additional, say, audio m= line, it asks for that. But how is it to know when it has been given them? The next re-INVITE to arrive from the leader (= designated offerer) may have been spontaneously sent, and it may have an additional audio m= line that the leader added, for entirely different purposes. The follower may misinterpret the use of the new m= line as the one that it ordered, and it will get confused when a further m= line shows up when the solicited re-INVITE arrives. (I've written a set of messy railroad diagrams below that show how the follower can lose track of what the leader is doing.) In any case, the logic in the draft assumes that the follower can determine when the leader has sent the solicited INVITE. (Among other things, the follower is then allowed to send another solicitation.) You can probably clean that up by having each solicitation contain a sequence number or identifier, and the leader copies the identifier into the INVITE it generates because of the solicitation. Then the follower can always tell what the state of the conversation is. If the solicited INVITE fails, the leader has to send it again, because the solicitation is still outstanding. This could lead to bad failure situations. There are situations where simply having "an additional audio m= line" is not sufficient. I'd expect that the leader, once it sees the follower's configuration of the m= line, might want to update its configuration of the m= line. (Because we are logically (though not in protocol) *offering* the m= line in the *answer*.) So the leader may want to do a re-INVITE cycle to get its end of the media stream configured. (This isn't an error, though, and can't cause a delay; it's just an implementation warning.) Another complex situation is where the follower wants to split a bundle. If the leader is willing to bundle all m= lines, but the follower wants to bundle 1 with 2 and 3 with 4, it's difficult for the follower to prompt the leader to offer that bundle configuration. Three situations that look much alike to the follower: Leader Follower | | | sol |-- send |<--------------| solicit | | respond --| INV | w/INVITE |-------------->| | | | 200 | |<--------------| | | spontaneous --| INV | INVITE |-------------->| | | | 200 | |<--------------| | | | |-- What's | | happening? | | | | | sol |-- send | +-------| solicit | | | spontaneous --| INV | | INVITE |-------|------>| | | | | | 200 | |<------|-------| | | | |<------+ | | | respond --| INV | w/INVITE |-------------->| | | | 200 | |<--------------| | | | |-- What's | | happening? | | | | | sol |-- send | +-------| solicit | | | spontaneous --| INV | | INVITE |-------|------>| | | | | | 200 | |<------|-------| | | | spontaneous --| INV | | INVITE |-------|------>| | | | | | 200 | |<------|-------| | | | |<------+ |-- What's | | happening? respond --| INV | w/INVITE |------> | to come | | | | Dale From worley@shell01.TheWorld.com Fri May 10 13:15:55 2013 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 768B321F85DC for ; Fri, 10 May 2013 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR8tlwpxwiGH for ; Fri, 10 May 2013 13:15:49 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6D43621F85D1 for ; Fri, 10 May 2013 13:15:49 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4AKFA8K000316 for ; Fri, 10 May 2013 16:15:12 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4AKFAog4513610 for ; Fri, 10 May 2013 16:15:10 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4AKFASK4512588; Fri, 10 May 2013 16:15:10 -0400 (EDT) Date: Fri, 10 May 2013 16:15:10 -0400 (EDT) Message-Id: <201305102015.r4AKFASK4512588@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> Subject: [rtcweb] Reducing glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:15:55 -0000 Two possible solutions for glare problems come to mind: One is to require the designated "follower" to accept and give a 200 response to an incoming re-INVITE even if it has an outstanding re-INVITE. The difficulty that follows is that the follower doesn't know whether the "leader" has accepted or rejected its re-INVITE until the response arrives, so there is an interval (between sending the 200 to the leader's re-INVITE and receiving the leaders response to its re-INVITE) during which the follower doesn't know its outgoing media configuration. We could probably fix that by annotating the leader's offers with the o= value of the follower's SDP that the leader currently is using. A second one would be to simply drastically shorten the glare backoff timer. Given that we're talking about video systems, the RFC 3261 timer ranges of 0 to 2 secs and 2.1 to 4 secs are very slow. If we cut those times by a factor of 10, wouldn't the user-visible problems nearly vanish? Dale From csp@csperkins.org Fri May 10 13:50:51 2013 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 3317421F845D for ; Fri, 10 May 2013 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V7lihrAISul for ; Fri, 10 May 2013 13:50:46 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id A4F0921F92EC for ; Fri, 10 May 2013 13:50:45 -0700 (PDT) Received: from [81.187.2.149] (port=48160 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UauH4-0000Wa-SW; Fri, 10 May 2013 21:50:44 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Fri, 10 May 2013 21:50:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C28EDB0-4ED2-447C-BF11-7E852F64660F@csperkins.org> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:50:51 -0000 On 10 May 2013, at 21:03, Cullen Jennings wrote: > On May 10, 2013, at 12:59 PM, Colin Perkins wrote: >> On 10 May 2013, at 17:39, Cullen Jennings wrote: >>> On May 8, 2013, at 4:33 AM, Colin Perkins wrote: >>>> I agree: the PT was never intended to be used as a demultiplexing = point for different flows in RT >>>=20 >>> I'm not sure I really agree on this point. Lots of implications use = the PT along with the port received on to decide which codec to pass to = the RTP packet on to. I think, in practice, the PT has been a very key = demux pony for a long time in RTP.=20 >>=20 >>=20 >> To identify the codec, sure, that's what the PT is designed to do. = That's logically separate to identifying the source, which is the role = of the SSRC. >=20 > But I am not trying to identify the source, if I wanted to do that I = agree CSRC would be one of things to use. I am trying to figure out = which codec to pass the incoming packet to. I don't mind using SSRC when = they are around but when they are not, PT seems perfectly reasonable to = use if uniquely identifiers which codec to pass the packet to. I realize = that you prefer the shim approach but when there is not a shim, I'm not = seeing the problem with using PT. Adam's draft also allows use of SSRC = for folks that want to overlap the PT from different m lines.=20 I wasn't thinking about the shim at all; this is independent of that. > Consider a normal SIP call with only single speaker of G.711 audio = with early media where two sources are both sending to the same port and = PT on that phone. That's normal. It does not need to figure out the = sources to render the audio. Sure the codec probably might want to note = that a SSRC changed and retrain the jitter buffer but the phone does not = care about who the sources are in this case to play them. Except that it does care about the source, as you say, to retrain the = jitter buffer. Or, if you're using something other than G.711 to reset = the codec state when you change source. Or to link to the appropriate = FEC or retransmission stream, comfort noise packets, RTCP reports, codec = control messages, etc. None of which works properly if you ignore the = SSRCs. WebRTC isn't building a dumb SIP phone that only does G.711. The = kind of features people are talking about for WebRTC need to use the = SSRC as the first demultiplexing point to work properly, then use the = payload type to select the codec.=20 > In more complicated conferring cases the phone could use SSRC/CSRC = info to map to roster information received over some other protocol than = SDP to display a name for the active speaker or something. But thats a = case where who the sources are matters - this is just about getting the = media to the right codec on the right m line.=20 --=20 Colin Perkins http://csperkins.org/ From ted.ietf@gmail.com Fri May 10 14:03:05 2013 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 3D0AE21F915B for ; Fri, 10 May 2013 14:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfFYsHrL77TZ for ; Fri, 10 May 2013 14:03:04 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA6A21F9154 for ; Fri, 10 May 2013 14:03:04 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id j3so3766795iae.5 for ; Fri, 10 May 2013 14:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ySXUzOta2EdP9iE1jlGoOs7XDnHEyeu1TAynuwJDFqM=; b=Nn08K8HF5sRWrt6S1opvZ0QVPSxfmfCO84djma2pgEGtFUVpXRC5dsarJjjtYgSSWt pnS9vfv/pSPrdGX006EscIthCrnzBmelWcGXV5FEkVcAM4jjc0j9ibPmyrACTlNWtnXM ofYhlpndGvKYgyDqQJF5lQyj4kLMGTvwg3s4wxVoLevQgRw5Iirmv3tIa5B0Jh/FXt0e +087GcFqgRBOTAEpwAYkcKbssXnMLfoewWPFBoj8q1rX+fn1GujX+o6Av8meofqnu7Cb BaQ3DaVKx3reDWNWZx903lesXZlSytZoJx9cTz1Svh5piLkF7wU0bmVbrGy+feqKAHy0 76aw== MIME-Version: 1.0 X-Received: by 10.50.110.106 with SMTP id hz10mr3481121igb.24.1368219783882; Fri, 10 May 2013 14:03:03 -0700 (PDT) Received: by 10.42.79.73 with HTTP; Fri, 10 May 2013 14:03:03 -0700 (PDT) In-Reply-To: <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> Date: Fri, 10 May 2013 14:03:03 -0700 Message-ID: From: Ted Hardie To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e01182f66316fcc04dc637e74 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:03:05 -0000 --089e01182f66316fcc04dc637e74 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 10, 2013 at 10:10 AM, Cullen Jennings wrote: > > > I want to be able to build a multi-screen telepresence systems that when > it constructs an Offer, that offer could be going to a webrtc compliant > browser, or it could be going to another CLUE complains endpoint. When it > constructs the offer, it does not know where it going and based on the > answer, the right thing will happen. So, I think you have elided some of the steps in this process because you presume we share an understanding. I'm really serious that I want this unpacked, because I think there's been a lot of talking past each other (no doubt some of it from me) What you've written says the offer is going to a "webrtc compliant browser", but the webrtc system is a compound of a browser and a specific downloaded javascript application. Can you unpack whether this offer is going to a downloaded javascript application *built to work with the telepresence system*? For example, a company manufacturing hardware telepresence systems could market a general web-based conference system that interworked with it-*if you used their specific downloaded javascript app*. If that's not meant to be sharing resources at the same time as other apps, it's not very different than a browser than can load a Hangout or start a Webex app now (You'll remember we actually even mixed those two apps at the Stockholm interim--by not mixing the resources). But if it works that way, the question of how to detect whether the downloaded javascript application supports CLUE or not seems to be answered--you know because you know what app is downloaded, right? If you mean interworking a CLUE telepresence system with an arbitrary downloaded javascript app, I think that's just flat off the table--why would pokerstars want to support CLUE? I have the strong feeling I'm missing something obvious here, which would make it great if we could speak in long, slow sentences with short words. thanks, Ted --089e01182f66316fcc04dc637e74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2013 at 10:10 AM, Cullen Jennings <fluffy@iii.ca> wrote:


I want to be able to build a multi-screen telepresence systems that w= hen it constructs an Offer, that offer could be going to a webrtc compliant= browser, or it could be going to another CLUE complains endpoint. When it = constructs the offer, it does not know where it going and based on the answ= er, the right thing will happen.

So, I think you have elided some of the steps in this process bec= ause you presume we share an understanding.=A0 I'm really serious that = I want this unpacked, because I think there's been a lot of talking pas= t each other (no doubt some of it from me)

What you've written says the offer is going to a "webrtc compl= iant browser", but the webrtc system is a compound of a browser and a = specific downloaded javascript application.=A0 Can you unpack whether this = offer is going to a downloaded javascript application *built to work with t= he telepresence system*?=A0 For example, a company manufacturing hardware t= elepresence systems could market a general web-based conference system that= interworked with it-*if you used their specific downloaded javascript app*= .=A0

If that's not meant to be sharing resources at the same time as oth= er apps, it's not very different than a browser than can load a Hangout= or start a Webex app now (You'll remember we actually even mixed those= two apps at the Stockholm interim--by not mixing the resources).=A0=A0 But= if it works that way, the question of how to detect whether the downloaded= javascript application supports CLUE or not seems to be answered--you know= because you know what app is downloaded, right?

If you mean interworking a CLUE telepresence system with an arbitrary d= ownloaded javascript app, I think that's just flat off the table--why w= ould pokerstars want to support CLUE?

I have the strong feeling I= 9;m missing something obvious here, which would make it great if we could s= peak in long, slow sentences with short words.

thanks,

Ted
--089e01182f66316fcc04dc637e74-- From pkyzivat@alum.mit.edu Fri May 10 14:20:10 2013 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 5019521F92C5 for ; Fri, 10 May 2013 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTbPz2LV1FrN for ; Fri, 10 May 2013 14:20:04 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 47AFF21F909A for ; Fri, 10 May 2013 14:20:04 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id a9yv1l00116LCl053ML3Dj; Fri, 10 May 2013 21:20:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id aML31l00p3ZTu2S3SML36P; Fri, 10 May 2013 21:20:03 +0000 Message-ID: <518D6482.2010008@alum.mit.edu> Date: Fri, 10 May 2013 17:20:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368220803; bh=FT8XmLPiOWIV4si8k3wBZVTlF0Bco3cgaGat0HWENTg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oNfVl7lxGSDq8NnTxMYbjFulOdMkNXlv9cYHL4XokCjMDR8o32OUJ4yKZpiD2cToV 4ZzZIB+eifRrE/w66wpVTlvt/NLk66wX5+bt6AEaGwEak63pgYWwE5ZsDqo0Xs4QZu YiXxKSC/tnQrCIR3ctMyAyO4qfF8oYL6teAFTLiJHxAoIXxjtvCxhOUk53e2TEl9pf sQJodlo6/7hQUOw5wCeJ9NynSR7mGFhxM9Oqf192HLJZp09umh6IQ7JhBr2f8NZYFF 8ygfd7u1ETWN8ybKcKgLQYOus8prvFfY9Re9FLyKm5a23fHaN3qGhFIgZ5O57E2/l8 v5D+NXdBXpTkg== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:20:10 -0000 On 5/10/13 2:37 AM, Stefan Håkansson LK wrote: ... > But I can easily think of other situations that would lead to glare for > Plan A. > > Just as an example, think about a conference scenario with a centralized > node. Now, one of the participants wants to mute her/his audio, and as a > result the audio m-line would go from sendrecv to recvonly. At roughly > the same time the server wants to disable the high res video and enable > the low res video (because this user will be moved, based e.g. on the > recent audio activity, from being displayed in the main video window to > be in a thumbnail on the screen of the other participants in the > conference), so it wants to manipulate the direction attribute of other > m-lines. > > So there would be two offers sent at roughly the same time, which means > we would have glare. What do you mean by "roughly"? How long does it take to do an O/A exchange that doesn't require human input? Presumably less than a second, maybe considerably less. (Or will it be more with RTCWEB and web servers in the path?) What is the probability that the other side, for independent reasons, decides to make a change within that interval? (And it isn't really the whole interval - it is only the first part of it.) There may indeed be realistic cases for glare, but they will probably be because both changes are keyed to a common event. Thanks, Paul From pkyzivat@alum.mit.edu Fri May 10 14:24:08 2013 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 877AD21F91CA for ; Fri, 10 May 2013 14:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 351iuJlFs-dj for ; Fri, 10 May 2013 14:24:02 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCBC21F9154 for ; Fri, 10 May 2013 14:24:02 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id aBP61l0020QuhwU55MQ1S6; Fri, 10 May 2013 21:24:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id aMQ11l00r3ZTu2S3NMQ12l; Fri, 10 May 2013 21:24:01 +0000 Message-ID: <518D6570.4060301@alum.mit.edu> Date: Fri, 10 May 2013 17:24:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <518BBE2A.4060102@alum.mit.edu> <518BC345.6060807@nostrum.com> <518C59B5.7050200@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368221041; bh=qXJxeRwgCbwTE5zGPSHJpmJHONz1VaJ+VKLSCkuHMXk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oyAfkYIHuCuFaDBAHdMITJf7C/r3RWBLNhm/JOrol3qCKL5KgfRfCRt1VJMpwnL3R Ite1ZSw3zbI8sEoshD+I6gUAJwRN/sHIsu2eGZ5wtdFi4dkYTwXAvg1BZgUovNbmTR QbCqVbn+nqIyyzOFEi+6ZofxkakhteMuaOKokPhlZwVuLiWnnyRdl4iMeDCUxebGg8 9cr4hBmA6/mbVF3Qur8SiV+4smKNOjjkFbKAe4dDBBai3DnJlst23E+kGKXQBoKYnq hhKmWyHgsTKkaAZc/fhV0k/T/X2JRaf7J5/zfH/OVO0uwV5+temhPLrIVsHFZU60fG 1hs0nrLuHQIZQ== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:24:08 -0000 On 5/10/13 12:54 PM, Cullen Jennings wrote: > > On May 9, 2013, at 8:21 PM, Paul Kyzivat wrote: > >> On 5/9/13 11:39 AM, Adam Roach wrote: >>> On 5/9/13 10:18, Paul Kyzivat wrote: >>>> On 5/8/13 5:18 PM, Adam Roach wrote: >>>>> >>>>> What I was trying to say above is that the only information you would >>>>> need to convey is literally one, two, or three >>>>> pairs. You don't say what you're planning to do with them, just that you >>>>> need them. >>>> >>>> How is that possibly enough? What codecs and codec parameters/optons? >>>> What bandwidth? What bundling options? The list goes on. >>> >>> I apologize. I must have done a really poor job in the prose in my >>> draft, since I clearly didn't communicate the fundamental mechanism that >>> I had in mind at all. >>> >>> Let me try with a ladder diagram to see whether that helps illuminate >>> what I'm proposing. >>> >>> >>> Offerer Answerer >>> | | >>> |<----------Solicitation-------------| >>> | (I need 1 new audio 1 new video) | >>> | | >>> | | >>> |-------------SDP Offer------------->| >>> | (Contains two more m-line sections | >>> | than the current session; one | >>> | audio, one video. Both recvonly.) | >>> | | >>> | | >>> |<------------SDP Answer-------------| >>> | (Makes use of the two new m-line | >>> | sections by populating them with | >>> | codec parameters, options, ssrc | >>> | bandwidth, bundling, etc, etc.) | >>> >> >> Yeah, I figured that from the last message. But the answer is constrained by the offer. So the answer may only have codecs that are listed in the offer. >> >> I guess the offerer can just include everything it is capable of supporting. But that would be especially unpleasant > > it seem to me that we all the same problems in the initial offer. The whole idea of an Offer/Answer is the offer has more or less has everything you support or are willing to do so I don't really see that being a big problem here. The existing O/A only works reasonably when variations from the norm are small. As long as it was just codecs on a single audio m-line it wasn't a big deal. Add one video m-line and it still has a reasonable chance of working. But in a case like CLUE, where each side has a mass of things available to send it doesn't work well at all. And some of the rtcweb cases have a lot of similarity to that. But this particular discussion is a little silly, because passing an "offer token" around doesn't have any of these problems. Thanks, Paul From pkyzivat@alum.mit.edu Fri May 10 14:54:06 2013 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 272D121F92C5 for ; Fri, 10 May 2013 14:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKzogJ9Ip-9x for ; Fri, 10 May 2013 14:54:00 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id A5A0021F90CD for ; Fri, 10 May 2013 14:53:59 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id aHxP1l0020Fqzac54Mtzaa; Fri, 10 May 2013 21:53:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id aMty1l0193ZTu2S3UMtyxV; Fri, 10 May 2013 21:53:59 +0000 Message-ID: <518D6C76.5060606@alum.mit.edu> Date: Fri, 10 May 2013 17:53:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Hardie References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368222839; bh=2/fusQbArvrO1HDc10OMIh6tIRUba0QT/8j4FlE68vY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UqghN53SM0WpQxylgZONEya3RdPTUuC1J/AlB8wWK8v3s0YNtECR/nRUQIA8Y1BqZ lXvV04AvfO5KszAxjQnHd0fjZ+vVYatCt/mogBdMMjxWuWEFiPZHLISGpn803lqHPX ibhWrYYG8LhyRN8YyRf4q0Hg2/OjIZi+w5oiSy597NtIgVHtxMhJ8nKX41lkXI1zZM OkWXrC6QTs2NouC49g+9h8Q+LdhHySCuEvNBs6MlsF4ENnM+8eKy9iIHAIsU7UlQqX jxa6VGPLZIB/d18ote9M8Q397u9TfoajnW51HlKJYej5XXtnW2LjjXCeR1oRTT3nvo ZZ1I7Msvdj3FQ== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:54:07 -0000 On 5/10/13 5:03 PM, Ted Hardie wrote: > On Fri, May 10, 2013 at 10:10 AM, Cullen Jennings > wrote: > > > > I want to be able to build a multi-screen telepresence systems that > when it constructs an Offer, that offer could be going to a webrtc > compliant browser, or it could be going to another CLUE complains > endpoint. When it constructs the offer, it does not know where it > going and based on the answer, the right thing will happen. > > > So, I think you have elided some of the steps in this process because > you presume we share an understanding. I'm really serious that I want > this unpacked, because I think there's been a lot of talking past each > other (no doubt some of it from me) Fair enough > What you've written says the offer is going to a "webrtc compliant > browser", but the webrtc system is a compound of a browser and a > specific downloaded javascript application. Can you unpack whether this > offer is going to a downloaded javascript application *built to work > with the telepresence system*? For example, a company manufacturing > hardware telepresence systems could market a general web-based > conference system that interworked with it-*if you used their specific > downloaded javascript app*. It could be either. CLUE is being designed to interop with "legacy" sip endpoints. A clue client will send an offer that will downgrade to vanilla SIP if the other end doesn't understand the clue specific stuff. But the interesting case is where the web server for the target intends to support clue - providing suitable javascript so that the browser can do the clue stuff. > If that's not meant to be sharing resources at the same time as other > apps, it's not very different than a browser than can load a Hangout or > start a Webex app now (You'll remember we actually even mixed those two > apps at the Stockholm interim--by not mixing the resources). But if it > works that way, the question of how to detect whether the downloaded > javascript application supports CLUE or not seems to be answered--you > know because you know what app is downloaded, right? The issue is the SDP stuff that is wired into the rtcweb browser machinery. Specifically, if rtcweb has one way to indicate the use of plan B, via MSID that identifies a MediaStreamTrack, and clue uses something else to indicate use of plan B and to bind a capture-encoding to an SSRC, then we have a problem. Maybe the answer is that CLUE needs to use MSIDs. But we first need to ensure that the semantics are right. Clue doesn't have media stream tracks. Maybe we will sort out the equivalences via the taxonomy, but that is moving along very well. I would hate to require the web server to be getting SDP from the browser and having to translate it from rtcweb-dialect-sdp to clue-dialect-sdp. > If you mean interworking a CLUE telepresence system with an arbitrary > downloaded javascript app, I think that's just flat off the table--why > would pokerstars want to support CLUE? Only in the "legacy" sense I mentioned above, and then only if the javascript is intended to support legacy sip. > I have the strong feeling I'm missing something obvious here, which > would make it great if we could speak in long, slow sentences with short > words. Does the above help? From ted.ietf@gmail.com Fri May 10 15:46:17 2013 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 776B521F8F38 for ; Fri, 10 May 2013 15:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwq6i6N8oOmE for ; Fri, 10 May 2013 15:46:16 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6D21F870F for ; Fri, 10 May 2013 15:46:16 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id k38so3325922iah.0 for ; Fri, 10 May 2013 15:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OE2ndcREx0AX8jBOVoD/mWMDF9Pg5imuZby7LH+i0ls=; b=JwZ/XIPFfhtMoLdRsVDux27eL6HY+k6X+zvhgICa72qeDlhUxmqlO0veLarw88TwMn IMZdP3dq+947ggigSnvkyc+PA9QTn8u4K5SlcyI/WPaZ+pp9bL2zBD4Rd8E6jEEVY1nZ 8FK2qFWsGN07DaWFnQjgUZnB1mGksnqhD3VuVLegh6Iu39y65ws90WLVnRkxGTfUZQzU 3YO6S6a6Q24VPJZ7NZkW+fb1VY0z7DnRhd534dk58IUP0cYcXf+WlsnHF2e3WsFtUtZl beKXFPOpl53jTPA0I2ptn+Uth+ogZkvKIdXrr+Vy+UqMvmvQCyIS4vNMRO6KeYtKFvgS KOMQ== MIME-Version: 1.0 X-Received: by 10.50.39.35 with SMTP id m3mr3581532igk.42.1368225976002; Fri, 10 May 2013 15:46:16 -0700 (PDT) Received: by 10.42.79.73 with HTTP; Fri, 10 May 2013 15:46:15 -0700 (PDT) In-Reply-To: <518D6C76.5060606@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> <518D6C76.5060606@alum.mit.edu> Date: Fri, 10 May 2013 15:46:15 -0700 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bdca5ca45b3d004dc64ef4b Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:46:17 -0000 --047d7bdca5ca45b3d004dc64ef4b Content-Type: text/plain; charset=ISO-8859-1 Inline. On Fri, May 10, 2013 at 2:53 PM, Paul Kyzivat wrote: > On 5/10/13 5:03 PM, Ted Hardie wrote: > >> On Fri, May 10, 2013 at 10:10 AM, Cullen Jennings > > wrote: >> >> >> >> I want to be able to build a multi-screen telepresence systems that >> when it constructs an Offer, that offer could be going to a webrtc >> compliant browser, or it could be going to another CLUE complains >> endpoint. When it constructs the offer, it does not know where it >> going and based on the answer, the right thing will happen. >> >> >> So, I think you have elided some of the steps in this process because >> you presume we share an understanding. I'm really serious that I want >> this unpacked, because I think there's been a lot of talking past each >> other (no doubt some of it from me) >> > > Fair enough > > > What you've written says the offer is going to a "webrtc compliant >> browser", but the webrtc system is a compound of a browser and a >> specific downloaded javascript application. Can you unpack whether this >> offer is going to a downloaded javascript application *built to work >> with the telepresence system*? For example, a company manufacturing >> hardware telepresence systems could market a general web-based >> conference system that interworked with it-*if you used their specific >> downloaded javascript app*. >> > > It could be either. > > I'm sorry, either what? Either a purpose-built javascript application or....? > CLUE is being designed to interop with "legacy" sip endpoints. A clue > client will send an offer that will downgrade to vanilla SIP if the other > end doesn't understand the clue specific stuff. > > Should I infer that one way forward here is for a clue client to downgrade to vanilla sip while speaking to gateway that has a webrtc client on the other side? > But the interesting case is where the web server for the target intends to > support clue - providing suitable javascript so that the browser can do the > clue stuff. > > > Okay, in this case the web server knows what the javascript application can do. This means, if I understand it, that there is no problem (*for this case*) in determining which endpoints support clue--because the webserver should known. Is that right? > If that's not meant to be sharing resources at the same time as other >> apps, it's not very different than a browser than can load a Hangout or >> start a Webex app now (You'll remember we actually even mixed those two >> apps at the Stockholm interim--by not mixing the resources). But if it >> works that way, the question of how to detect whether the downloaded >> javascript application supports CLUE or not seems to be answered--you >> know because you know what app is downloaded, right? >> > > The issue is the SDP stuff that is wired into the rtcweb browser > machinery. Specifically, if rtcweb has one way to indicate the use of plan > B, via MSID that identifies a MediaStreamTrack, and clue uses something > else to indicate use of plan B and to bind a capture-encoding to an SSRC, > then we have a problem. > > But this seems entirely separate from the point I thought kicked this off, when you said: "I* think it is important that clue and rtcweb to be able to coexist in a single endpoint, and for a clue+rtcweb client to interoperate with either another clue+rtcweb client or a pure clue client. Using different indicators in the two environments doesn't help with that." If I understand here is the clue-capable javascript application doesn't have to coexist in any meaningful sense with a non-clue rtcweb javascript application---it gets downloaded into a browser by a web server for the target. It's not coexisting with a different *active* client in that case, even if the browser could or has downloaded some other javascript for a different site. > Maybe the answer is that CLUE needs to use MSIDs. But we first need to > ensure that the semantics are right. Clue doesn't have media stream tracks. > Maybe we will sort out the equivalences via the taxonomy, but that is > moving along very well. > > I would hate to require the web server to be getting SDP from the browser > and having to translate it from rtcweb-dialect-sdp to clue-dialect-sdp. > But if the downloaded client speaks CLUE, why would it? > If you mean interworking a CLUE telepresence system with an arbitrary >> downloaded javascript app, I think that's just flat off the table--why >> would pokerstars want to support CLUE? >> > > Only in the "legacy" sense I mentioned above, and then only if the > javascript is intended to support legacy sip. > > > I think that's the gateway case I mentioned above, > I have the strong feeling I'm missing something obvious here, which >> would make it great if we could speak in long, slow sentences with short >> words. >> > > Does the above help? > > I guess I won't know until I see your and Cullen's answers to some of the above. Ted --047d7bdca5ca45b3d004dc64ef4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inline.

On Fri, May 10, 2013 at 2:53 PM, Paul Kyzivat <pkyzivat= @alum.mit.edu> wrote:
On 5/10/13 5:03 PM, Ted Hardie wrote:
On Fri, May 10, 2013 at 10:10 AM, Cullen Jennings <fluffy@iii.ca
<mailto:fluffy@iii.ca= >> wrote:



=A0 =A0 I want to be able to build a multi-screen telepresence systems that=
=A0 =A0 when it constructs an Offer, that offer could be going to a webrtc<= br> =A0 =A0 compliant browser, or it could be going to another CLUE complains =A0 =A0 endpoint. When it constructs the offer, it does not know where it =A0 =A0 going and based on the answer, the right thing will happen.


So, I think you have elided some of the steps in this process because
you presume we share an understanding. =A0I'm really serious that I wan= t
this unpacked, because I think there's been a lot of talking past each<= br> other (no doubt some of it from me)

Fair enough


What you've written says the offer is going to a "webrtc compliant=
browser", but the webrtc system is a compound of a browser and a
specific downloaded javascript application. =A0Can you unpack whether this<= br> offer is going to a downloaded javascript application *built to work
with the telepresence system*? =A0For example, a company manufacturing
hardware telepresence systems could market a general web-based
conference system that interworked with it-*if you used their specific
downloaded javascript app*.

It could be either.


I'm sorry, either what?=A0 Either a purpose-b= uilt javascript application or....?
=A0
CLUE is being designed to interop with "legacy" sip endpoints. A = clue client will send an offer that will downgrade to vanilla SIP if the ot= her end doesn't understand the clue specific stuff.


Should I infer that one way forward here is for a= clue client to downgrade to vanilla sip while speaking to gateway that has= a webrtc client on the other side?

=A0
But the interesting case is where the web server for the target intends to = support clue - providing suitable javascript so that the browser can do the= clue stuff.



Okay, in this case the web server knows wha= t the javascript application can do.=A0 This means, if I understand it, tha= t there is no problem (*for this case*) in determining which endpoints supp= ort clue--because the webserver should known.=A0 Is that right?


=A0
If that's not meant to be sharing resources at the same time as other apps, it's not very different than a browser than can load a Hangout or=
start a Webex app now (You'll remember we actually even mixed those two=
apps at the Stockholm interim--by not mixing the resources). =A0 But if it<= br> works that way, the question of how to detect whether the downloaded
javascript application supports CLUE or not seems to be answered--you
know because you know what app is downloaded, right?

The issue is the SDP stuff that is wired into the rtcweb browser machinery.= Specifically, if rtcweb has one way to indicate the use of plan B, via MSI= D that identifies a MediaStreamTrack, and clue uses something else to indic= ate use of plan B and to bind a capture-encoding to an SSRC, then we have a= problem.


But this seems entirely separate from the point I= thought kicked this off, when you said:=A0

"I* think it is im= portant that clue and rtcweb to be able to coexist in a single endpoint, and for a clue+rtcweb client to interoperate with=20 either another clue+rtcweb client or a pure clue client. Using different indicators in the two environments doesn't help with that."
If I understand here is the clue-capable javascript application doesn'= ;t have to coexist in any meaningful sense with a non-clue rtcweb javascrip= t application---it gets downloaded into a browser by a web server for the t= arget.=A0 It's not coexisting with a different *active* client in that = case, even if the browser could or has downloaded some other javascript for= a different site.=A0

=A0
Maybe the answer is that CLUE needs to use MSIDs. But we first need to ensu= re that the semantics are right. Clue doesn't have media stream tracks.= Maybe we will sort out the equivalences via the taxonomy, but that is movi= ng along very well.

I would hate to require the web server to be getting SDP from the browser a= nd having to translate it from rtcweb-dialect-sdp to clue-dialect-sdp.
<= /blockquote>

But if the downloaded client speaks CLUE, why would it= ?
=A0
If you mean interworking a CLUE telepresence system with an arbitrary
downloaded javascript app, I think that's just flat off the table--why<= br> would pokerstars want to support CLUE?

Only in the "legacy" sense I mentioned above, and then only if th= e javascript is intended to support legacy sip.


I think that's the gateway case I mentioned= above,

=A0
I have the strong feeling I'm missing something obvious here, which
would make it great if we could speak in long, slow sentences with short words.

Does the above help?


I guess I won't know until I see your and Cullen= 's answers to some of the above.

Ted
--047d7bdca5ca45b3d004dc64ef4b-- From dwing@cisco.com Fri May 10 15:48:57 2013 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 06DAE21F9428 for ; Fri, 10 May 2013 15:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LSVQZy+vPrO for ; Fri, 10 May 2013 15:48:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 020F721F9355 for ; Fri, 10 May 2013 15:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2329; q=dns/txt; s=iport; t=1368226131; x=1369435731; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9gGW67Ez6XHHr8Y9HhVmjKROLNBamiwzW3X2Cxz2leI=; b=bFoqgt5kZu6ylggcuOQus2u8BZwUfDJogUGXcOhUt4g3xR08a9EObcV5 FfKEwUqawGCuXs1n3fgtCU+/WwdsWc2NSHDEYadwnYLx+sY66h7BELNED kbYIBv41V3QxWHKwOKKy8pB/WwKXW9AQrFoRZO6/Jb/k1rU2xqPFfM/F6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAD54jVGrRDoH/2dsb2JhbAA8DQmDBzfAIHsWdIIfAQEBAwF5BQsLDgoTG1cGE4gGBQ29PI1eD4EIMweCdGEDiRqIBYI+g0+GFosfgy8c X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="77730723" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 10 May 2013 22:48:48 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4AMmmg1011841; Fri, 10 May 2013 22:48:48 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Fri, 10 May 2013 15:48:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <74300615-2293-4DCE-82A7-475F1A5A8256@gmail.com> <91B4F744-2201-4361-A8D8-7D36F47B865C@cisco.com> <95219856-8365-4A7E-BD0B-4EECE8868498@phonefromhere.com> <517A820F.9050807@alvestrand.no> <22E6A779-1573-4EDE-82D6-B1A831CE4833@cisco.com> <9D36A7FF-DFF0-4CDC-A4D2-01159FA246AA@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:48:57 -0000 On May 10, 2013, at 11:44 AM, Cullen Jennings wrote: >=20 > On May 6, 2013, at 8:56 AM, Dan Wing wrote: >=20 >>=20 >> On May 6, 2013, at 7:30 AM, Henry Lum = wrote: >>=20 >>> Chiming in late. >>>=20 >>> Speaking from a contact center perspective, a lot of calls are = required to be recorded. In order to allow active recording (such as = SIPREC), the contact center has to provide a media endpoint for bridging = media so that a copy of the media can be created. The users will have to = trust the contact center to handle the media anyways, and the media must = be decrypted and re-encrypted by some media element within the contact = center to perform recording. To me DTLS-SRTP-EKT does not provide any = additional benefit over SDES for this type of use case. >>=20 >> Only DTLS-SRTP proves the call is actually to the call center (bank, = stock broker, reservation company).=20 >=20 > Uh, can you say a bit more about how DTLS-SRTP provides that? =20 >=20 The certificate can be verified using an identity provider. That can be = a company like OneID, Facebook, a classic Certificate Authority, a = privately-maintained list of previous certificates we used for that same = identity (e.g., in my own addressbook, similar to the mechanism = described by ZRTP), network notaries (similar to = http://perspectives-project.org/notary-servers). Identity can also be = provided by the WEBRTC operator if the is sufficient (e.g., facebook can = be the identity provider for facebook users). The strength of this = model is the identity provider can be anyone, so if a user wants to = verify identity with a 3rd party, they can. > The topic of how this is done and if it reduces to the same security = as SDES has been controversial and would be good to get people = understanding the issues her Without separate identity, a bank or healthcare provider will be unable = to certify their identity to a 3rd party (my local addressbook, = Facebook, a network notary service, etc.). Instead, their identity = would be attested by whatever entity originates or terminates the RTCWEB = session, and the user and the browser have no basis to build a stronger, = more robust system to protect against such abuse. -d From stefan.lk.hakansson@ericsson.com Sat May 11 04:50:12 2013 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 927E621F8E94; Sat, 11 May 2013 04:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPCg2FRjRApI; Sat, 11 May 2013 04:50:06 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2F3F21F8E8E; Sat, 11 May 2013 04:50:05 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-a4-518e306c3ccc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.02.28165.C603E815; Sat, 11 May 2013 13:50:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Sat, 11 May 2013 13:50:04 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w== Date: Sat, 11 May 2013 11:50:03 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvrW6OQV+gwdpfuhZ7/i5it5i6/DGL xYoNB1gt1v5rZ3dg8fj7/gOTx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVseHhEvaCZUIV a360sDUwHuLrYuTkkBAwkTi25xgzhC0mceHeerYuRi4OIYHDjBK9R78wQjhLGCVmrVsGVsUm ECixdd8CoCoODhEBDYlJW9VATGaBXIkv0wJAKoQFvCW2bVgIVi0i4COx/uYhdghbT6Kldwsr iM0ioCpx7dU5MJtXwFfiw5/drBCrpjFJdE5ZxQaSYAQ66PupNUwgNrOAuMStJ/OZIA4VkFiy 5zzU0aISLx//Y4WwlSR+bLjEAlGvJ3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGzkLTM QtIyC0nLAkaWVYzsuYmZOenlhpsYgZFycMtv3R2Mp86JHGKU5mBREudN4moMFBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cCoI/my++fviee+t79TOVnbeOPCcr6rHuf1WOyXav7NnL5CIDPt WMGpbab6kQVH37+vumKTtcz2lc9X/fuTbLSmuMnfrpsrxvqNjfuu/Fq1+FdxQvf8j02e8v9U 79dp5VeZio7sUBZIcrhzd1axd97+uW2blVPydKUvp2zKuZXy7u4aldu7z8fdUmIpzkg01GIu Kk4EAES/Z81iAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 11:50:12 -0000 On 5/10/13 11:20 PM, Paul Kyzivat wrote:=0A= > On 5/10/13 2:37 AM, Stefan H=E5kansson LK wrote:=0A= > ...=0A= >> But I can easily think of other situations that would lead to glare for= =0A= >> Plan A.=0A= >>=0A= >> Just as an example, think about a conference scenario with a centralized= =0A= >> node. Now, one of the participants wants to mute her/his audio, and as a= =0A= >> result the audio m-line would go from sendrecv to recvonly. At roughly= =0A= >> the same time the server wants to disable the high res video and enable= =0A= >> the low res video (because this user will be moved, based e.g. on the=0A= >> recent audio activity, from being displayed in the main video window to= =0A= >> be in a thumbnail on the screen of the other participants in the=0A= >> conference), so it wants to manipulate the direction attribute of other= =0A= >> m-lines.=0A= >>=0A= >> So there would be two offers sent at roughly the same time, which means= =0A= >> we would have glare.=0A= >=0A= > What do you mean by "roughly"?=0A= >=0A= > How long does it take to do an O/A exchange that doesn't require human=0A= > input? Presumably less than a second, maybe considerably less. (Or will= =0A= > it be more with RTCWEB and web servers in the path?)=0A= =0A= That sounds right to me.=0A= =0A= >=0A= > What is the probability that the other side, for independent reasons,=0A= > decides to make a change within that interval? (And it isn't really the= =0A= > whole interval - it is only the first part of it.)=0A= =0A= Given that in multiparty services the "main" video changes quite often, =0A= I'd not say this is extremely low. It will happen.=0A= =0A= But, given that there is a way to roll-back in a predictable way I think = =0A= glare resolution could be quick - nothing stops the web application from = =0A= including a random number in every offer, and resolve glare based on =0A= that (one of the offers "win").=0A= =0A= So I think glare will happen in practice (that is what I wanted to point = =0A= out), but it is not a show-stopper provided there is a way to roll back.=0A= =0A= >=0A= > There may indeed be realistic cases for glare, but they will probably be= =0A= > because both changes are keyed to a common event.=0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Sat May 11 05:20:19 2013 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 7E6C121F8AD5 for ; Sat, 11 May 2013 05:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gote4RNRDf7z for ; Sat, 11 May 2013 05:20:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E64CB21F8ADF for ; Sat, 11 May 2013 05:20:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-29-518e377c9085 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4A.59.32006.C773E815; Sat, 11 May 2013 14:20:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Sat, 11 May 2013 14:20:12 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Cullen Jennings Thread-Topic: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOTa514PcF8tvBwUOl8gWNxiH9Cw== Date: Sat, 11 May 2013 12:20:11 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW6NeV+gwfKV2hYf1v9gtFj7r53d gcljyZKfTB6Xz39kDGCK4rJJSc3JLEst0rdL4Mr43rWFvWCWUMX2622sDYy3+LoYOTkkBEwk jn57ywphi0lcuLeerYuRi0NI4DCjxKuGVhYIZwmjxKY/WxlBqtgEAiW27lvABmKLCChLnNtx lxnEZhZQl7iz+Bw7iC0sECJx5O8MdoiaUImrfW+hbD2JeQfWAtVzcLAIqEq8fecMEuYV8JWY e2ot1OJ5TBK9z3pYQBKMQBd9P7WGCWK+uMStJ/OZIC4VkFiy5zwzhC0q8fLxP6gPlCQalzxh hajXk7gxdQobhK0tsWzha2aIZYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkb23MTMnPRy o02MwGg4uOW36g7GO+dEDjFKc7AoifMmczUGCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDM XBc9t3r2YrlHbpXGt5vv1QuHWR47c+OQQzLz15e268/dnX/22MLvwr7HZxcsUMnymBvacOrQ BLXguzlWP/ztdh28zt15T2ie0+S+h3YXJ2nfY+YteWrEXzP9m/Jp7y6tBftMlqSV8ShOkna5 /7xw39cJk15lS9przHRn2pm/yvKkc+jBZ1XLlFiKMxINtZiLihMBaMXCAVQCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 12:20:19 -0000 On 5/10/13 8:44 PM, Cullen Jennings wrote:=0A= >=0A= > On May 8, 2013, at 2:52 AM, Stefan H=E5kansson LK=0A= > wrote:=0A= >=0A= >> * The (3-way) handshake is well aligned with the API (where the=0A= >> sending app initiates the sending of media)=0A= >=0A= > Interesting - I saw it sort of the opposite so perhaps you can you=0A= > say some more.=0A= =0A= Absolutely. The API (as of now) is aligned towards sending media. You'd =0A= construct a PC-stream containing PC-tracks which in turn corresponds to =0A= microphones and cameras. If you want to send that PC-stream to a peer =0A= you do "addStream" with it on a PeerConnection. If you want to add or =0A= remove a PC-track, there are operations for that - and it would be =0A= reflected on the far end.=0A= =0A= The point is that the API is about sending - not about setting up a =0A= session with a certain amount of ougoing and incoming PC-tracks, and to =0A= me that harmonizes very well with the handshake in =0A= draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media =0A= A->B and B->A respectively. An additional benefit seems to be that those = =0A= two exchanges are somewhat independent and would not cause glare. This =0A= is denoted as a 3-way handshake in the draft, that is a bit misleading =0A= perhaps.=0A= =0A= I think this is actually proposed in the JSEP draft as well, look at the = =0A= second part of =0A= http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.2.3.1=0A= =0A= =0A= > I saw this as a complete change to everything we had=0A= > discussed up to this point in how the API would work and how it would=0A= > interact with Offer/Answer. I figured dealing with this change would=0A= > set back the W3C API work over 8 months so this is good news if you=0A= > see a way that it is the well alighted. Can you explain how it lines=0A= > up with the current drafts, call flows, existing example=0A= > applications, and APIs that are all based on a 2 way hand shake?=0A= =0A= As I read draft-uberti-rtcweb-plan-00, no API changes are needed or =0A= proposed, and the call flows could stay the same (but as I recollect the = =0A= discussion at the Boston interim they should be changed for other reasons).= =0A= =0A= >=0A= >=0A= >=0A= =0A= From ekr@rtfm.com Sat May 11 07:14:54 2013 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 2311821F8EF2 for ; Sat, 11 May 2013 07:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZfxsqa363oU for ; Sat, 11 May 2013 07:14:48 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 377B021F8E4C for ; Sat, 11 May 2013 07:14:48 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so2931970qeb.20 for ; Sat, 11 May 2013 07:14:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=zr7GWwivUiTiLhyI8G9Xv305PswGb/fJcwJcXztq7Vo=; b=E6PpI501jYLsd05dbo9oSp2w5yd4asM9TRSRo+oKiX2YqiA+HUmoJWxHQu863g2xSM uJHK20dy3vfNNIBbH6Oj6xvip/a9/h8sR9Ga7XrfjC1IN8qpZBSXEXAqMzwdV0X6igET RIBvPwUT4avVgklVnqpbYmIxrjP6CCjTD7kiieGsyVqJ0JCgeHPLIy5CKsJetovbxD+j rOvty4WqjmHGF1KyUnRBYNY42z+NKFVTdyuFErqYEA9/iHgs78LlP+d3Tifke9v2Uoj3 DnE7lTYK/lytNxA483d+obiAu/3rgeEhcFPfH/GFrTlVQTLJwLMSajLbQ6HQdQHrSdns A89g== X-Received: by 10.224.98.9 with SMTP id o9mr15334434qan.31.1368281687684; Sat, 11 May 2013 07:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.96.169 with HTTP; Sat, 11 May 2013 07:14:07 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sat, 11 May 2013 07:14:07 -0700 Message-ID: To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=20cf3074d7d0f289c304dc71e7b3 X-Gm-Message-State: ALoCoQmwegaBvFkHxOM532RZ5kEoJe/Zna93VmRqRJN77wPBHndxEkRmoWzZ/QqwD5jZW+CdNYgt Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 14:14:54 -0000 --20cf3074d7d0f289c304dc71e7b3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 11, 2013 at 5:20 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > > As I read draft-uberti-rtcweb-plan-00, no API changes are needed or > proposed, and the call flows could stay the same (but as I recollect the > discussion at the Boston interim they should be changed for other reasons= ). I wanted to address this point in isolation... I believe that both Plan A and Plan B require at least one change to the API: the ability to indicate that a stream is important and thus requires backward-compatible treatment. In Plan A this means not marking it bundle-only. In Plan B it means putting it on its own m-line. -Ekr --20cf3074d7d0f289c304dc71e7b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, May 11, 2013 at 5:20 AM, Stefan = H=E5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
As I read draft-uberti-rtcweb-plan-00, no API changes are needed or
proposed, and the call flows could stay the same (but as I recollect the discussion at the Boston interim they should be changed for other reasons).=

I wanted to address this point in isolatio= n...

I believe that both Plan A and Plan B require= at least one change to
the API: the ability to indicate that a stream is important and thus
requires backward-compatible treatment. In Plan A this means
=
not marking it bundle-only. In Plan B it means putting it on its own
m-line.

-Ekr

--20cf3074d7d0f289c304dc71e7b3-- From pkyzivat@alum.mit.edu Sat May 11 09:24:25 2013 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 D481821F9347 for ; Sat, 11 May 2013 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nWKG6cN8zAi for ; Sat, 11 May 2013 09:24:20 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2421F9239 for ; Sat, 11 May 2013 09:24:11 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id afxz1l0010EZKEL5FgQBWw; Sat, 11 May 2013 16:24:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id agQA1l00k3ZTu2S3MgQAyq; Sat, 11 May 2013 16:24:11 +0000 Message-ID: <518E70A9.7070007@alum.mit.edu> Date: Sat, 11 May 2013 12:24:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368289451; bh=8UTa6ZJNZGmpimfK6oznzEHlDAk382YzHGooMGsU7bQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Zz+PbQH+sO7FXuvWynkPx7UnGuaK2tz8HZ9iv96gzSuLuuyY4S5pLplNaIDNQn9Um iVYp6XIRM9BW98BqxtMbZsL5y3Orts1Mdddj5b4FaAGDy1TkHLxDlHKHyzNrFF6xAL E/YVxSifJ1BKcx0o44SWqxAGuMIM9YH26PPsyt2Vv6UGwgyTBkXdJMqZcsHEBaraXV HkOF+hJXYtSK8B3Eu+27grHm1ZA4RSg9ZWGQwwR+UZTjyJmM8yOXeSVh87fD16bpIv kWmMdqice8VO8q+3GVKlpqmEckbCCN04kFysyrW8RNthSUmmGwKbahAP7GgTT93b9G jlPEOt2l40hXw== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 16:24:26 -0000 On 5/11/13 7:50 AM, Stefan Håkansson LK wrote: > On 5/10/13 11:20 PM, Paul Kyzivat wrote: >> What is the probability that the other side, for independent reasons, >> decides to make a change within that interval? (And it isn't really the >> whole interval - it is only the first part of it.) > > Given that in multiparty services the "main" video changes quite often, > I'd not say this is extremely low. It will happen. Are you thinking that there will be an SDP change every time the speaker changes??? Or do you mean changes when participants join and leave a conference? I would hope there will normally not be SDP changes for either of those events. > But, given that there is a way to roll-back in a predictable way I think > glare resolution could be quick - nothing stops the web application from > including a random number in every offer, and resolve glare based on > that (one of the offers "win"). > > So I think glare will happen in practice (that is what I wanted to point > out), but it is not a show-stopper provided there is a way to roll back. I'm sure it will happen. The question is whether it happens often enough to do more than count on the normal glare recovery procedures. Thanks, Paul From pkyzivat@alum.mit.edu Sat May 11 09:51:26 2013 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 1AFD421F8B64 for ; Sat, 11 May 2013 09:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.182 X-Spam-Level: X-Spam-Status: No, score=-0.182 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9N83k1+YkAd for ; Sat, 11 May 2013 09:51:20 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7335E21F8539 for ; Sat, 11 May 2013 09:51:19 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id ac921l00716LCl055grDA4; Sat, 11 May 2013 16:51:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id agrD1l00a3ZTu2S3SgrDTl; Sat, 11 May 2013 16:51:13 +0000 Message-ID: <518E7700.1080906@alum.mit.edu> Date: Sat, 11 May 2013 12:51:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368291073; bh=wB4XNvyjdnVCeacxn+B4/wovRoaUl/krqBhYfaa3sWo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YRF9YEbMJLtBbjoN+g/T1LvivXp0T5MVJ65a5AJQn7C5gvwmZ0xGhzVOrfBU/IX5o aYNjY1a9EtN9pjqZm/mBqxBDsYGcSGwStElxzok2Pi7L8Kg7cO9KFhmitc1V7dP850 yz7xlmAntv7aBwen44IWnp2jIhgI6fJ/DCNKuRrruFpwIMncibjLRmIZPIZidVJdRw XoYZ9bcPrQUtA4nitAD7mPmJmgvzzlecExA1QHZJ9Utv3TR6M3c5wv+gN5h6AY+/Sr 17rcZ//z36di88s1eaHe4oGVy0BVgGWiDcbRcqHEca4YuaW9JBFGElftnvaryAVzwx qzF9sJWYf3hmA== Subject: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 16:51:26 -0000 I found what Stefan said below to be interesting: On 5/11/13 8:20 AM, Stefan Håkansson LK wrote: > Absolutely. The API (as of now) is aligned towards sending media. You'd > construct a PC-stream containing PC-tracks which in turn corresponds to > microphones and cameras. If you want to send that PC-stream to a peer > you do "addStream" with it on a PeerConnection. If you want to add or > remove a PC-track, there are operations for that - and it would be > reflected on the far end. > > The point is that the API is about sending - not about setting up a > session with a certain amount of ougoing and incoming PC-tracks, and to > me that harmonizes very well with the handshake in > draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media > A->B and B->A respectively. An additional benefit seems to be that those > two exchanges are somewhat independent and would not cause glare. This > is denoted as a 3-way handshake in the draft, that is a bit misleading > perhaps. A very similar situation holds for CLUE. Maybe this is a more fundamental change than we have been thinking. O/A works best when both sides have similar capabilities and desires. (It makes sense to set up to receive what I hope to receive, because it is likely that you will want to send that.) It works poorly when you and I might have a highly eclectic set of stuff we could send, and unpredictable interests for what we are interested in receiving. In clue we are addressing that by exchanging (in a separate channel) advertisements of what the endpoints are willing to send, and only doing O/A to set up the media that is of interest. In rtcweb it isn't so structured, but I suspect something is happening implicitly, though it may be more hard-wired per application. In clue we may still end up negotiating separate one-way streams in each direction, similar to what Stefan mentions below. With bundling there isn't a big penalty for that (e.g., in ports and RTCP traffic) though there is an extra O/A required. But for both RTCWEB and CLUE there are cases where we must negotiate bidirectional streams for compatibility with legacy devices. So there must be a way to do that. I don't have a specific action to recommend here. This just seems like a somewhat fundamental shift that out to be recognized. It probably isn't just RTCWEB and CLUE, it is really related to more complex communication scenarios. ISTM that CLUE is addressing this by building a layer on top of O/A, while RTCWEB is *battling* with O/A. Thanks, Paul From bernard_aboba@hotmail.com Sat May 11 14:08:35 2013 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 1A68721F8AD5 for ; Sat, 11 May 2013 14:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nrEJcRPhInC for ; Sat, 11 May 2013 14:08:29 -0700 (PDT) Received: from blu0-omc3-s36.blu0.hotmail.com (blu0-omc3-s36.blu0.hotmail.com [65.55.116.111]) by ietfa.amsl.com (Postfix) with ESMTP id 189DC21F899E for ; Sat, 11 May 2013 14:08:29 -0700 (PDT) Received: from BLU169-W81 ([65.55.116.73]) by blu0-omc3-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 May 2013 14:08:28 -0700 X-EIP: [9scIkVfLuc1Q0d7ppPcpSBEg6rrlbsOJ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ed3f6848-ab3a-496e-9a0d-4ab5d00841a3_" From: Bernard Aboba To: Paul Kyzivat , "rtcweb@ietf.org" Date: Sat, 11 May 2013 14:08:28 -0700 Importance: Normal In-Reply-To: <518E7700.1080906@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <518A1268.8090107@ericsson.com>, <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca>, <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se>, <518E7700.1080906@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2013 21:08:28.0865 (UTC) FILETIME=[AF4AAB10:01CE4E8B] Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 21:08:35 -0000 --_ed3f6848-ab3a-496e-9a0d-4ab5d00841a3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul Kyzivat said:=20 > I don't have a specific action to recommend here. This just seems like a= =20 > somewhat fundamental shift that out to be recognized. It probably isn't=20 > just RTCWEB and CLUE=2C it is really related to more complex communicatio= n=20 > scenarios. ISTM that CLUE is addressing this by building a layer on top=20 > of O/A=2C while RTCWEB is *battling* with O/A. [BA] IMHO=2C the distinction between CLUE and RTCWEB may not be that clear = cut=2C and so the issues (and considerations) that arise in CLUE may also c= ome up in RTCWEB=2C although they may not be recognized as such.=20 For example=2C within the use case document the scenario in Section 4.2.11 = (Hockey Game Viewer) refers to use of multiple cameras on a single host. C= learly it is possible for a host to have multiple cameras as well as multip= le screens attached=2C and existing WebRTC implementations are capable of m= aking use of those capabilities=2C though perhaps not to the full extent en= visioned in CLUE.=20 So while I do agree with Ted Hardie when he said "If you mean interworking = a CLUE telepresence system with an arbitrary downloaded _javascript_ app=2C= I think that's just flat off the table--why would pokerstars want to suppo= rt CLUE?"=2C at the same time if you asked me what part of the functionalit= y described in CLUE was out-of-scope of WebRTC based on the use case docume= nt=2C I might not be able to come up with all that much (e.g. exchange and= use of spatial information). =20 This is why I find it disturbing for WebRTC and CLUE RTP usage documents to= come to different conclusions about required RTP functionality *for simila= r scenarios*. For example=2C I do not think that the concept of MSID and C= LUE capture are all that different=2C so that I do not buy that supporting = each of these concepts require different solutions. So if we are debating w= hether an RTP extension (or SDES item) is needed to indicate the CLUE captu= re to which an RTP flow pertains=2C then I would assert that the same logic= would apply (or not apply) to msid.=20 It is one thing to make different design decisions based on aspects of a sc= enario which are fundamentally different than another scenario. It's anoth= er thing to make different design decisions purely because the two scenario= s are handled in different WGs.=20 = --_ed3f6848-ab3a-496e-9a0d-4ab5d00841a3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul Kyzivat said: =3B
<= br>
>=3B I don't have a specific action to recommend here. This just = seems like a
>=3B somewhat fundamental shift that out to be recognize= d. It probably isn't
>=3B just RTCWEB and CLUE=2C it is really relate= d to more complex communication
>=3B scenarios. ISTM that CLUE is add= ressing this by building a layer on top
>=3B of O/A=2C while RTCWEB i= s *battling* with O/A.

[BA] IMHO=2C the distinctio= n between CLUE and RTCWEB may not be that clear cut=2C and so the issues (a= nd considerations) that arise in CLUE may also come up in RTCWEB=2C althoug= h they may not be recognized as such. =3B

For = example=2C within the use case document the scenario in Section 4.2.11 (Hoc= key Game Viewer) refers to use of multiple cameras on a single host.  = =3BClearly it is possible for a host to have multiple cameras as well as mu= ltiple screens attached=2C and existing WebRTC implementations are capable = of making use of those capabilities=2C though perhaps not to the full exten= t envisioned in CLUE. =3B

So while I do = agree with Ted Hardie when he said "If you mean interworking a CLUE telepresence = system with an arbitrary downloaded _javascript_ app=2C I think that's just= flat off the table--why would pokerstars want to support CLUE?"=2C at the = same time if you asked me what part of the functionality described in CLUE = was out-of-scope of WebRTC based on the use case document=2C  =3BI migh= t not be able to come up with all that much (e.g. exchange and use of spati= al information).  =3B

This is why I fin= d it disturbing for WebRTC and CLUE RTP usage documents to come to differen= t conclusions about required RTP functionality *for similar scenarios*. &nb= sp=3BFor example=2C I do not think that the concept of MSID and CLUE captur= e are all that different=2C so that I do not buy that supporting each of th= ese concepts require different solutions. So if we are debating whether an = RTP extension (or SDES item) is needed to indicate the CLUE capture to whic= h an RTP flow pertains=2C then I would assert that the same logic would app= ly (or not apply)  =3Bto msid. =3B

It is o= ne thing to make different design decisions based on aspects of a scenario = which are fundamentally different than another scenario.  =3BIt's anoth= er thing to make different design decisions purely because the two scenario= s are handled in different WGs. =3B


=
= --_ed3f6848-ab3a-496e-9a0d-4ab5d00841a3_-- From bernard_aboba@hotmail.com Sat May 11 16:59:56 2013 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 76E9421F8AD5 for ; Sat, 11 May 2013 16:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vgr2-KHMR-n for ; Sat, 11 May 2013 16:59:51 -0700 (PDT) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C021F8B2B for ; Sat, 11 May 2013 16:59:50 -0700 (PDT) Received: from BLU169-W115 ([65.55.116.72]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 May 2013 16:59:49 -0700 X-EIP: [19fqnCcSrzjUQD+BuyrHsFX+EDEcU8Dt] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_99b62df1-10d4-4679-9d7d-00cf5754d31f_" From: Bernard Aboba To: "rtcweb@ietf.org" Date: Sat, 11 May 2013 16:59:49 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2013 23:59:49.0533 (UTC) FILETIME=[9F0C1CD0:01CE4EA3] Subject: [rtcweb] Comments on draft-uberti-rtcweb-plan-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 11 May 2013 23:59:56 -0000 --_99b62df1-10d4-4679-9d7d-00cf5754d31f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First some general comments:=20 To some extent this document is arguing against a straw man (individual m= =3D lines for RTP streams) that in its extreme case (dozens of RTP streams= =2C possibly with simulcast and layered coding) is quite impractical. AFAI= K=2C many (if not the majority) of video implementations have rejected that= purist "Plan A" approach. So to some extent=2C the document is beating a = horse that is quite dead (or should be). To characterize that dead horse = as "legacy" is a mistake -- in fact legacy implementations are more sophist= icated than that=2C and several resemble Plan B in their approach=2C though= not quite enough to avoid potential interoperability problems. More later= on how to get betterinteroperability with legacy and also how to reduce th= e exchange to a single O/A in common cases.=20 Section 2.4 2.4. Interworking with legacy devices=0A= =0A= When interacting with a legacy application that only knows how to=0A= deal with a small number of sources=2C it must be possible to degrade=0A= gracefully to a usable basic experience=2C where at least a single=0A= audio and video source are active on each side=2C using a typical offer= =0A= /answer exchange. [BA] I would suggest that only being able to handle a single legacy stream = is toolimiting. It seems that it should be possible to handle multiple un= declared SSRCs as long as it is assumed that they inherit the parameters de= clared for the RTP session they are part of.=20 2.1 These layouts can change dynamically=2C depending on the conference=0A= content and the preferences of the receiver. As such=2C there are not= =0A= well-defined 'roles'=2C that could be used to group sources into=0A= specific 'large' or 'thumbnail' categories. As such=2C the requirement= =0A= Plan B attempts to satisfy is support for sending and receiving up to=0A= hundreds of simultaneous=2C hetereogeneous sources.=0A= [BA] While I agree that the layouts can change dynamically=2C I am wonderin= g if there is an implication that the burden of determining the 'roles' is = on the mixer. For example=2C it might be assumed that the mixer allocates = an SSRC for the 'large' category=2C and other SSRCs for the 'thumbnails' an= d then these SSRCs are statically mapped to MSTs and rendered. However=2C = another way to handle it is for the browser to handle the role assignment= =2C and I would argue that this could make more sense in some cases=2C part= icularly since this could make the mixer a lot simpler=2C or even obviate t= he need for a mixer entirely (e.g. an RTP translator might work in some cas= es). =20 2.6. Simple binding of MediaStreamTrack to SDP=0A= =0A= In WebRTC=2C each media source is identified by a MediaStreamTrack=0A= object. In order to ensure that the MSTs created by the sender show=0A= up at the receiver=2C each MST's id attribute needs to be reflected in= =0A= SDP. [BA] While I might understand why the MST ID might be useful to expose in t= he API=2C I don't see why this needs to be signaled over the wire. In gener= al=2C since WebRTC is supposed to be "signaling independent"=2C we should t= ry to avoid signaling things that don't need to be signaled. With respect = to MST id=2C a number of approaches seem preferrable=2C including use of an= RTP SDES item=2C or (even better)allowing the receiver to determine which = MediaStreamTrack an incoming RTP stream belongs to when the SSRC is first r= eceived. =20 2.7. Support for RTX=2C FEC=2C simulcast=2C layered coding=0A= =0A= For robust applications=2C techniques like RTX and FEC are used to=0A= protect media=2C and simulcast/layered coding can be used to provide=0A= support to hetereogeneous receivers. It needs to be possible to=0A= support these techniques=2C allow the receipient to optionally use or=0A= not use them on a source-by-source basis=2C and for simulcast/layered=0A= scenarios=2C control which simulcast streams or layers are received. [BA] In practice=2C control over simulcast streams or layers is often left = with the sender. That is=2C a sender can determine what simulcast stream o= r set of layers will go a particular receiver based on the RTCP feedback. = What the receiver needs to indicate is what it is capable of receiving (e.g= . "I can handle up to 4 temporal layers"). While I'm not against allowing = a receiver to indicate what simulcast or layered streams it wants to receiv= e=2C I don't think this is the most important use case. In particular=2C a= ssuming receiver-side control isn't compatible with the sender-side congest= ion control most commonly used along with simulcast/layered coding.=20 Section 3.1 By only using a m=3D line for each media type=2C as opposed to each medi= a=0A= source=2C this approach reduces the number of transports required to 2= =0A= even in complex audio/video cases.=20 [BA] Wasn't sure if the "2" referred to here was one for audio and one for = video=2Cor one for RTP and another for RTCP. To clarify I might say "2 (on= e for audio and one for video=2C assuming rtcp mux)".=20 4.1. Negotiation of new or legacy behavior=0A= In order to know whether a given application supports Plan B=2C an=0A= attribute in the offer is needed. There are various options that=0A= could be used for this:=0A= =0A= o a=3Dssrc isn't enough=2C since you might not have any send streams=2C= =0A= and therefore no a=3Dssrc attributes.=0A= =0A= o a=3Dmax-*-ssrc could work=2C but has additional semantics=0A= =0A= o a=3Dmsid-semantic indicates that you understand MSIDs.=0A= =0A= Because understanding MSID is a prerequisite to using plan B=2C the=0A= third option (presence of a=3Dmsid-semantic) is recommended.=0A= [BA] I would suggest that max-*-ssrc is a better choice because there are = legacy scenarios where msid might not be present. 4.2. New signaling flow=0A= =0A= When both sides support Plan B=2C to properly allow both sides to=0A= indicate which MSTs they have=2C and allow the remote side to select=0A= the desired MSTs to receive=2C a 3-way handshake is needed (this is=0A= just math=3B the offer can't select the answerer's MSTs until they know= =0A= about them). =20 [BA] While I understand the argument for why you need two O/As for bothside= s to select the desired streams=2C I think that it's possible to designthe = exchange so that only one O/A is needed most of the time. The keyconcept i= s for the offer to contain information on what the offerer is capableof rec= eiving in addition to what it is capable of sending. Yes=2C anotherO/A mig= ht be needed if it turns out that the Offerer wants something differentthan= what the Answerer chose=2C but at least the first Answer is guaranteed tob= e acceptable to the Offerer.=20 That is=2C I believe we should think of the second O/A as an optional excha= ngethat hopefully won't be needed much of the time than as part of a "3-way= " or"4-way" handshake that will execute every time.=20 The expected flow for this would be for the caller to=0A= send an offer with its sources=2C then the callee would send back an=0A= answer with the sources it wants the caller to send=2C followed=0A= immediately by an offer with the sources that the callee has=0A= available to send. Finally=2C the answerer will reply back with the=0A= sources that it wants to request from the callee. The entire=0A= sequence can be done in 1.5 RTT. [BA] Why not add the info on what sources the callee has available to send = to the first Answer? If the Offer also contains the maximum number of recei= ved SSRCs=2C the Offerer should prepare to receive that many SSRCs=2C and t= he Answer could include up to that many sourcesas enabled and start sending= . That way=2C if the sources sent are OK with the Offerer then we don't = need anotherOffer/Answer exchange=2C because the Answerer has indicated wha= t sources it wants from the ones the Offerersaid it could send.=20 This assumes that the Offerer can handle incoming RTP streams up to the max= imum number of receive SSRCs before it receives the Answer which can explic= itly declare the SSRCs. =20 In addition=2C since the=0A= sources are known ahead of time by the recipient of said sources=2C it= =0A= is prepared to demux them by SSRC without any signaling/media race. [BA] If you don't make this a hard requirement=2C it seems like you could g= et by with a single O/A exchange much of the time.=20 4.3. Legacy signaling flow=0A= =0A= In the legacy case=2C Plan B degrades gracefully back to a single=0A= offer-answer sequence. Since there's no brokering of which sources=0A= should be sent=2C the "new" endpoint picks a default media source for=0A= each m=3D line=2C and upon receiving an answer indicating lack of suppor= t=0A= for Plan B=2C it sends just the default sources to the legacy endpoint.= =0A= When receiving media from the legacy endpoint=2C the new endpoint=0A= creates a "default" MediaStream (containing a single=0A= MediaStreamTrack) for each m=3D line=2C just as when talking to any othe= r=0A= legacy endpoint=2C as specified in the MSID draft. [BA] I'd claim that not only the "legacy" case but other cases as well can = behandled with a single O/A if you are prepared to handle more than one und= eclaredSSRC. Seems like a win to me.=20 = --_99b62df1-10d4-4679-9d7d-00cf5754d31f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
First some general comments:&nbs= p=3B

To some extent this document is arguing against a s= traw man (individual m=3D lines for RTP streams) that in its extreme case &= nbsp=3B(dozens of RTP streams=2C possibly with simulcast and layered coding= ) is quite impractical.  =3BAFAIK=2C many (if not the majority) of vide= o implementations have rejected that purist "Plan A" approach.  =3BSo t= o some extent=2C the document is beating a horse that is quite dead (or sho= uld be).  =3B To characterize that dead horse as "legacy" is a mistake = -- in fact legacy implementations are more sophisticated than that=2C and s= everal resemble Plan B in their approach=2C though not quite enough to avoi= d potential interoperability problems.  =3BMore later on how to get bet= ter
interoperability with legacy and also how to reduce the excha= nge to a single O/A in common cases. =3B

Secti= on 2.4

2.4.  Interworking=
 with legacy devices
=0A=
=0A=
   When interacting with a legacy application that only knows how to=0A=
   deal with a small number of sources=2C it must be possible to degrade=0A=
   gracefully to a usable basic experience=2C where at least a single=0A=
   audio and video source are active on each side=2C using a typical offer=
=0A=
   /answer exchange.
[BA] I would suggest t=
hat only being able to handle a single legacy stream is too
limiting.  It seems that it should be p=
ossible  to handle multiple undeclared SSRCs as long =3B
as it is assumed that they inherit = the parameters declared for the RTP session they are part of. =3B

2.1

   These layouts can c=
hange dynamically=2C depending on the conference=0A=
   content and the preferences of the receiver.  As such=2C there are not=
=0A=
   well-defined 'roles'=2C that could be used to group sources into=0A=
   specific 'large' or 'thumbnail' categories.  As such=2C the requirement=
=0A=
   Plan B attempts to satisfy is support for sending and receiving up to=0A=
   hundreds of simultaneous=2C hetereogeneous sources.=0A=


[BA] While I agree that =
the layouts can change dynamically=2C I am wondering if there is an implica=
tion that the burden of determining the 'roles' is on the mixer.  For examp=
le=2C it might be assumed that the mixer allocates an SSRC for the 'large' =
category=2C and other SSRCs for the 'thumbnails' and then these SSRCs are s=
tatically mapped to MSTs and rendered.  However=2C another way to handle it=
 is for the browser to handle the role assignment=2C and I would argue that=
 this could make more sense in some cases=2C particularly since this could =
make the mixer a lot simpler=2C or even obviate the need for a mixer entire=
ly (e.g. an RTP translator might work in some cases).







2.6. Simple binding of MediaStreamTrack to SDP

<= /span>=0A= =0A= In WebRTC=2C each media source is identified by a MediaStreamTrack=0A= object. In order to ensure that the MSTs created by the sender show=0A= up at the receiver=2C each MST's id attribute needs to be reflected in= =0A= SDP.

[BA] =3BWhile I might understan=
d why the MST ID might be useful to expose in the API=2C I don't see why th=
is needs to be signaled over the wire. In general=2C since WebRTC is su=
pposed to be "signaling independent"=2C we should try to avoid signali=
ng things that don't need to be signaled.  With respect to MST id=2C a numb=
er of approaches seem preferrable=2C including use of an RTP SDES item=2C o=
r (even better)
=
allowing the receiver to determine which MediaStreamTrack an incoming RTP s=
tream belongs to when the SSRC is first received.  


2.7.  Support for RTX=2C FEC=2C simulcast=2C layered coding
=0A=
=0A=
   For robust applications=2C techniques like RTX and FEC are used to=0A=
   protect media=2C and simulcast/layered coding can be used to provide=0A=
   support to hetereogeneous receivers.  It needs to be possible to=0A=
   support these techniques=2C allow the receipient to optionally use or=0A=
   not use them on a source-by-source basis=2C and for simulcast/layered=0A=
   scenarios=2C control which simulcast streams or layers are received.

[BA] In practice=2C control over simulcast str=
eams or layers is often left with the sender.  That is=2C a sender can dete=
rmine what simulcast stream or set of layers will go a particular receiver =
based on the RTCP feedback.  What the receiver needs to indicate is what it=
 is capable of receiving (e.g. "I can handle up to 4 temporal layers").  Wh=
ile I'm not against allowing a receiver to indicate what simulcast or layer=
ed streams it wants to receive=2C I don't think this is the most important =
use case.  In particular=2C assuming receiver-side control isn't compatible=
 with the sender-side congestion control most commonly used along with simu=
lcast/layered coding. 
=

Section 3.1

   By only using a m=3D line for each media type=
=2C as opposed to each media=0A=
   source=2C this approach reduces the number of transports required to 2=
=0A=
   even in complex audio/video cases. 

[BA]=
 Wasn't sure if the "2" referred to here was one for audio and one for vide=
o=2C
or one for RTP and =
another for RTCP.  To clarify I might say "2 (one for audio and one for vid=
eo=2C assuming rtcp mux)". 

4.1.  Negotiation of new or legacy behavior
=0A=
   In order to know whether a given application supports Plan B=2C an=0A=
   attribute in the offer is needed.  There are various options that=0A=
   could be used for this:=0A=
=0A=
   o  a=3Dssrc isn't enough=2C since you might not have any send streams=2C=
=0A=
      and therefore no a=3Dssrc attributes.=0A=
=0A=
   o  a=3Dmax-*-ssrc could work=2C but has additional semantics=0A=
=0A=
   o  a=3Dmsid-semantic indicates that you understand MSIDs.=0A=
=0A=
   Because understanding MSID is a prerequisite to using plan B=2C the=0A=
   third option (presence of a=3Dmsid-semantic) is recommended.=0A=



[BA]  I would suggest that =
max-*-ssrc is a better choice because there are legacy scenarios where msid=
 might not be present.
=

4.2.  New signaling flow
=0A=
=0A=
   When both sides support Plan B=2C to properly allow both sides to=0A=
   indicate which MSTs they have=2C and allow the remote side to select=0A=
   the desired MSTs to receive=2C a 3-way handshake is needed (this is=0A=
   just math=3B the offer can't select the answerer's MSTs until they know=
=0A=
   about them).  

[BA] While I understand t=
he argument for why you need two O/As for both
sides to select the desired streams=2C I think that =
it's possible to design
=
the exchange so that only one O/A is needed most of the time.  The key
concept is for the offer to =
contain information on what the offerer is capable
of receiving in addition to what it is capable o=
f sending.  Yes=2C another
O/A might be needed if it turns out that the Offerer wants something d=
ifferent
than what the A=
nswerer chose=2C but at least the first Answer is guaranteed to
be acceptable to the Offerer. 

That is=2C I believe we should think of the sec=
ond O/A as an optional exchange
that hopefully won't be needed much of the time than as part of a "=
3-way" or
"4-way" handsh=
ake that will execute every time. 

   The e=
xpected flow for this would be for the caller to=0A=
   send an offer with its sources=2C then the callee would send back an=0A=
   answer with the sources it wants the caller to send=2C followed=0A=
   immediately by an offer with the sources that the callee has=0A=
   available to send.  Finally=2C the answerer will reply back with the=0A=
   sources that it wants to request from the callee.  The entire=0A=
   sequence can be done in 1.5 RTT.

[BA] Wh=
y not add the info on what sources the callee has available to send to the =
first Answer? If the Offer also contains the maximum number of received SSR=
Cs=2C =3B
the Offerer =
should prepare to receive that many SSRCs=2C and the Answer could include u=
p to that many sources
as enabled and start sending.    That way=2C if the sources sent are O=
K with the Offerer then we don't need another
Offer/Answer exchange=2C because the Answerer ha=
s indicated what sources it wants from the ones the Offerer
said it could send. 

This assumes that the Offerer can handle in=
coming RTP streams up to the maximum number of receive SSRCs before it rece=
ives the Answer which can explicitly declare the SSRCs.  

   In addition=2C since the=0A=
   sources are known ahead of time by the recipient of said sources=2C it=
=0A=
   is prepared to demux them by SSRC without any signaling/media race.


[BA] If you don't make this a hard requirement=2C it seems like yo=
u could get by with a single O/A exchange much of the time. 

4.3.  Legacy signaling flow
=0A=
=0A=
   In the legacy case=2C Plan B degrades gracefully back to a single=0A=
   offer-answer sequence.  Since there's no brokering of which sources=0A=
   should be sent=2C the "new" endpoint picks a default media source for=0A=
   each m=3D line=2C and upon receiving an answer indicating lack of suppor=
t=0A=
   for Plan B=2C it sends just the default sources to the legacy endpoint.=
=0A=
   When receiving media from the legacy endpoint=2C the new endpoint=0A=
   creates a "default" MediaStream (containing a single=0A=
   MediaStreamTrack) for each m=3D line=2C just as when talking to any othe=
r=0A=
   legacy endpoint=2C as specified in the MSID draft.

[BA] I'd claim that not only the "legacy" case but other cases a=
s well can be
handled wi=
th a single O/A if you are prepared to handle more than one undeclared
SSRC.  Seems like a win to m=
e. 



=

=
= --_99b62df1-10d4-4679-9d7d-00cf5754d31f_-- From bernard_aboba@hotmail.com Sat May 11 20:17:46 2013 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 CD5A321F8976; Sat, 11 May 2013 20:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fVuT-+Wqy8K; Sat, 11 May 2013 20:17:41 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF121F8956; Sat, 11 May 2013 20:17:40 -0700 (PDT) Received: from BLU403-EAS154 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 May 2013 20:17:40 -0700 X-EIP: [7m7o79jdo00ApckqYG1RqbAfzGj/7BIo] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <518D6482.2010008@alum.mit.edu> Date: Sat, 11 May 2013 20:17:35 -0700 To: Paul Kyzivat X-OriginalArrivalTime: 12 May 2013 03:17:40.0567 (UTC) FILETIME=[42BC2670:01CE4EBF] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 03:17:46 -0000 PiBPbiA1LzEwLzEzIDI6MzcgQU0sIFN0ZWZhbiBIw6VrYW5zc29uIExLIHdyb3RlOg0KPj4gDQo+ PiANCj4+IEp1c3QgYXMgYW4gZXhhbXBsZSwgdGhpbmsgYWJvdXQgYSBjb25mZXJlbmNlIHNjZW5h cmlvIHdpdGggYSBjZW50cmFsaXplZA0KPj4gbm9kZS4gTm93LCBvbmUgb2YgdGhlIHBhcnRpY2lw YW50cyB3YW50cyB0byBtdXRlIGhlci9oaXMgYXVkaW8sIGFuZCBhcyBhDQo+PiByZXN1bHQgdGhl IGF1ZGlvIG0tbGluZSB3b3VsZCBnbyBmcm9tIHNlbmRyZWN2IHRvIHJlY3Zvbmx5LiBBdCByb3Vn aGx5DQo+PiB0aGUgc2FtZSB0aW1lIHRoZSBzZXJ2ZXIgd2FudHMgdG8gZGlzYWJsZSB0aGUgaGln aCByZXMgdmlkZW8gYW5kIGVuYWJsZQ0KPj4gdGhlIGxvdyByZXMgdmlkZW8gKGJlY2F1c2UgdGhp cyB1c2VyIHdpbGwgYmUgbW92ZWQsIGJhc2VkIGUuZy4gb24gdGhlDQo+PiByZWNlbnQgYXVkaW8g YWN0aXZpdHksIGZyb20gYmVpbmcgZGlzcGxheWVkIGluIHRoZSBtYWluIHZpZGVvIHdpbmRvdyB0 bw0KPj4gYmUgaW4gYSB0aHVtYm5haWwgb24gdGhlIHNjcmVlbiBvZiB0aGUgb3RoZXIgcGFydGlj aXBhbnRzIGluIHRoZQ0KPj4gY29uZmVyZW5jZSksIHNvIGl0IHdhbnRzIHRvIG1hbmlwdWxhdGUg dGhlIGRpcmVjdGlvbiBhdHRyaWJ1dGUgb2Ygb3RoZXINCj4+IG0tbGluZXMuDQo+PiANCj4+IFNv IHRoZXJlIHdvdWxkIGJlIHR3byBvZmZlcnMgc2VudCBhdCByb3VnaGx5IHRoZSBzYW1lIHRpbWUs IHdoaWNoIG1lYW5zDQo+PiB3ZSB3b3VsZCBoYXZlIGdsYXJlLg0KDQpUaGVyZSBhcmUgaW1wbGVt ZW50YXRpb25zIHdoZXJlIG5vIHNpZ25hbGxpbmcgaXMgcmVxdWlyZWQgZm9yIHRoZSBtaXhlciB0 byBnbyBmcm9tIGhpZ2ggcmVzIHRvIGxvd2VyIHJlcy4gRm9yIGV4YW1wbGUsIGlmIHRoZSByZWNl aXZlciBkZWNsYXJlcyB3aGF0IGl0IGNhbiByZWNlaXZlIGFuZCB0aGUgbWl4ZXIgc2VsZWN0cyB0 aGUgc2ltdWxjYXN0IHN0cmVhbSBmb3IgdGhhdCByZWNlaXZlciBiYXNlZCBvbiBjYXBhYmlsaXRp ZXMgYW5kIGNvbmRpdGlvbnMsIHdpdGggdGhlIHN0cmVhbSBwcm9wZXJ0aWVzIGRlY2xhcmVkIGlu IGJhbmQuICA= From emil@sip-communicator.org Sun May 12 02:39:10 2013 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 52F0921F8DD5 for ; Sun, 12 May 2013 02:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK2Eg1M1-K0E for ; Sun, 12 May 2013 02:39:09 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 74A8D21F88EA for ; Sun, 12 May 2013 02:39:08 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so2086592wib.1 for ; Sun, 12 May 2013 02:39:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=7w1vWomHsQ39A/aJ+O/21ndTCNXplhlhmEj83B9jNtc=; b=FR1/2dqrQhsCzMLPDMBwfva4zCSTwpJ4cWBkepizkb4tmANIULSbgexVfhQCRNEjH8 9ggw5u1gns1G/9DjcGf3gCSIXw3qOLGPGYo2t9/4UDhf4bnTZy5bVq7lstx5S5eFf3uW K5mrLu0DWzL7jPYIBfyMuouubc74bVQbOS9+lpsw6b6iG4YWjyq3YeumHdB8u8C2/598 YtcmJmywYkftY9VqK7KrXyKJ7AlQDAXAu6uNhE3rlUofZTq7vEr4OiNe+oVeCMd/NxpC XoVme1Hl+8GlPdR4mGcUpUnWALUCdMhVRqrYhBUYtZs8G/WNDBDnTH0m6oqOZ9miIkaS srRg== X-Received: by 10.181.12.14 with SMTP id em14mr12435962wid.18.1368351548244; Sun, 12 May 2013 02:39:08 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id i11sm8965430wiw.11.2013.05.12.02.39.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 02:39:07 -0700 (PDT) Message-ID: <518F6338.8070903@jitsi.org> Date: Sun, 12 May 2013 12:39:04 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> In-Reply-To: <518A304A.1030609@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkF2xdDswHiDM/7LdgAbhb6d1QunQWQrS2L4K+O2NXqMs9IOuRxPYFXY17H7aYXIaLxa4TW Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:39:10 -0000 Coming back to this for a sec: On 08.05.13, 14:00, Harald Alvestrand wrote: > To put a blunt point on it: Either send less than ~32 streams, or give > a=ssrc attributes. Wouldn't it make more sense to either send ~32 streams or you don't use bundle? If you run out of PTs for a single m-line then you may also reconsider use of rtcp-mux. It seems to me that the consequences of not using bundle in some specific scenarios, especially in cases where trickle ICE is also supported, are far lesser than requiring everyone to support pre-announcement of SSRCs. Emil -- https://jitsi.org From emil@sip-communicator.org Sun May 12 02:59:03 2013 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 225A921F8E49 for ; Sun, 12 May 2013 02:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZFZlbS+Sdjr for ; Sun, 12 May 2013 02:59:02 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 52E7521F8DD5 for ; Sun, 12 May 2013 02:59:02 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so5224173wgg.21 for ; Sun, 12 May 2013 02:59:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=spcMJ6czq/XoXifWLUW5x+p5FQBDUA2UL4JPZKzreFw=; b=OUWXH6PQWBGPGZEWtj0ln7X2cHQhmopB/PkMA8oE5Y4sXZ/r05FKx034YF60E/zF73 j+tB2jue6+He/Foo4Tq5cBsyldkg3Mi20bLmcodDOR6XO7RFnwTusZvn+SPs+6wCyHXB apSDD95qMya2NyWr7/IZGXl0J4EMXnAnoAMZqktysoIEADCYT5fHvww2wOv2BoPoitzT CdWT4B11LSX2ek2k5NNc3l2k2DxQ5wCw0XmZUBEz8Av4dazbvOG/Dzy4HeGxsEF9CXm1 D+M0pE9W3Es8Qs/Codf4C9qMXisTakRPeoQQMKz9kCx+x7wp9YpsKzuWDKTZKVbraCKv 5VTw== X-Received: by 10.194.62.233 with SMTP id b9mr33564926wjs.37.1368352741344; Sun, 12 May 2013 02:59:01 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id x13sm9156601wib.3.2013.05.12.02.58.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 02:59:00 -0700 (PDT) Message-ID: <518F67E1.3040205@jitsi.org> Date: Sun, 12 May 2013 12:58:57 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> In-Reply-To: <518E7700.1080906@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnDLsP9dapFAPSGPOCbLCJBdyEafNb7LaxutylShLBvirDDyXlxGCVNZpzO7g1pKRyp/Vhn Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:59:03 -0000 On 11.05.13, 19:51, Paul Kyzivat wrote: > I don't have a specific action to recommend here. This just seems like a > somewhat fundamental shift that out to be recognized. It probably isn't > just RTCWEB and CLUE, it is really related to more complex communication > scenarios. ISTM that CLUE is addressing this by building a layer on top > of O/A, while RTCWEB is *battling* with O/A. That's a nice way to put it. Interestingly the CLUE approach to take this out of O/A seems to be more in line with the RTCWEB paradigm than both Plan A or Plan B. The decision not to implement an official signalling RTCWEB protocol was taken very early in this working group and there was very strong consensus on the fact that imposing a specific signalling protocol would be incompatible with the web in general. Still, it seems to me that we are now trying to compensate for the lack of such a signalling protocol by piggybacking on top of O/A and SDP with things such as the possibility to turn off individual SSRCs. Why do we need these things? Aren't they better handled by the API? Emil -- https://jitsi.org From stefan.lk.hakansson@ericsson.com Sun May 12 03:37:48 2013 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 D383C21F8E49 for ; Sun, 12 May 2013 03:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-IlypItL7jb for ; Sun, 12 May 2013 03:37:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5B21F8D7A for ; Sun, 12 May 2013 03:37:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-b5-518f70f5b70d Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E0.AB.32006.5F07F815; Sun, 12 May 2013 12:37:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Sun, 12 May 2013 12:37:41 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] We are moving beyond the assumptions on which O/A is based Thread-Index: AQHOTmfKp+aMNtB83UWYNJIDUPiJsg== Date: Sun, 12 May 2013 10:37:40 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA0FB@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvre63gv5Ag5cHuC1WbDjAarH2Xzu7 A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx4VwjU8F/qYrup4uYGhjfinYxcnJICJhI rGv4zAZhi0lcuLceyObiEBI4zCix7uknJghnCaNE+/cNjCBVbAKBElv3LQCq4uAQEdCQmLRV DSTMLKAucWfxOXYQW1ggSOLLh6XMILaIQLDE5cMTGSFsPYmutmdgcRYBVYl3z9eDLeYV8JU4 8+UfO8SuNmaJk9ces4AkGIEu+n5qDRPEAnGJW0/mM0FcKiCxZM95ZghbVOLl43+sELaSxI8N l1gg6vUkbkydwgZha0ssW/iaGWKZoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMn vdxoEyMwGg5u+a26g/HOOZFDjNIcLErivMlcjYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GHNNNBQUXHfk/8metJUxdorR/durvk+4+7Ory/3J1Ft7dZs8HG7m9KW4cx254sC6rPzJ1pZS xfAfQXGGTziiDzJliT6J2nlYNXtjItul/f2vCmR2zfqmKTVpSZ6hyR+PqAMKT9cvtNq0Pf7R hU9C+Xont53zfSlwVmGtW26rcvOzaeJnj75Z4q/EUpyRaKjFXFScCACGz2UeVAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:37:49 -0000 On 5/11/13 6:51 PM, Paul Kyzivat wrote:=0A= > I found what Stefan said below to be interesting:=0A= >=0A= > On 5/11/13 8:20 AM, Stefan H=E5kansson LK wrote:=0A= >=0A= >> Absolutely. The API (as of now) is aligned towards sending media. You'd= =0A= >> construct a PC-stream containing PC-tracks which in turn corresponds to= =0A= >> microphones and cameras. If you want to send that PC-stream to a peer=0A= >> you do "addStream" with it on a PeerConnection. If you want to add or=0A= >> remove a PC-track, there are operations for that - and it would be=0A= >> reflected on the far end.=0A= >>=0A= >> The point is that the API is about sending - not about setting up a=0A= >> session with a certain amount of ougoing and incoming PC-tracks, and to= =0A= >> me that harmonizes very well with the handshake in=0A= >> draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media= =0A= >> A->B and B->A respectively. An additional benefit seems to be that those= =0A= >> two exchanges are somewhat independent and would not cause glare. This= =0A= >> is denoted as a 3-way handshake in the draft, that is a bit misleading= =0A= >> perhaps.=0A= >=0A= > A very similar situation holds for CLUE.=0A= >=0A= > Maybe this is a more fundamental change than we have been thinking.=0A= >=0A= > O/A works best when both sides have similar capabilities and desires.=0A= > (It makes sense to set up to receive what I hope to receive, because it= =0A= > is likely that you will want to send that.) It works poorly when you and= =0A= > I might have a highly eclectic set of stuff we could send, and=0A= > unpredictable interests for what we are interested in receiving.=0A= >=0A= > In clue we are addressing that by exchanging (in a separate channel)=0A= > advertisements of what the endpoints are willing to send, and only doing= =0A= > O/A to set up the media that is of interest.=0A= >=0A= > In rtcweb it isn't so structured, but I suspect something is happening=0A= > implicitly, though it may be more hard-wired per application.=0A= >=0A= > In clue we may still end up negotiating separate one-way streams in each= =0A= > direction, similar to what Stefan mentions below. With bundling there=0A= > isn't a big penalty for that (e.g., in ports and RTCP traffic) though=0A= > there is an extra O/A required.=0A= >=0A= > But for both RTCWEB and CLUE there are cases where we must negotiate=0A= > bidirectional streams for compatibility with legacy devices. So there=0A= > must be a way to do that.=0A= >=0A= > I don't have a specific action to recommend here. This just seems like a= =0A= > somewhat fundamental shift that out to be recognized. It probably isn't= =0A= > just RTCWEB and CLUE, it is really related to more complex communication= =0A= > scenarios. ISTM that CLUE is addressing this by building a layer on top= =0A= > of O/A, while RTCWEB is *battling* with O/A.=0A= =0A= I don't know much about Clue, but I find the above being a good summary =0A= for rtcweb, however I would perhaps say "application specific" rahter =0A= than "hard-wired per application"; and perhaps it is not a "battle" but =0A= rather "sorting out" that is ongoing regarding O/A.=0A= =0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From harald@alvestrand.no Sun May 12 04:58:37 2013 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 76A3D21F8E49 for ; Sun, 12 May 2013 04:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.741 X-Spam-Level: X-Spam-Status: No, score=-109.741 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkSt3xp8ZXIh for ; Sun, 12 May 2013 04:58:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4269021F8DA6 for ; Sun, 12 May 2013 04:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB63239E125; Sun, 12 May 2013 13:58:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YfuQpo7fE9j; Sun, 12 May 2013 13:58:30 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:11a7:a70e:3e57:aa15] (unknown [IPv6:2001:470:de0a:27:11a7:a70e:3e57:aa15]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F1F5339E070; Sun, 12 May 2013 13:58:29 +0200 (CEST) Message-ID: <518F83E5.4060209@alvestrand.no> Date: Sun, 12 May 2013 13:58:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> In-Reply-To: <518F6338.8070903@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:58:37 -0000 On 05/12/2013 11:39 AM, Emil Ivov wrote: > Coming back to this for a sec: > > On 08.05.13, 14:00, Harald Alvestrand wrote: >> To put a blunt point on it: Either send less than ~32 streams, or give >> a=ssrc attributes. > Wouldn't it make more sense to either send ~32 streams or you don't use > bundle? If you run out of PTs for a single m-line then you may also > reconsider use of rtcp-mux. So you're saying that when using 1-31 streams, we use a single port pair, but when we use 32 streams, we use 32 port pairs? I hadn't even considered the possibility of driving off that particular cliff at that boundary. > > It seems to me that the consequences of not using bundle in some > specific scenarios, especially in cases where trickle ICE is also > supported, are far lesser than requiring everyone to support > pre-announcement of SSRCs. Why? Remember: In Plan B, the only applications who have to support pre-announcement of SSRCs are those that want to send more than one media stream in a single RTP session. Any application that is satisfied with having mulitple RTP sessions corresponding to multiple M-lines can just signal as they're used to, without BUNDLE or SSRC signalling (although it will work a lot better if they use a=content consistently). Plan B is even compatible with folks that want to use BUNDLE, but are happy to let the recipient handle incoming SSRCs without knowing which one is which. That's not "everyone". > > Emil > > From emil@sip-communicator.org Sun May 12 06:00:54 2013 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 9E6BA21F859A for ; Sun, 12 May 2013 06:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bem9xDdQNcUa for ; Sun, 12 May 2013 06:00:54 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id A6FAA21F84F5 for ; Sun, 12 May 2013 06:00:53 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id j13so5650536wgh.16 for ; Sun, 12 May 2013 06:00:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=lzHWtr2Gg0o/z2gha/RGtWgy4aszdsDA8dEOIERPbro=; b=lnkD5EKZlsdWfJgzboLp+iQ6NaK9Tt2Cpsn76uoGt+BuToH4mg8NBcaWcdAhEhJtJM KB99LPW0w+0naxBb1LtAyeNBxG+xFqs/aN8ErsGqKk8Fh9FzhC+4db6AJNqQKSlniWYU dtIO6gmNqy5b6En/ftcfKFvhBuZ5PdVwUGTSfajYUBxlCMrAFGAr4aePKNs9zaL8jMS3 IhJn1+Q+18CT2M6d7/l327CtBSgy9J6vqmqPolQ78WvuZ0YAikC3YFYNG8sdB91z5eue Z+3gmEa2sG483HZzycKrs6CdWgBZ1WAQ5x+KMCVlud84djXmHey3n3lU4cvi5Vej22Js g59g== X-Received: by 10.180.76.103 with SMTP id j7mr13264028wiw.21.1368363652633; Sun, 12 May 2013 06:00:52 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id q13sm10098903wie.8.2013.05.12.06.00.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 06:00:51 -0700 (PDT) Message-ID: <518F9280.6070803@jitsi.org> Date: Sun, 12 May 2013 16:00:48 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> In-Reply-To: <518F83E5.4060209@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlUlj6irxoPBmkWyV+4NGiR1HYEhJREyWAloznbuLnst6OZBOT5VsVpjjKGhTh2fyS+cbsi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:00:54 -0000 On 12.05.13, 14:58, Harald Alvestrand wrote: > On 05/12/2013 11:39 AM, Emil Ivov wrote: >> Coming back to this for a sec: >> >> On 08.05.13, 14:00, Harald Alvestrand wrote: >>> To put a blunt point on it: Either send less than ~32 streams, or give >>> a=ssrc attributes. >> Wouldn't it make more sense to either send ~32 streams or you don't use >> bundle? If you run out of PTs for a single m-line then you may also >> reconsider use of rtcp-mux. > So you're saying that when using 1-31 streams, we use a single port > pair, but when we use 32 streams, we use 32 port pairs? Most certainly not! I am suggesting that if you fill up your PT space you could stop using bundle for your (presumably two, audio and video) m= lines. So rather than using a single port for RTP, you'll fall back to using two ports for audio and video. If you start lacking numbers again, you could consider turning off rtcp-mux which would again almost double your choices (presuming that you limited yourself to using the 96-127 range because you wanted to make rtcp demuxing easier). Just to clarify, I consider Plan B's use of m= lines (i.e. 1 m=line for many SSRCs) very natural and in-line with RTP design. I am not arguing against this. (I would actually strongly argue against the alternative). > I hadn't even considered the possibility of driving off that particular > cliff at that boundary. Fortunately I don't think anyone is. >> It seems to me that the consequences of not using bundle in some >> specific scenarios, especially in cases where trickle ICE is also >> supported, are far lesser than requiring everyone to support >> pre-announcement of SSRCs. > > Why? > > Remember: In Plan B, the only applications who have to support > pre-announcement of SSRCs are those that want to send more than one > media stream in a single RTP session. And it is exactly those applications that I am worried about. Imagine I am a conference focus that remotely controls an RTP translator. I would hence invite you with a single m= line for audio and a single m=line for video. On either of these you would end up getting a bunch of SSRCs for all the other participants. Or maybe you would just get one if the translator decides to mix rather than translate for some reason. Either way I can't send you all SSRCs in advance because there's know way for me to learn those of the other participants unless I use some unnecessary, unnecessarily complicated and unnecessarily time-consuming, signalling. > Any application that is satisfied with having mulitple RTP sessions > corresponding to multiple M-lines can just signal as they're used to, > without BUNDLE or SSRC signalling (although it will work a lot better if > they use a=content consistently). Again, that's not the kind of alternative that I was arguing for. Emil -- https://jitsi.org From harald@alvestrand.no Sun May 12 07:54:19 2013 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 DB34921F8D92 for ; Sun, 12 May 2013 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG6ieJNTss-5 for ; Sun, 12 May 2013 07:54:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7737D21F8D14 for ; Sun, 12 May 2013 07:54:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 482F339E125; Sun, 12 May 2013 16:54:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anrbdkN0QUvE; Sun, 12 May 2013 16:54:12 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:11a7:a70e:3e57:aa15] (unknown [IPv6:2001:470:de0a:27:11a7:a70e:3e57:aa15]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 186AB39E070; Sun, 12 May 2013 16:54:12 +0200 (CEST) Message-ID: <518FAD13.9050503@alvestrand.no> Date: Sun, 12 May 2013 16:54:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> In-Reply-To: <518F9280.6070803@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 14:54:20 -0000 On 05/12/2013 03:00 PM, Emil Ivov wrote: > On 12.05.13, 14:58, Harald Alvestrand wrote: >> On 05/12/2013 11:39 AM, Emil Ivov wrote: >>> Coming back to this for a sec: >>> >>> On 08.05.13, 14:00, Harald Alvestrand wrote: >>>> To put a blunt point on it: Either send less than ~32 streams, or give >>>> a=ssrc attributes. >>> Wouldn't it make more sense to either send ~32 streams or you don't use >>> bundle? If you run out of PTs for a single m-line then you may also >>> reconsider use of rtcp-mux. >> So you're saying that when using 1-31 streams, we use a single port >> pair, but when we use 32 streams, we use 32 port pairs? > Most certainly not! I am suggesting that if you fill up your PT space > you could stop using bundle for your (presumably two, audio and video) > m= lines. So rather than using a single port for RTP, you'll fall back > to using two ports for audio and video. Hmmm... how would you do that? Since you're using one M-line per video source (remember, this is plan A, not plan B), you're using the PT number for getting back to your M-line, which means that you're now creating more than one bundle, each bundle being limited to 32 PTs (and therefore 32 M-lines). Plan A is certainly creating an use case for more than one bundle, but it's still implying code that swings into action at the 32 track boundary, and is unused before that. > > If you start lacking numbers again, you could consider turning off > rtcp-mux which would again almost double your choices (presuming that > you limited yourself to using the 96-127 range because you wanted to > make rtcp demuxing easier). > > Just to clarify, I consider Plan B's use of m= lines (i.e. 1 m=line for > many SSRCs) very natural and in-line with RTP design. I am not arguing > against this. (I would actually strongly argue against the alternative). Thanks for the clarification! > >> I hadn't even considered the possibility of driving off that particular >> cliff at that boundary. > Fortunately I don't think anyone is. > >>> It seems to me that the consequences of not using bundle in some >>> specific scenarios, especially in cases where trickle ICE is also >>> supported, are far lesser than requiring everyone to support >>> pre-announcement of SSRCs. >> Why? >> >> Remember: In Plan B, the only applications who have to support >> pre-announcement of SSRCs are those that want to send more than one >> media stream in a single RTP session. > And it is exactly those applications that I am worried about. Imagine I > am a conference focus that remotely controls an RTP translator. I would > hence invite you with a single m= line for audio and a single m=line for > video. > > On either of these you would end up getting a bunch of SSRCs for all the > other participants. Or maybe you would just get one if the translator > decides to mix rather than translate for some reason. > > Either way I can't send you all SSRCs in advance because there's know > way for me to learn those of the other participants unless I use some > unnecessary, unnecessarily complicated and unnecessarily time-consuming, > signalling. Or you could signal none of them and depend on the fallback case in draft-ietf-mmusic-msid to handle them in a consistent manner, and use other methods to figure out how to handle them... > >> Any application that is satisfied with having mulitple RTP sessions >> corresponding to multiple M-lines can just signal as they're used to, >> without BUNDLE or SSRC signalling (although it will work a lot better if >> they use a=content consistently). > Again, that's not the kind of alternative that I was arguing for. > > Emil > > From emcho@sip-communicator.org Sun May 12 09:04:01 2013 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 9E82E21F8916 for ; Sun, 12 May 2013 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhhKDAJHk2xY for ; Sun, 12 May 2013 09:03:58 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7621F884F for ; Sun, 12 May 2013 09:03:57 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id k13so869123dae.34 for ; Sun, 12 May 2013 09:03:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=AUxqn5kdYXQMGXeAtI4fWzGXoF6WlsnF1WK8D+QAgu0=; b=gJacZnpEOikZ8SNIq16GVuA57qj1OBTix++CtGIcFQu5/4iqWIlBVGkexiX/bltlJw kkCDdu49pl9x38MxqpUVbKGFijUxEztRfBDLHvDSn/UTpjEZUy48bxb4sSaTU8yow8/6 fcYdBHxz5qcM6dup1rpBsFYi4fn+SekBkUdARDHV1fGI+2Y/MyX8AFqrqJYhA2iI7H6f HKFA1JKB5wTiGEVu8o27xKPdR53sRtjaUXz7yLuCd5wH1SRK+ZEVglIQDNRcJkimv/Jq EMJNQ3L9mwH4bWikGFtu9bPdVHREvJRtsPuGZwkXeMa8s47S1VoMqG1SdbBiPARPHmne 3BLA== X-Received: by 10.68.164.33 with SMTP id yn1mr25626122pbb.71.1368374637656; Sun, 12 May 2013 09:03:57 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx.google.com with ESMTPSA id fa5sm10543491pbb.35.2013.05.12.09.03.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 09:03:57 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj3so4037132pad.1 for ; Sun, 12 May 2013 09:03:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.6.168 with SMTP id c8mr5249858pba.184.1368374636337; Sun, 12 May 2013 09:03:56 -0700 (PDT) Received: by 10.66.229.68 with HTTP; Sun, 12 May 2013 09:03:56 -0700 (PDT) Received: by 10.66.229.68 with HTTP; Sun, 12 May 2013 09:03:56 -0700 (PDT) In-Reply-To: <518FAD13.9050503@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> Date: Sun, 12 May 2013 19:03:56 +0300 Message-ID: From: Emil Ivov To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec52156fd1e757d04dc878c17 X-Gm-Message-State: ALoCoQmIEC4Tag1ZyMMVW1sEjZLjbbiXaGFQungyYJUUOphMb+2HUq+PMokMy9JOSHGMS+EVlm9T Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:04:01 -0000 --bcaec52156fd1e757d04dc878c17 Content-Type: text/plain; charset=ISO-8859-1 On May 12, 2013 5:54 PM, "Harald Alvestrand" wrote: >>> So you're saying that when using 1-31 streams, we use a single port >>> pair, but when we use 32 streams, we use 32 port pairs? >> >> Most certainly not! I am suggesting that if you fill up your PT space >> you could stop using bundle for your (presumably two, audio and video) >> m= lines. So rather than using a single port for RTP, you'll fall back >> to using two ports for audio and video. > > Hmmm... how would you do that? Since you're using one M-line per > video source No, I am not. I am using one m= line for many video sources. > (remember, this is plan A, not plan B), Correct, and again I am not talking about plan A. > you're using the PT > number for getting back to your M-line, which means that you're now > creating more than one bundle, each bundle being limited to 32 PTs > (and therefore 32 M-lines). My point was NOT to use bundle in case PTs are insufficient. So in most cases you'd have one m= line for video (with as many sources as you wish) and one for audio. >> If you start lacking numbers again, you could consider turning off >> rtcp-mux which would again almost double your choices (presuming that >> you limited yourself to using the 96-127 range because you wanted to >> make rtcp demuxing easier). >> >> Just to clarify, I consider Plan B's use of m= lines (i.e. 1 m=line for >> many SSRCs) very natural and in-line with RTP design. I am not arguing >> against this. (I would actually strongly argue against the alternative). > > Thanks for the clarification! >>>> It seems to me that the consequences of not using bundle in some >>>> specific scenarios, especially in cases where trickle ICE is also >>>> supported, are far lesser than requiring everyone to support >>>> pre-announcement of SSRCs. >>> >>> Why? >>> >>> Remember: In Plan B, the only applications who have to support >>> pre-announcement of SSRCs are those that want to send more than one >>> media stream in a single RTP session. >> >> And it is exactly those applications that I am worried about. Imagine I >> am a conference focus that remotely controls an RTP translator. I would >> hence invite you with a single m= line for audio and a single m=line for >> video. >> >> On either of these you would end up getting a bunch of SSRCs for all the >> other participants. Or maybe you would just get one if the translator >> decides to mix rather than translate for some reason. >> >> Either way I can't send you all SSRCs in advance because there's know >> way for me to learn those of the other participants unless I use some >> unnecessary, unnecessarily complicated and unnecessarily time-consuming, >> signalling. > > > Or you could signal none of them and depend on the fallback case in > draft-ietf-mmusic-msid to handle them in a consistent manner, and > use other methods to figure out how to handle them... If you are referring to section 4.1 that you also pasted earlier in this thread, it only talks about one track, per stream, per m= line. This doesn't cover the conferencing case I described in my previous mail (quoted above). Cheers, Emil --sent from my mobile > > >> >>> Any application that is satisfied with having mulitple RTP sessions >>> corresponding to multiple M-lines can just signal as they're used to, >>> without BUNDLE or SSRC signalling (although it will work a lot better if >>> they use a=content consistently). >> >> Again, that's not the kind of alternative that I was arguing for. >> >> Emil >> >> > --bcaec52156fd1e757d04dc878c17 Content-Type: text/html; charset=ISO-8859-1


On May 12, 2013 5:54 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>>> So you're saying that when using 1-31 streams, we use a single port
>>> pair, but when we use 32 streams, we use 32 port pairs?
>>
>> Most certainly not! I am suggesting that if you fill up your PT space
>> you could stop using bundle for your (presumably two, audio and video)
>> m= lines. So rather than using a single port for RTP, you'll fall back
>> to using two ports for audio and video.
>
> Hmmm... how would you do that? Since you're using one M-line per
> video source

No, I am not. I am using one m= line for many video sources.

> (remember, this is plan A, not plan B),

Correct, and again I am not talking about plan A.

> you're using the PT
> number for getting back to your M-line, which means that you're now
> creating more than one bundle, each bundle being limited to 32 PTs
> (and therefore 32 M-lines).

My point was NOT to use bundle in case PTs are insufficient. So in most cases you'd have one m= line for video (with as many sources as you wish) and one for audio.

>> If you start lacking numbers again, you could consider turning off
>> rtcp-mux which would again almost double your choices (presuming that
>> you limited yourself to using the 96-127 range because you wanted to
>> make rtcp demuxing easier).
>>
>> Just to clarify, I consider Plan B's use of m= lines (i.e. 1 m=line for
>> many SSRCs) very natural and in-line with RTP design. I am not arguing
>> against this. (I would actually strongly argue against the alternative).
>
> Thanks for the clarification!

>>>> It seems to me that the consequences of not using bundle in some
>>>> specific scenarios, especially in cases where trickle ICE is also
>>>> supported, are far lesser than requiring everyone to support
>>>> pre-announcement of SSRCs.
>>>
>>> Why?
>>>
>>> Remember: In Plan B, the only applications who have to support
>>> pre-announcement of SSRCs are those that want to send more than one
>>> media stream in a single RTP session.
>>
>> And it is exactly those applications that I am worried about. Imagine I
>> am a conference focus that remotely controls an RTP translator. I would
>> hence invite you with a single m= line for audio and a single m=line for
>> video.
>>
>> On either of these you would end up getting a bunch of SSRCs for all the
>> other participants. Or maybe you would just get one if the translator
>> decides to mix rather than translate for some reason.
>>
>> Either way I can't send you all SSRCs in advance because there's know
>> way for me to learn those of the other participants unless I use some
>> unnecessary, unnecessarily complicated and unnecessarily time-consuming,
>> signalling.
>
>
> Or you could signal none of them and depend on the fallback case in
> draft-ietf-mmusic-msid to handle them in a consistent manner, and
> use other methods to figure out how to handle them...

If you are referring to section 4.1 that you also pasted earlier in this thread, it only talks about one track, per stream, per m= line. This doesn't cover the conferencing case I described in my previous mail (quoted above).

Cheers,
Emil

--sent from my mobile

>
>
>>
>>> Any application that is satisfied with having mulitple RTP sessions
>>> corresponding to multiple M-lines can just signal as they're used to,
>>> without BUNDLE or SSRC signalling (although it will work a lot better if
>>> they use a=content consistently).
>>
>> Again, that's not the kind of alternative that I was arguing for.
>>
>> Emil
>>
>>
>

--bcaec52156fd1e757d04dc878c17-- From stefan.lk.hakansson@ericsson.com Sun May 12 10:05:10 2013 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 4729F21F8709 for ; Sun, 12 May 2013 10:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTJo-C0nb2rh for ; Sun, 12 May 2013 10:05:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C70421F8700 for ; Sun, 12 May 2013 10:05:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-03-518fcbbe07a4 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 65.B6.28165.EBBCF815; Sun, 12 May 2013 19:05:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sun, 12 May 2013 19:05:01 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Eric Rescorla Thread-Topic: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOTa514PcF8tvBwUOl8gWNxiH9Cw== Date: Sun, 12 May 2013 17:05:01 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA1C9@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@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.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre6+0/2BBvdbZS1WvD7HbvFh/Q9G i7X/2tkdmD2WLPnJ5HH5/EdGj8mP25gDmKO4bFJSczLLUov07RK4Mvbc/stUsI+94tz52gbG P6xdjJwcEgImEnuOHWOCsMUkLtxbzwZiCwkcZpS48zmpi5ELyF7CKLH9yDRGkASbQKDE1n0L wIpEBBQkfv05wdLFyMHBLOAhcXtZMkhYWCBE4sjfGewQJaESV/veQtl6EvMOrGUGsVkEVCXa 7n8HG8Mr4CuxtX0OC8Su1cwSU7b9BEswAh30/dQasOOYBcQlbj2ZD3WogMSSPeeZIWxRiZeP /0E9oyTxY8MlFoh6PYkbU6ewQdjaEssWvmaGWCYocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCy rGJkz03MzEkvN9zECIyOg1t+6+5gPHVO5BCjNAeLkjhvEldjoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbGyiCPtP7z718I5k9yOaV7ulyucdIcjv9tzsU8zvNuLhVg/2U/37bqsdmHzYLx XIvMUw8vnHlLh3XTpvxN+bIv/9f9yFdN2j/zV/vr+197V8hEn/jRlpHx97e+jpKbusfmjJeP Xp6vTfHWrVXbcZvvePQDbzbzmbYLld81u9dJ7PoeddLAImCpEktxRqKhFnNRcSIAX8Cmj1wC AAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:05:10 -0000 On 5/11/13 4:14 PM, Eric Rescorla wrote:=0A= >=0A= >=0A= > On Sat, May 11, 2013 at 5:20 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > As I read draft-uberti-rtcweb-plan-00, no API changes are needed or= =0A= > proposed, and the call flows could stay the same (but as I recollect = the=0A= > discussion at the Boston interim they should be changed for other=0A= > reasons).=0A= >=0A= >=0A= > I wanted to address this point in isolation...=0A= >=0A= > I believe that both Plan A and Plan B require at least one change to=0A= > the API: the ability to indicate that a stream is important and thus=0A= > requires backward-compatible treatment. In Plan A this means=0A= > not marking it bundle-only. In Plan B it means putting it on its own=0A= > m-line.=0A= =0A= I think you're right. Stefan=0A= =0A= >=0A= > -Ekr=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Sun May 12 10:18:33 2013 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 64E0521F89C3; Sun, 12 May 2013 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiPUjp1H-B3P; Sun, 12 May 2013 10:18:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D09421F87B1; Sun, 12 May 2013 10:18:26 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-85-518fcee0e173 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A0.D6.01956.0EECF815; Sun, 12 May 2013 19:18:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Sun, 12 May 2013 19:18:23 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w== Date: Sun, 12 May 2013 17:18:23 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvre7Dc/2BBpNusVns+buI3WLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXxscDF1kK9ohX HL69n72B8YFQFyMnh4SAicSJvgZ2CFtM4sK99WxdjFwcQgKHGSXaV35lgXCWMErsur8GrIpN IFBi674FQFUcHCICGhKTtqqBmMwCuRJfpgWAVAgLeEts27CQGcQWEfCRWH/zEDuErSfR0ruF FcRmEVCVeDHlFwuIzSvgK9G75wkzxKo/TBJTV1wBSzACHfT91BomEJtZQFzi1pP5TBCHCkgs 2XOeGcIWlXj5+B8rhK0k0bjkCStEvZ7EjalT2CBsbYllC18zQywTlDg58wnLBEbRWUjGzkLS MgtJyywkLQsYWVYxsucmZuakl5tvYgRGysEtvw12MG66L3aIUZqDRUmcN5mrMVBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QD45ElIffzDFW9dpk9L163UCD8w9Mezgibit+RUZK7q358WvXm xKtzh1603bJimBlnUblbsjl48gGD3L/af+SvOzSul/3x7GpGrQOb+7dE0/r8vpdqpxcpz75b bFg1RSZt87lbySobTuQv5Qr+n/Q/P6Qw6HAE487g3c2FHOtY0qY0WlaIfpU9rMRSnJFoqMVc VJwIAJEdk61iAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:18:33 -0000 On 5/11/13 6:24 PM, Paul Kyzivat wrote:=0A= > On 5/11/13 7:50 AM, Stefan H=E5kansson LK wrote:=0A= >> On 5/10/13 11:20 PM, Paul Kyzivat wrote:=0A= >=0A= >>> What is the probability that the other side, for independent reasons,= =0A= >>> decides to make a change within that interval? (And it isn't really the= =0A= >>> whole interval - it is only the first part of it.)=0A= >>=0A= >> Given that in multiparty services the "main" video changes quite often,= =0A= >> I'd not say this is extremely low. It will happen.=0A= >=0A= > Are you thinking that there will be an SDP change every time the speaker= =0A= > changes???=0A= >=0A= > Or do you mean changes when participants join and leave a conference?=0A= =0A= I meant the former (at speaker change).=0A= =0A= I guess that different designs can be chosen for media from central node = =0A= to end-user clients, and some of them (as Bernard pointed out) would not = =0A= require any signaling. Still, there might be cases where signaling is =0A= needed.=0A= =0A= But leaving that aside, we still have the case of the media end-user =0A= client -> central node. If you're serious about not wasting bandwidth =0A= (and with my radio/mobile background I am sort of obsessed :-) ) all =0A= end-user clients which do not end up as main video anywhere should only =0A= transmit a low resolution video. So at every speaker change there would =0A= be at least one client that is asked to stop sending high resolution and = =0A= only transmit low resolution, and one client that is asked to start =0A= transmitting high resolution video.=0A= =0A= I think that this would best be done using some RTCP signaling scheme, =0A= but I also think there was an agreement a long time ago that SDP O/A =0A= should be used. In this case either to transmit a new imageattr value =0A= requesting another resolution, or to pause/resume - using recv on/off in = =0A= Plan B or the direction attribute in Plan A - the low and high =0A= resolution simulcast streams accordingly (or I assume to pause/resume =0A= the enhancement layers if a scalable codec is used).=0A= =0A= >=0A= > I would hope there will normally not be SDP changes for either of those= =0A= > events.=0A= =0A= I would like to avoid them too, but I'm not sure how.=0A= =0A= >=0A= >> But, given that there is a way to roll-back in a predictable way I think= =0A= >> glare resolution could be quick - nothing stops the web application from= =0A= >> including a random number in every offer, and resolve glare based on=0A= >> that (one of the offers "win").=0A= >>=0A= >> So I think glare will happen in practice (that is what I wanted to point= =0A= >> out), but it is not a show-stopper provided there is a way to roll back.= =0A= >=0A= > I'm sure it will happen. The question is whether it happens often enough= =0A= > to do more than count on the normal glare recovery procedures.=0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= >=0A= =0A= From emcho@sip-communicator.org Sun May 12 11:29:12 2013 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 B4EDA21F8BB7 for ; Sun, 12 May 2013 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkXD+WGsOvMs for ; Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DC0D921F8797 for ; Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz17so3932414pbc.3 for ; Sun, 12 May 2013 11:29:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7gkTSk+96Pf79o0bHvtoQjoAuejxtwvY7WTKpfeK5jo=; b=Ax/ULnCVR8sdVFSLa5CMs53Zzx7bJD7O61G2QKA9m3HtA8s34PEXJ1HhJkay5n+0PQ F8rw+9wCZAhj3Iua8BEQBIZbJaiIJ8ibsmpFmstKHPQTlHI8A7e9WEpMvQgXc7eE2FAq 9+wM5zuiVW9MUBP5E4WTem4oUltwcuagl51dwtFOJQqYiGgMjjrwAQ0qFlb5kZcvuHU8 y/vX3U9wxcqEfveZ/1svh7Sk1Sk7gKnIdlhv48y9bZt9mFZVZCu4P5kBTzrE9u+Z9kuv Km6P1oWGmzWLoKx+rZBBh0IOJ+vQQMmtXra66sJ4f1hcnvh9b50+IRzRKWJik9+LTayj XXyw== X-Received: by 10.68.44.169 with SMTP id f9mr25849908pbm.29.1368383351476; Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx.google.com with ESMTPSA id br2sm10876513pbc.46.2013.05.12.11.29.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa10so4054099pad.5 for ; Sun, 12 May 2013 11:29:10 -0700 (PDT) X-Received: by 10.66.216.198 with SMTP id os6mr26211752pac.145.1368383350836; Sun, 12 May 2013 11:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.229.68 with HTTP; Sun, 12 May 2013 11:28:50 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> From: Emil Ivov Date: Sun, 12 May 2013 21:28:50 +0300 Message-ID: To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlZrVgNjRIZMzT1TZ5R23ww//lp5GMBqB2MBeGahfL8Q7qAPimaLNdFZ+762tnR9B07pGzA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:29:12 -0000 On Sun, May 12, 2013 at 8:18 PM, Stefan H=E5kansson LK wrote: > On 5/11/13 6:24 PM, Paul Kyzivat wrote: >> On 5/11/13 7:50 AM, Stefan H=E5kansson LK wrote: >>> On 5/10/13 11:20 PM, Paul Kyzivat wrote: >> >>>> What is the probability that the other side, for independent reasons, >>>> decides to make a change within that interval? (And it isn't really th= e >>>> whole interval - it is only the first part of it.) >>> >>> Given that in multiparty services the "main" video changes quite often, >>> I'd not say this is extremely low. It will happen. >> >> Are you thinking that there will be an SDP change every time the speaker >> changes??? >> >> Or do you mean changes when participants join and leave a conference? > > I meant the former (at speaker change). > > I guess that different designs can be chosen for media from central node > to end-user clients, and some of them (as Bernard pointed out) would not > require any signaling. Still, there might be cases where signaling is > needed. Right, however in cases where signalling is indeed needed, should it really be defined by RTCWEB rather than the application developer? > But leaving that aside, we still have the case of the media end-user > client -> central node. If you're serious about not wasting bandwidth > (and with my radio/mobile background I am sort of obsessed :-) ) all > end-user clients which do not end up as main video anywhere should only > transmit a low resolution video. So at every speaker change there would > be at least one client that is asked to stop sending high resolution and > only transmit low resolution, and one client that is asked to start > transmitting high resolution video. > > I think that this would best be done using some RTCP signaling scheme, RTCP is just one of the possibilities. This could also be implemented in a number of other ways that would all be more efficient for the specific application and all out-of-scope for rtcweb. > but I also think there was an agreement a long time ago that SDP O/A > should be used. Well the way I remember it SDP O/A was chosen for session negotiation and that other forms of signalling were explicitly left out of the charter. > In this case either to transmit a new imageattr value imageattr is great as a declarative parameter indicating capabilities: "I can't show more than 720p so there's no point to send me more than that". Using it as a way to switch between thumbnail and HQ videos is not entire impossible but is not particularly efficient either. > requesting another resolution, or to pause/resume - using recv on/off in > Plan B or the direction attribute in Plan A - the low and high > resolution simulcast streams accordingly (or I assume to pause/resume > the enhancement layers if a scalable codec is used). > >> >> I would hope there will normally not be SDP changes for either of those >> events. > > I would like to avoid them too, but I'm not sure how. Well we can either figure that out (and it seems that we can't quite agree on a solution) or make sure APIs have all it takes for the matter to be resolved by app-to-app signalling. Emil -- https://jitsi.org From harald@alvestrand.no Sun May 12 12:55:34 2013 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 ABD2921F89AF for ; Sun, 12 May 2013 12:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.265 X-Spam-Level: X-Spam-Status: No, score=-110.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvIhfh3wrVol for ; Sun, 12 May 2013 12:55:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03A21F8BBA for ; Sun, 12 May 2013 12:55:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1926B39E125; Sun, 12 May 2013 21:55:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4zPWBoMaCIu; Sun, 12 May 2013 21:55:27 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:11a7:a70e:3e57:aa15] (unknown [IPv6:2001:470:de0a:27:11a7:a70e:3e57:aa15]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 488CD39E070; Sun, 12 May 2013 21:55:27 +0200 (CEST) Message-ID: <518FF3AE.4050505@alvestrand.no> Date: Sun, 12 May 2013 21:55:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:55:34 -0000 On 05/12/2013 06:03 PM, Emil Ivov wrote: > > > Or you could signal none of them and depend on the fallback case in > > draft-ietf-mmusic-msid to handle them in a consistent manner, and > > use other methods to figure out how to handle them... > > If you are referring to section 4.1 that you also pasted earlier in > this thread, it only talks about one track, per stream, per m= line. > This doesn't cover the conferencing case I described in my previous > mail (quoted above). > Changing subject as I'm replying to a subtopic, and because I was misunderstanding what Emil was arguing in favour of..... when I wrote that text, I didn't intend it to cover only one SSRC per stream. What I intended to say was that when, in an RTP session, a browser gets several SSRCs that were not mentioned in signalling, it will send several onaddstream signals to the application, each indicating a new stream being added, which has exactly one track. If the language doesn't say that, I need to change it. (One reason why I changed this from the version with just a single stream with one track per unknown SSRC was that there's no way to know the desired synchronization properties of the stream before one sees the CNAME of the stream - which may be at an arbitrary time after the first packet.) From rmohanr@cisco.com Sun May 12 21:16:57 2013 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 7FEA521F8AD1 for ; Sun, 12 May 2013 21:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qiHxBzX2EOJ for ; Sun, 12 May 2013 21:16:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CD21F8A7B for ; Sun, 12 May 2013 21:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1133; q=dns/txt; s=iport; t=1368418612; x=1369628212; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PgqH7MSdaX4t0gFlNVhXJ4zcvi9JsDooLBavFsKifv0=; b=CbS25djtkrZiHFEMdNkUy5LBd+s8+D5Zbdpcp4BnoxXhNnzrFEfVNYlq zxvvcmDnbZeDRJzDQS4EheVt/Rvh8vKk0iRf67bKOuLmFWxtU9BX/82da 2I28GttdV0sjQTcLYtqcx2jKNaf5Sogv4op5GYhtCek5SBADUohE9xLt8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FACRokFGtJXHA/2dsb2JhbABagwc3RL9igQMWbQeCHwEBAQMBOj0HDQEIIhRCGwEGAwIEEwgBh30GBwWcHZ8Njnc4gnRhA5hSkA+DD4In X-IronPort-AV: E=Sophos;i="4.87,659,1363132800"; d="scan'208";a="209372343" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 13 May 2013 04:16:51 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4D4GpxW023782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 May 2013 04:16:51 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.52]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Sun, 12 May 2013 23:16:50 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-reddy-rtcweb-mobile-03.txt Thread-Index: AQHOTM8DYyP2rg0b/ka4JmWBVxuLyZkDOKYA Date: Mon, 13 May 2013 04:16:49 +0000 Message-ID: In-Reply-To: <20130509160511.5457.86755.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 04:16:57 -0000 We have publish a new revision of draft-reddy-rtcweb-mobile by addressing the comments received so far. Please review and provide your comments Regards, Authors > On 09/05/13 9:35 PM, "internet-drafts@ietf.org" > wrote: > >A new version of I-D, draft-reddy-rtcweb-mobile-03.txt >has been successfully submitted by Tirumaleswar Reddy and posted to the >IETF repository. > >Filename: draft-reddy-rtcweb-mobile >Revision: 03 >Title: Considerations with WebRTC in Mobile Networks >Creation date: 2013-05-09 >Group: Individual Submission >Number of pages: 16 >URL: =20 >http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-mobile-03.txt >Status: http://datatracker.ietf.org/doc/draft-reddy-rtcweb-mobile >Htmlized: http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-03 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-rtcweb-mobile-03 > >Abstract: > This document discusses some of the issues with WebRTC applications > in Mobile Networks. > > =20 > =20 > > >The IETF Secretariat > > From juberti@google.com Sun May 12 22:22:36 2013 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 E380021F8F4F for ; Sun, 12 May 2013 22:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.478 X-Spam-Level: X-Spam-Status: No, score=-98.478 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87uu6cxPbufR for ; Sun, 12 May 2013 22:22:35 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CD29921F8F43 for ; Sun, 12 May 2013 22:22:31 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id z10so3191264qcx.28 for ; Sun, 12 May 2013 22:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0ve1R+FQMWCCG153/L/7RqLO3/ynfY4vAd4Hlsp9YoU=; b=etC4hwJ3KodurgKoMf8TZCmmPbfpc8BzTSNRpz6gwSGMpt2PFtjAMPw1oNtJDrCpcw C2rKXi06adZcJ2PkT4PjqpI3Jv64FuJkPVHsL1DGIvSy0NACoPJJXNYX8scTegTE+oak mDRt8e1mJCpdlS+UtEARPG4zSvvCey99+Eo+5/tzmtoIhW7ZiUnNSbxuzaR9kPu+F7x0 c/84G7/XOfocgsrAXfTuBJleHCrg4QCzBz0XP6rLhNX1TUWK8KL82jT/uYZPn+XwqGe+ 2tZ1Te/5j6tcLrhtqEqki897eIkV+/RqZBoh0VSdI7iCllrrpr+bPcJcgAen6EmxEIRw 4eKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=0ve1R+FQMWCCG153/L/7RqLO3/ynfY4vAd4Hlsp9YoU=; b=T3BMwLV89hWdVVoVRAfIs6Zs73Aj93oC7xKK+gJ3rKZmAGB9cHhfnG3aIIOEMHjSfy 9YaKMubEzGT+ysiQKxOaRmV0kaQWs0uPh4ANBIYrWwgI32jaNFHgZt4CsUZPy3CYZRRb eTWXKHRoQrAGfhR+01tKhB3LGu50+Q6f4Xo8h0nDPtp+SbwfbAKRZJbiol13ASTmcnYw 3sToZndbV58WxjHy385OGIM9Wrq/eLzANOR+pv+jc7e1WlCwakhM8SbJ6NYtM/MRIZxf gLBZEiE/UF2/H+2hjHvfGaPmtBKok7nQBBpSxOk7vlIbHFlSbBqwaSLyTvxKIIZ4rnNm 4R5w== X-Received: by 10.49.71.165 with SMTP id w5mr22226596qeu.36.1368422541915; Sun, 12 May 2013 22:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.133 with HTTP; Sun, 12 May 2013 22:22:01 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 12 May 2013 22:22:01 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=047d7b5dbdcc83b90004dc92b38a X-Gm-Message-State: ALoCoQm1NnHaptDp/bwh4YCjSjorHXgpCkQWbhmTBJ/dRoVqsqbthBPIjHWl1HJ1mObjKye/3B1TFuOJZv4aSNka//QYcrXU2lF8hP5vRVwdYnqMaOb1a/NspbgBf8c2PjH/LhADY1qmcahiP/zYPBWgV+XpCyuxUQZMnr40k2DThvsMUEdviQu6iaJMGOWIdzjJngLNDtxw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 05:22:36 -0000 --047d7b5dbdcc83b90004dc92b38a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, May 11, 2013 at 5:20 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 5/10/13 8:44 PM, Cullen Jennings wrote: > > > > On May 8, 2013, at 2:52 AM, Stefan H=C3=A5kansson LK > > wrote: > > > >> * The (3-way) handshake is well aligned with the API (where the > >> sending app initiates the sending of media) > > > > Interesting - I saw it sort of the opposite so perhaps you can you > > say some more. > > Absolutely. The API (as of now) is aligned towards sending media. You'd > construct a PC-stream containing PC-tracks which in turn corresponds to > microphones and cameras. If you want to send that PC-stream to a peer > you do "addStream" with it on a PeerConnection. If you want to add or > remove a PC-track, there are operations for that - and it would be > reflected on the far end. > > The point is that the API is about sending - not about setting up a > session with a certain amount of ougoing and incoming PC-tracks, and to > me that harmonizes very well with the handshake in > draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media > A->B and B->A respectively. An additional benefit seems to be that those > two exchanges are somewhat independent and would not cause glare. This > is denoted as a 3-way handshake in the draft, that is a bit misleading > perhaps. > > I think this is actually proposed in the JSEP draft as well, look at the > second part of > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.2.3.1 > > > > I saw this as a complete change to everything we had > > discussed up to this point in how the API would work and how it would > > interact with Offer/Answer. I figured dealing with this change would > > set back the W3C API work over 8 months so this is good news if you > > see a way that it is the well alighted. Can you explain how it lines > > up with the current drafts, call flows, existing example > > applications, and APIs that are all based on a 2 way hand shake? > > As I read draft-uberti-rtcweb-plan-00, no API changes are needed or > proposed, and the call flows could stay the same (but as I recollect the > discussion at the Boston interim they should be changed for other reasons= ). > > The sole API change that is proposed is the new .content property, to allow a MST to have its a=3Dcontent property set, and as such be placed on its own m=3D line. The rest works using the existing APIs; the necessary a=3Dremote-ssrc lines can be generated (to enable or disable a stream) base= d on whether a received MST is hooked up to an output or not. --047d7b5dbdcc83b90004dc92b38a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, May 11, 2013 at 5:20 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 5/10/13 8:44 PM, Cullen= Jennings wrote:
>
> On May 8, 2013, at 2:52 AM, Stefan H=C3=A5kansson LK
> <stefan.lk.haka= nsson@ericsson.com> wrote:
>
>> * The (3-way) handshake is well aligned with the API (where the >> sending app initiates the sending of media)
>
> Interesting - I saw it sort of the opposite so perhaps you can you
> say some more.

Absolutely. The API (as of now) is aligned towards sending media. You= 'd
construct a PC-stream containing PC-tracks which in turn corresponds to
microphones and cameras. If you want to send that PC-stream to a peer
you do "addStream" with it on a PeerConnection. If you want to ad= d or
remove a PC-track, there are operations for that - and it would be
reflected on the far end.

The point is that the API is about sending - not about setting up a
session with a certain amount of ougoing and incoming PC-tracks, and to
me that harmonizes very well with the handshake in
draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media
A->B and B->A respectively. An additional benefit seems to be that th= ose
two exchanges are somewhat independent and would not cause glare. This
is denoted as a 3-way handshake in the draft, that is a bit misleading
perhaps.

I think this is actually proposed in the JSEP draft as well, look at the second part of
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-0= 3#section-4.2.3.1=C2=A0



> I saw this as a complete change to everything we had
> discussed up to this point in how the API would work and how it would<= br> > interact with Offer/Answer. I figured dealing with this change would > set =C2=A0back the W3C API work over 8 months so this is good news if = you
> see a way that it is the well alighted. Can you explain how it lines > up with the current drafts, call flows, existing example
> applications, and APIs that are all based on a 2 way hand shake?

As I read draft-uberti-rtcweb-plan-00, no API changes are needed or proposed, and the call flows could stay the same (but as I recollect the discussion at the Boston interim they should be changed for other reasons).=

The sole API change that is proposed is the new .content property, to = allow a MST to have its a=3Dcontent property set, and as such be placed on = its own m=3D line. The rest works using the existing APIs; the necessary a= =3Dremote-ssrc lines can be generated (to enable or disable a stream) based= on whether a received MST is hooked up to an output or not.=C2=A0
--047d7b5dbdcc83b90004dc92b38a-- From stefan.lk.hakansson@ericsson.com Mon May 13 00:21:56 2013 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 6925221F923C; Mon, 13 May 2013 00:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ybvIUaeVjnw; Mon, 13 May 2013 00:21:51 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DB2E621F9234; Mon, 13 May 2013 00:21:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-61-5190948a0093 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6D.09.01956.A8490915; Mon, 13 May 2013 09:21:46 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 13 May 2013 09:21:46 +0200 Message-ID: <5190948A.5070707@ericsson.com> Date: Mon, 13 May 2013 09:21:46 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+JvrW7XlAmBBp/n6Vms2TmBxWLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTy+P8mMIA5issmJTUnsyy1SN8ugStj4q6pzAV/lCve /T3F3MB4TqaLkZNDQsBEovfGFlYIW0ziwr31bCC2kMApRol/Jzy7GLmA7LVA9pp+RpAEr4C2 xJb7p5i6GDk4WARUJU4fFgIJswkESlz//4sJxBYViJL493Y3VLmgxMmZT1hAbBEBeYnutkVg NcwC5RKnL30Hs4UFvCW2bVjIDLH3O7NE9+EUEJsTaOb0m8+g6m0lLsy5zgJhy0s0b50NVa8r 8e71PdYJjIKzkKybhaRlFpKWBYzMqxjZcxMzc9LLzTcxAoP14JbfBjsYN90XO8QozcGiJM6b zNUYKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR+tp1373dbxw8AtyyHMu/Tzs2s6x1bnRr bZ3Q3xvrShSUdC4k19wLL1zkLLk39VB82pmjvnN/b/189omtTtyM8vkTFgR9LjjJO4vRKXHd m4Z/L7ntBVPtTA8ese9Vejtp+oHlxsc3aHs+l7pgs2jdSf3bO6ZPc3e+lpwesVltXdlaG7WE fhdhJZbijERDLeai4kQAFV5HUiQCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 07:21:56 -0000 On 2013-05-12 20:28, Emil Ivov wrote: > On Sun, May 12, 2013 at 8:18 PM, Stefan Håkansson LK > wrote: >> On 5/11/13 6:24 PM, Paul Kyzivat wrote: >>> On 5/11/13 7:50 AM, Stefan Håkansson LK wrote: >>>> On 5/10/13 11:20 PM, Paul Kyzivat wrote: >>> >>>>> What is the probability that the other side, for independent reasons, >>>>> decides to make a change within that interval? (And it isn't really the >>>>> whole interval - it is only the first part of it.) >>>> >>>> Given that in multiparty services the "main" video changes quite often, >>>> I'd not say this is extremely low. It will happen. >>> >>> Are you thinking that there will be an SDP change every time the speaker >>> changes??? >>> >>> Or do you mean changes when participants join and leave a conference? >> >> I meant the former (at speaker change). >> >> I guess that different designs can be chosen for media from central node >> to end-user clients, and some of them (as Bernard pointed out) would not >> require any signaling. Still, there might be cases where signaling is >> needed. > > Right, however in cases where signalling is indeed needed, should it > really be defined by RTCWEB rather than the application developer? > >> But leaving that aside, we still have the case of the media end-user >> client -> central node. If you're serious about not wasting bandwidth >> (and with my radio/mobile background I am sort of obsessed :-) ) all >> end-user clients which do not end up as main video anywhere should only >> transmit a low resolution video. So at every speaker change there would >> be at least one client that is asked to stop sending high resolution and >> only transmit low resolution, and one client that is asked to start >> transmitting high resolution video. >> >> I think that this would best be done using some RTCP signaling scheme, > > RTCP is just one of the possibilities. This could also be implemented > in a number of other ways that would all be more efficient for the > specific application and all out-of-scope for rtcweb. > >> but I also think there was an agreement a long time ago that SDP O/A >> should be used. > > Well the way I remember it SDP O/A was chosen for session negotiation > and that other forms of signalling were explicitly left out of the > charter. I took the result of the discussion and poll at the IETF-84 (http://tools.ietf.org/wg/rtcweb/minutes?item=minutes-84-rtcweb.html) as an indication of that SDP O/A should be used for this kind of in-session changes as well. > >> In this case either to transmit a new imageattr value > > imageattr is great as a declarative parameter indicating capabilities: > "I can't show more than 720p so there's no point to send me more than > that". Using it as a way to switch between thumbnail and HQ videos is > not entire impossible but is not particularly efficient either. To me it looks like a solution that people might feel inclined towards using. But there are others that want to use simulcast, and then pause/resume sending of high and low resolution streams, and that problem is more or less the same when it comes to signaling. And even if we omitted the possibility for a receiver to indicate to the sender (via standardized signaling) that it should pause or resume sending, and instead left that up to an API (at sender side) and proprietary signaling, we still have to have some kind of signaling IMO: the sender can not just stop sending RTP packets, there need to be a signal to the receiver so it understands this (and does not think there are extreme packet losses or some other errors) and can indicate to the application at the receiving end (in WebRTC it should result in a "mute" event being fired on the PC-track in question). I think the current assumption is SDP O/A for that kind of signaling. > >> requesting another resolution, or to pause/resume - using recv on/off in >> Plan B or the direction attribute in Plan A - the low and high >> resolution simulcast streams accordingly (or I assume to pause/resume >> the enhancement layers if a scalable codec is used). >> >>> >>> I would hope there will normally not be SDP changes for either of those >>> events. >> >> I would like to avoid them too, but I'm not sure how. > > Well we can either figure that out (and it seems that we can't quite > agree on a solution) or make sure APIs have all it takes for the > matter to be resolved by app-to-app signalling. > > Emil > > -- > https://jitsi.org > From ron.even.tlv@gmail.com Mon May 13 02:56:06 2013 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 7475C21F93E9 for ; Mon, 13 May 2013 02:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-eHSTp3t0gV for ; Mon, 13 May 2013 02:56:05 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id CF05321F9413 for ; Mon, 13 May 2013 02:56:03 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so2729580wib.4 for ; Mon, 13 May 2013 02:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=SZfMAWQYlp4+t3/XXg8nGfPbxaf494B1WrGqJgv3auU=; b=PIxhmZfYKDL5QBsboqWCYUwMjYR7/iLjguEYn/SO551qEsrfaxoO0M928Em4pVYLvW 1YaJdKH6VxXKxAHrqsEe8T0oIeJTYCf/9DOuU6xWPtFxQKbuH2Rn7yaw9JaPFOaEvrZ3 SVxQSc6QIRp5aCVzZZDP3iaVDtgEjWHcEh9pjv3AHuIjPlp4TlML7o5LPtSgcqZIaPrc E4l1rrGRy6ELXxvE/galASmTv3pw6OLlW04+l/ofW2hDmXujELpqxigpooPuv7JeSHM3 1k5Tb4JCkbHIGNT90fGen2YdMcTyEiOzBuuMLZAJoebabER2hNBRWobtkCCx8tnpEVJ5 A4ew== X-Received: by 10.180.212.3 with SMTP id ng3mr17572770wic.22.1368438962420; Mon, 13 May 2013 02:56:02 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id ay7sm6907301wib.9.2013.05.13.02.56.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 02:56:01 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , "'Paul Kyzivat'" References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> <518F67E1.3040205@jitsi.org> In-Reply-To: <518F67E1.3040205@jitsi.org> Date: Mon, 13 May 2013 12:55:06 +0300 Message-ID: <009f01ce4fbf$f4763b20$dd62b160$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfgBrq/rAwLQUjLpAZ3w/YMBwZXOPQEVf9lIl/KRWhA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 09:56:06 -0000 Hi, I do not think that CLUE is much different from RTCweb. Like Bernard said the major usage of the CLUE channel is the support for the spatial information. CLUE is not replacing SDP o/a. In CLUE there is still a need to have an SDP that describe multiple RTP streams from the same media type multiplexed in a single RTP session. There is also a need to map these streams to a media capture in CLUE. The CLUE specific requirements stem from the need to support different RTP topologies (http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00) . I am aware that there was no conclusion in the Stockholm interim meeting about the need to support the different topologies for WebRTC Roni Even -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov Sent: 12 May, 2013 12:59 PM To: Paul Kyzivat Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based On 11.05.13, 19:51, Paul Kyzivat wrote: > I don't have a specific action to recommend here. This just seems like > a somewhat fundamental shift that out to be recognized. It probably > isn't just RTCWEB and CLUE, it is really related to more complex > communication scenarios. ISTM that CLUE is addressing this by building > a layer on top of O/A, while RTCWEB is *battling* with O/A. That's a nice way to put it. Interestingly the CLUE approach to take this out of O/A seems to be more in line with the RTCWEB paradigm than both Plan A or Plan B. The decision not to implement an official signalling RTCWEB protocol was taken very early in this working group and there was very strong consensus on the fact that imposing a specific signalling protocol would be incompatible with the web in general. Still, it seems to me that we are now trying to compensate for the lack of such a signalling protocol by piggybacking on top of O/A and SDP with things such as the possibility to turn off individual SSRCs. Why do we need these things? Aren't they better handled by the API? Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From csp@csperkins.org Mon May 13 03:33:08 2013 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 7AA6A21F942B for ; Mon, 13 May 2013 03:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhKEbXE9RW81 for ; Mon, 13 May 2013 03:33:04 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id C85FB21F9428 for ; Mon, 13 May 2013 03:33:03 -0700 (PDT) Received: from [130.209.247.112] (port=61888 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ubq3u-0005pP-Hc; Mon, 13 May 2013 11:33:01 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Mon, 13 May 2013 11:32:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> To: Cullen Jennings X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 10:33:08 -0000 On 10 May 2013, at 17:37, Cullen Jennings wrote: > On May 8, 2013, at 4:00 AM, Harald Alvestrand = wrote: >> The paragraph that worries me most is this one: >>=20 >> Offerers conformant to this specification MUST do one of the >> following: >>=20 >> o Use non-overlapping PT values for each m-line in any given bundle >> group. >>=20 >> o Provide distinct a=3Dssrc attributes for each m-line which uses >> overlapping PT values with any other m-line. [Technically, this >> is a general case of the previous point.] >>=20 >>=20 >>=20 >> To put a blunt point on it: Either send less than ~32 streams, or = give a=3Dssrc attributes. >=20 > As a slide note, as I imagine you are aware, it is not 32 but in the = roughly 100 range=20 >=20 >>=20 >> To me, that measn we're mandating one mechanism (PT values) for small = numbers of flows, and another mechanism (a=3Dssrc) for large numbers of = flows - such mechanism changes usually have "interesting" properties in = what happens at the changeover point. >=20 > The problem is that SSRC are not a stable demux point due to collision = and early media issues so, for applications that care about theses, they = can use PT. For things that need the properties of the larger code = space, they can use SSRC or other future extension to RTP. The code is = very simple to deal with demux on both PT and SSRC . If someone wants to = later add a RTP header extensions with another tag that can be used for = demux, that is fine too. The idea is that the device will use what it = currently knows (both PT and SSRC) to do the best demux it can do given = the information at hand. This gives us the best of SSRC demux and PT = demux and actually allows a combination of the two that scales to much = larger numbers than either alone. And it's trivial to implement. I'm confused about what you mean by using a combination of SSRC and PT = demux. You can't have two distinct SSRCs using the same PT values in a = single RTP session, because you can't distinguish the RTCP packets for = the two SSRCs, and we mandated the use of RTCP.=20 The RTP demultiplexing process, as I always understood it, was to look = at the SSRC first, and based on that find your SRTP context, jitter = buffer, RTCP state, etc., which are all indexed by SSRC. Then, look at = the PT to determine what codec to use for the stream (noting that SSRCs = can switch between PT values, and multiple SSRCs can use the same PT). = Using the PT as the de-mux point for streams doesn't let you find the = appropriate RTCP state or SRTP context, since those are indexed by SSRC, = and requires you to use unique PT values for each stream, which is a = much more limited space than the SSRC space (and, unlike the SSRC space, = has no collision resolution built-in).=20 >> It would seem to me to be architecturally cleaner to insist that = a=3Dssrc be used always. >=20 > There rare two major disadvantages to doing this=20 >=20 > 1) The side receiving the media can't tell the other side what SSRC to = use in the offer. That means you can not demux until after the answer is = received in the best case. This adds latency and cause media clipping. = It does not work with early media in some cases.=20 You can always use the SSRC to demux based on source, then use the PT to = direct to the appropriate codec, irrespective of whether you've received = signalling of the SSRC in advance. I don't see how using the PT as the = primary demultiplexing point helps here. > It may not matter to the use case you have in mind but it does matter = to use cases other have in mind. Note there is no problem for the use = case you are interested in just using the SSRC and not caring what = happens with the PT. For applications that want to do that, the = mechanism in this draft works just fine. =20 >=20 > 2) the other problem is that SSRC collide and it takes a long time to = get the the updated information about how the collision was resolved and = in that time the data may actually go the wrong place. Just sort of = curios if chrome has implemented dealing with collisions yet? If the colliding sources send the required RTCP packets immediately, as = RFC 3550 allows in unicast scenarios, you should be able to determine = how collision was resolved straight away.=20 And, if you're signalling SSRCs, an SSRC collision is no more likely = than a PT collision, and gives you a bigger space to work with to = identify streams. > I will note that using PT + SSRC in the way Adam's draft has them = actually allows for a theoretical maximum of more like 3 million RTP = flows per port.=20 Using the SSRC to distinguish sources allows this anyway, and as I noted = above, you can't run multiple sources with the same SSRC and different = PT values without breaking RTCP. >> But in that case, I have a very large difficulty seeing the important = advantage this has over Plan B. >>=20 >>=20 >>=20 >> On 05/07/2013 08:30 PM, Adam Roach wrote: >>> In order to facilitate discussion between the two SDP format = alternatives we're considering, I've put together a document that more = clearly spells out the Plan A approach as we originally envisioned it. = Note that this is a slightly different approach than Cullen outlined in = Orlando. I fear the Orlando approach may have suffered from its attempts = to incorporate some elements of Plan B in an attempt to appease = proponents of that approach; and, in doing so, lost some of its clean = architecture.=20 >>>=20 >>> The cleaned up, new-and-improved description of the Plan A approach = is available here:=20 >>>=20 >>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt=20 >>>=20 >>> Note that we've omitted discussion of glare reduction from that = document, as I believe that mid-session glare can be completely avoided = by applications implementing a set of non-normative behaviors. These = behaviors are described in the a separate companion document:=20 >>>=20 >>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt=20 >>>=20 >>> Thanks.=20 >>>=20 >>> /a=20 >>> _______________________________________________=20 >>> rtcweb mailing list=20 >>> rtcweb@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/rtcweb=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 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Mon May 13 06:42:52 2013 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 848EA21F95E7 for ; Mon, 13 May 2013 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNaKXVXaNaOX for ; Mon, 13 May 2013 06:42:48 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id EFBCB21F95E5 for ; Mon, 13 May 2013 06:42:46 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta07.westchester.pa.mail.comcast.net with comcast id bQ3H1l0010xGWP857Rimg5; Mon, 13 May 2013 13:42:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id bRil1l0143ZTu2S3YRilqb; Mon, 13 May 2013 13:42:46 +0000 Message-ID: <5190EDD5.9050509@alum.mit.edu> Date: Mon, 13 May 2013 09:42:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Roni Even References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> <518F67E1.3040205@jitsi.org> <009f01ce4fbf$f4763b20$dd62b160$@gmail.com> In-Reply-To: <009f01ce4fbf$f4763b20$dd62b160$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368452566; bh=KuEmdaEp1PwLRujDfftPaRQuaZS9qZRU0cvdSSaannk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iSOdzglzSC0lTahjyJZ2Oo9J12RuRej8SduXhIZHbJNb2agsFT8ZHdba5a6Jfofcr YBJtjt0r29VuwEkyWt5/MKfVn0I05WOz6pfixUg7SnmX4zemFF5J+pb4y7e2fKwErK pv7fkpI/S9n+kWAyj8e3Eo8tQ+Prky5uu/eX4amLREutJB3lcFcSqEhmZFvvtCqtip ew/1dGL0GyFnshKJNn/uIs7VmBSv6rFQXjaeX71pKxNXP8xTUKG09rKVFc3gTyXEec ci7bVwcTdlLSv4uqYLl/d78ZgSrO6tJmtfGSzrNikygtFMHNTcw7BlpMCsxegewHYD VFoCS09YmCAsQ== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 13:42:52 -0000 On 5/13/13 5:55 AM, Roni Even wrote: > Hi, > I do not think that CLUE is much different from RTCweb. Like Bernard said > the major usage of the CLUE channel is the support for the spatial > information. Obviously I also think there is a lot of overlap. But they are not the same thing. CLUE needs to work in situations where rtcweb doesn't apply, as well as those where it does. So I have been trying to ensure rtcweb ends up defining mechanisms that "work" for clue, without excessively bogging down rtcweb with clue-specific concerns. > CLUE is not replacing SDP o/a. In CLUE there is still a need to have an SDP > that describe multiple RTP streams from the same media type multiplexed in a > single RTP session. There is also a need to map these streams to a media > capture in CLUE. The CLUE specific requirements stem from the need to > support different RTP topologies > (http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00) . > I am aware that there was no conclusion in the Stockholm interim meeting > about the need to support the different topologies for WebRTC IMO CLUE will end up being, in effect, a general mechanism for advertising and selecting desired real-time media content, that has been specialized for telepresence. Once it is done, I expect it will be possible to make relatively minor changes to it in order to specialize it to other application areas. As to why we need to define a protocol for this, rather than just an API, the simple answer is that IETF doesn't define APIs, so if we want to define it we need to make it a protocol. Another answer is that the API approach being pursued by webrtc/rtcweb works primarily because the assumption underlying that is that all the communicating endpoints are being mediated by a single (web) server. In cases where that is not true a protocol will still be required. Thanks, Paul > Roni Even > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Emil Ivov > Sent: 12 May, 2013 12:59 PM > To: Paul Kyzivat > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is > based > > > > On 11.05.13, 19:51, Paul Kyzivat wrote: >> I don't have a specific action to recommend here. This just seems like >> a somewhat fundamental shift that out to be recognized. It probably >> isn't just RTCWEB and CLUE, it is really related to more complex >> communication scenarios. ISTM that CLUE is addressing this by building >> a layer on top of O/A, while RTCWEB is *battling* with O/A. > > That's a nice way to put it. Interestingly the CLUE approach to take this > out of O/A seems to be more in line with the RTCWEB paradigm than both Plan > A or Plan B. > > The decision not to implement an official signalling RTCWEB protocol was > taken very early in this working group and there was very strong consensus > on the fact that imposing a specific signalling protocol would be > incompatible with the web in general. > > Still, it seems to me that we are now trying to compensate for the lack of > such a signalling protocol by piggybacking on top of O/A and SDP with things > such as the possibility to turn off individual SSRCs. > > Why do we need these things? Aren't they better handled by the API? > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From pkyzivat@alum.mit.edu Mon May 13 07:21:35 2013 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 1142C21F965C for ; Mon, 13 May 2013 07:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf4yJnNdhrcX for ; Mon, 13 May 2013 07:21:30 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0D21F9425 for ; Mon, 13 May 2013 07:21:29 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id bNpz1l0020xGWP85FSMUmM; Mon, 13 May 2013 14:21:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id bSMU1l00H3ZTu2S3YSMUnU; Mon, 13 May 2013 14:21:28 +0000 Message-ID: <5190F6E7.3090801@alum.mit.edu> Date: Mon, 13 May 2013 10:21:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368454888; bh=SU55SZRJs1kYAiuEElJeMe1kOwVQn2f19jgu4GJWoy8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r1ibZ1EhWLzMaaAF+94PE1S15vXPTVdoCog5ESLflgEPHyfJ+9JBXD6rwD8m0da4F a+eD3238b1qlo9bn6MuitnqSedUVKt+1pd2pEhMtyQZ+JXfiFcIA43hPbJfudu1kPt AvuzMsreWE3kwctRRVBRJm9Vsz6n0AzqtGUkcgKYpfucsgvR8fltMrNRHlY8Kyzn3d +H6qr9uRvEXePqPRh/MGv/VrFt7fZqOcNd3v0U/vljfmP8vLdFk8xzm/ahuQ9sBXNa zafAd6cdm5Xp+UNoLyhqa2ebGdHWPihDBa49ULzn+hUq4LDaxh1BQP513MR/HVheFI H0ixabv9NA/MA== Subject: Re: [rtcweb] Comments on draft-uberti-rtcweb-plan-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 14:21:35 -0000 Comments inline, both to Bernard and to the draft itself. On 5/11/13 7:59 PM, Bernard Aboba wrote: > 2.1 > > These layouts can change dynamically, depending on the conference > content and the preferences of the receiver. As such, there are not > well-defined 'roles', that could be used to group sources into > specific 'large' or 'thumbnail' categories. As such, the requirement > Plan B attempts to satisfy is support for sending and receiving up to > hundreds of simultaneous, hetereogeneous sources. > > [BA] While I agree that the layouts can change dynamically, I am wondering if there is an implication that the burden of determining the 'roles' is on the mixer. For example, it might be assumed that the mixer allocates an SSRC for the 'large' category, and other SSRCs for the 'thumbnails' and then these SSRCs are statically mapped to MSTs and rendered. However, another way to handle it is for the browser to handle the role assignment, and I would argue that this could make more sense in some cases, particularly since this could make the mixer a lot simpler, or even obviate the need for a mixer entirely (e.g. an RTP translator might work in some cases). ISTM that this particular part gets well into the CLUE design space, where the focus is on the describing spatial relationship among sources, and thus the ability to choose which ones are desired on that basis. In clue we have concluded that these relationships are complex to describe, and not suited to embedding in SDP. > 4.1 . Negotiation of new or legacy behavior > > In order to know whether a given application supports Plan B, an > attribute in the offer is needed. There are various options that > could be used for this: > > o a=ssrc isn't enough, since you might not have any send streams, > and therefore no a=ssrc attributes. > > o a=max-*-ssrc could work, but has additional semantics > > o a=msid-semantic indicates that you understand MSIDs. > > Because understanding MSID is a prerequisite to using plan B, the > third option (presence of a=msid-semantic) is recommended. > > [BA] I would suggest that max-*-ssrc is a better choice because there are legacy scenarios where msid might not be present. I agree with you here. Instead of layering baggage on an attribute intended for a different purpose, using this one depends means depending directly on the intended purpose of the attribute. > 4.2 > . > New signaling flow > > When both sides support Plan B, to properly allow both sides to > indicate which MSTs they have, and allow the remote side to select > the desired MSTs to receive, a 3-way handshake is needed (this is > just math; the offer can't select the answerer's MSTs until they know > about them). > > [BA] While I understand the argument for why you need two O/As for both > sides to select the desired streams, I think that it's possible to design > the exchange so that only one O/A is needed most of the time. The key > concept is for the offer to contain information on what the offerer is capable > of receiving in addition to what it is capable of sending. Yes, another > O/A might be needed if it turns out that the Offerer wants something different > than what the Answerer chose, but at least the first Answer is guaranteed to > be acceptable to the Offerer. > > That is, I believe we should think of the second O/A as an optional exchange > that hopefully won't be needed much of the time than as part of a "3-way" or > "4-way" handshake that will execute every time. IMO the 2-way handshake as always depended on an implicit commonality between caller and callee, and/or applications simple enough that it is feasible to encompass all possible options within the first offer. So it works well when you are calling from a "phone" and it is likely that the thing you are calling is also a phone. But it doesn't work very well if you are a telepresence system calling another telepresence system. Even in more complex cases you can probably get things to work in one O/A exchange if a large percentage of the things you may call have similar configurations. But the general case is going to require multiple O/A exchanges, or else exchange of info via some other channel prior to the O/A exchange. > The expected flow for this would be for the caller to > send an offer with its sources, then the callee would send back an > answer with the sources it wants the caller to send, followed > immediately by an offer with the sources that the callee has > available to send. Finally, the answerer will reply back with the > sources that it wants to request from the callee. The entire > sequence can be done in 1.5 RTT. > > [BA] Why not add the info on what sources the callee has available to send to the first Answer? If the Offer also contains the maximum number of received SSRCs, > the Offerer should prepare to receive that many SSRCs, and the Answer could include up to that many sources > as enabled and start sending. That way, if the sources sent are OK with the Offerer then we don't need another > Offer/Answer exchange, because the Answerer has indicated what sources it wants from the ones the Offerer > said it could send. Certainly the offer can describe a bunch of sendonly streams. That is the easy part. The hard part is describing what you want to receive, without knowing what is available to be received. Also, it is hard to describe the content of those sendonly streams sufficiently in the offer so that the answerer will know whether it wants them or not. > This assumes that the Offerer can handle incoming RTP streams up to the maximum number of receive SSRCs before it receives the Answer which can explicitly declare the SSRCs. > > > In addition, since the > sources are known ahead of time by the recipient of said sources, it > is prepared to demux them by SSRC without any signaling/media race. *How* are the sources known ahead of time by the recipient??? Thanks, Paul From emil@sip-communicator.org Mon May 13 07:33:16 2013 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 9933921F8F4D for ; Mon, 13 May 2013 07:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqVcJ-PBlp4E for ; Mon, 13 May 2013 07:33:16 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E87AF21F940B for ; Mon, 13 May 2013 07:33:13 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id ik5so2499584bkc.9 for ; Mon, 13 May 2013 07:33:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=O+H+EnDlhjUOxj75ZXxXaXvVaUNvPaq91A4bL0Mv7eA=; b=i2YiO/3xvjSytJOW2h6lJ62310ozjHSLbxgi1f1PejpRJJq5XUPzZ+aJCrSrhjAIFQ Ghdfxwf8IH44onaQ2bU6fX/q2F+Hh+difcIzDYa0Sze/heF0TLz+t+zSoX0OC3xR2KKv 3o8IzV0Df5NjKjgFqlyqBXM35sySicvMaSCPzowSvURuW2j2GA2YNnD5XSNDvnYw/t3t wzlD7yW1vLE+oFuTy/gMWn/kLTbgCStrdMbo/CFtHPdsZJ5kH1uNDLOfrvHozcqqjJ16 6eKAcT/Zg3FzRYTuhdO0hlAV7kTMK6eNVLcJ0VpXe3R+mMpwZVIjvgqyCaaktJYWojzl 7SmQ== X-Received: by 10.205.38.195 with SMTP id tj3mr5590960bkb.67.1368455592347; Mon, 13 May 2013 07:33:12 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id j8sm2298660bky.17.2013.05.13.07.33.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 07:33:11 -0700 (PDT) Message-ID: <5190F9A6.4000904@jitsi.org> Date: Mon, 13 May 2013 17:33:10 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5190948A.5070707@ericsson.com> In-Reply-To: <5190948A.5070707@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxQgH7PFHiuS/Uaniny0bg3B0qVeyZVNc1i63j1ri9utiAb/JQYxOGo5xOi+f9Bp8eQ3MJ Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 14:33:16 -0000 Hey Stefan, On 13.05.13, 10:21, Stefan H=E5kansson LK wrote: >> Well the way I remember it SDP O/A was chosen for session negotiation >> and that other forms of signalling were explicitly left out of the >> charter. >=20 > I took the result of the discussion and poll at the IETF-84=20 > (http://tools.ietf.org/wg/rtcweb/minutes?item=3Dminutes-84-rtcweb.html)= as=20 > an indication of that SDP O/A should be used for this kind of in-sessio= n=20 > changes as well. True, I am not sure we all realized the number of use cases this would end up encompassing and how we would end up implementing signalling features into SDP. >>> In this case either to transmit a new imageattr value >> >> imageattr is great as a declarative parameter indicating capabilities:= >> "I can't show more than 720p so there's no point to send me more than >> that". Using it as a way to switch between thumbnail and HQ videos is >> not entire impossible but is not particularly efficient either. >=20 > To me it looks like a solution that people might feel inclined towards = > using. >=20 > But there are others that want to use simulcast, and then pause/resume = > sending of high and low resolution streams, and that problem is more or= =20 > less the same when it comes to signaling. >=20 > And even if we omitted the possibility for a receiver to indicate to th= e=20 > sender (via standardized signaling) that it should pause or resume=20 > sending, and instead left that up to an API (at sender side) and=20 > proprietary signaling, we still have to have some kind of signaling IMO= :=20 > the sender can not just stop sending RTP packets, there need to be a=20 > signal to the receiver so it understands this=20 I never implied there should be no signalling. Just that implementing it all over SDP O/A leads to unforeseen complexities. RTCP BYE and/or SSRC expiration would be one option here. Custom signalling another. Cheers, Emil --=20 https://jitsi.org From bernard_aboba@hotmail.com Mon May 13 09:20:25 2013 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 52A2021F93FF for ; Mon, 13 May 2013 09:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNPdGXyTL6pr for ; Mon, 13 May 2013 09:20:19 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 532EE21F940D for ; Mon, 13 May 2013 09:20:19 -0700 (PDT) Received: from BLU169-W136 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 09:20:17 -0700 X-EIP: [bQK3HYoS+z0Rer9+hZ6EBfuPeAoeDI8f] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_0c3579ea-99c5-468d-8968-6f404ef748f4_" From: Bernard Aboba To: Colin Perkins Date: Mon, 13 May 2013 09:20:16 -0700 Importance: Normal In-Reply-To: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no>, , MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 16:20:17.0215 (UTC) FILETIME=[C17DC4F0:01CE4FF5] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 16:20:25 -0000 --_0c3579ea-99c5-468d-8968-6f404ef748f4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colin said:=20 The RTP demultiplexing process=2C as I always understood it=2C was to look = at the SSRC first=2C and based on that find your SRTP context=2C jitter buf= fer=2C RTCP state=2C etc.=2C which are all indexed by SSRC. Then=2C look at= the PT to determine what codec to use for the stream (noting that SSRCs ca= n switch between PT values=2C and multiple SSRCs can use the same PT). Usin= g the PT as the de-mux point for streams doesn't let you find the appropria= te RTCP state or SRTP context=2C since those are indexed by SSRC=2C and req= uires you to use unique PT values for each stream=2C which is a much more l= imited space than the SSRC space (and=2C unlike the SSRC space=2C has no co= llision resolution built-in).=20 [BA] That is typically how I've seen it done=2C yes. =20 Colin also said:=20 I'm confused about what you mean by using a combination of SSRC and PT demu= x. You can't have two distinct SSRCs using the same PT values in a single R= TP session=2C because you can't distinguish the RTCP packets for the two SS= RCs=2C and we mandated the use of RTCP.=20 [BA] The statement above seems inconsistent with the earlier statement tha= t "multiple SSRCs can use the same PT". Or did you mean having multiple SS= RCs=2C each using multiple PT values? =20 Since the RTCP packets include the SSRC (but not the PT)=2C distinguishing = the RTCP packets by SSRC isn't a problem. I have seen multiple SSRCs use th= e same PT within an RTP session to enable several scenarios. This includes= RTP stream demux (e.g. the objective of "Plan B")=2C as well as simulcast = and layered coding. In the simulcast/layered coding case there are issues = with understanding which RTP streams go together purely at the RTP level (e= .g. adding this info to an SDES packet would be helpful)=2C but it doesn't = seem to cause problems for de-muxing. = --_0c3579ea-99c5-468d-8968-6f404ef748f4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Colin said: =3B

= The RTP demultiplexing process=2C as I always understood it=2C was to look = at the SSRC first=2C and based on that find your SRTP context=2C jitter buf= fer=2C RTCP state=2C etc.=2C which are all indexed by SSRC. Then=2C look at= the PT to determine what codec to use for the stream (noting that SSRCs ca= n switch between PT values=2C and multiple SSRCs can use the same PT). Usin= g the PT as the de-mux point for streams doesn't let you find the appropria= te RTCP state or SRTP context=2C since those are indexed by SSRC=2C and req= uires you to use unique PT values for each stream=2C which is a much more l= imited space than the SSRC space (and=2C unlike the SSRC space=2C has no co= llision resolution built-in). =3B

[BA]  = =3BThat is typically how I've seen it done=2C yes.  =3B

<= /div>
Colin also said: =3B

I'm confus= ed about what you mean by using a combination of SSRC and PT demux. You can= 't have two distinct SSRCs using the same PT values in a single RTP session= =2C because you can't distinguish the RTCP packets for the two SSRCs=2C and= we mandated the use of RTCP. =3B

[BA]  = =3BThe statement above seems inconsiste= nt with the earlier statement that "multiple SSRCs can use the same PT". &n= bsp=3BOr did you mean having multiple SSRCs=2C each using multiple PT value= s?  =3B

Since the RTCP packets incl= ude the SSRC (but not the PT)=2C distinguishing the RTCP packets by SSRC is= n't a problem. =3BI have see= n multiple SSRCs use the same PT within an RTP session to enable several sc= enarios.  =3BThis includes RTP stream demux (e.g. the objective of "Pla= n B")=2C as well as simulcast and layered coding.  =3BIn the simulcast/= layered coding case there are issues with understanding which RTP streams g= o together purely at the RTP level (e.g. adding this info to an SDES packet= would be helpful)=2C but it doesn't seem to cause problems for de-muxing.&= nbsp=3B
= --_0c3579ea-99c5-468d-8968-6f404ef748f4_-- From csp@csperkins.org Mon May 13 09:25:30 2013 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 C6F0B21F8E97 for ; Mon, 13 May 2013 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXF-oPuSHibs for ; Mon, 13 May 2013 09:25:18 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2088221F8E7B for ; Mon, 13 May 2013 09:25:14 -0700 (PDT) Received: from [130.209.247.112] (port=64999 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UbvYj-00034Q-HS; Mon, 13 May 2013 17:25:12 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0CEB0C55-5944-4575-96EB-DC5FC0143327" From: Colin Perkins In-Reply-To: Date: Mon, 13 May 2013 17:25:08 +0100 Message-Id: <5A28748F-AD55-4D8F-8960-B14C9423AF1D@csperkins.org> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no>, , To: Bernard Aboba X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 16:25:31 -0000 --Apple-Mail=_0CEB0C55-5944-4575-96EB-DC5FC0143327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 13 May 2013, at 17:20, Bernard Aboba wrote: > Colin said:=20 >=20 > The RTP demultiplexing process, as I always understood it, was to look = at the SSRC first, and based on that find your SRTP context, jitter = buffer, RTCP state, etc., which are all indexed by SSRC. Then, look at = the PT to determine what codec to use for the stream (noting that SSRCs = can switch between PT values, and multiple SSRCs can use the same PT). = Using the PT as the de-mux point for streams doesn't let you find the = appropriate RTCP state or SRTP context, since those are indexed by SSRC, = and requires you to use unique PT values for each stream, which is a = much more limited space than the SSRC space (and, unlike the SSRC space, = has no collision resolution built-in).=20 >=20 > [BA] That is typically how I've seen it done, yes. =20 >=20 > Colin also said:=20 >=20 > I'm confused about what you mean by using a combination of SSRC and PT = demux. You can't have two distinct SSRCs using the same PT values in a = single RTP session, because you can't distinguish the RTCP packets for = the two SSRCs, and we mandated the use of RTCP.=20 >=20 > [BA] The statement above seems inconsistent with the earlier = statement that "multiple SSRCs can use the same PT". Or did you mean = having multiple SSRCs, each using multiple PT values? =20 Sorry, what I meant to say was that you can't do this while demuxing = based on the PT, because you can't distinguish RTCP packets. You need to = use the SSRC for demuxing.=20 > Since the RTCP packets include the SSRC (but not the PT), = distinguishing the RTCP packets by SSRC isn't a problem. I have seen = multiple SSRCs use the same PT within an RTP session to enable several = scenarios. This includes RTP stream demux (e.g. the objective of "Plan = B"), as well as simulcast and layered coding. In the simulcast/layered = coding case there are issues with understanding which RTP streams go = together purely at the RTP level (e.g. adding this info to an SDES = packet would be helpful), but it doesn't seem to cause problems for = de-muxing.=20 Agree. --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_0CEB0C55-5944-4575-96EB-DC5FC0143327 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Colin said: 

The RTP demultiplexing = process, as I always understood it, was to look at the SSRC first, and = based on that find your SRTP context, jitter buffer, RTCP state, etc., = which are all indexed by SSRC. Then, look at the PT to determine what = codec to use for the stream (noting that SSRCs can switch between PT = values, and multiple SSRCs can use the same PT). Using the PT as the = de-mux point for streams doesn't let you find the appropriate RTCP state = or SRTP context, since those are indexed by SSRC, and requires you to = use unique PT values for each stream, which is a much more limited space = than the SSRC space (and, unlike the SSRC space, has no collision = resolution built-in). 

[BA]  That is = typically how I've seen it done, yes. =  

Colin also = said: 

I'm confused about what you = mean by using a combination of SSRC and PT demux. You can't have two = distinct SSRCs using the same PT values in a single RTP session, because = you can't distinguish the RTCP packets for the two SSRCs, and we = mandated the use of RTCP. 

[BA] =  The statement above seems = inconsistent with the earlier statement that "multiple SSRCs can use the = same PT".  Or did you mean having multiple SSRCs, each using = multiple PT values? =  

So= rry, what I meant to say was that you can't do this while demuxing based = on the PT, because you can't distinguish RTCP packets. You need to use = the SSRC for demuxing. 

Since the = RTCP packets include the SSRC (but not the PT), distinguishing the RTCP = packets by SSRC isn't a problem. I have seen multiple SSRCs use the same PT within an RTP session = to enable several scenarios.  This includes RTP stream demux (e.g. = the objective of "Plan B"), as well as simulcast and layered coding. =  In the simulcast/layered coding case there are issues with = understanding which RTP streams go together purely at the RTP level = (e.g. adding this info to an SDES packet would be helpful), but it = doesn't seem to cause problems for = de-muxing. 
<= br>
Agree.

-- 
Colin Perkins



= --Apple-Mail=_0CEB0C55-5944-4575-96EB-DC5FC0143327-- From bernard_aboba@hotmail.com Mon May 13 09:40:29 2013 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 3E41221F8FB6 for ; Mon, 13 May 2013 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFwS-9loLPt7 for ; Mon, 13 May 2013 09:40:20 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by ietfa.amsl.com (Postfix) with ESMTP id B7C8221F8EC1 for ; Mon, 13 May 2013 09:40:20 -0700 (PDT) Received: from BLU169-W9 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 09:40:20 -0700 X-EIP: [R6DUTRmTSg9pVRW4vyHHRSArn12eg+dy] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_76bdc5de-d50f-4de5-8922-2ba2aa162c10_" From: Bernard Aboba To: Paul Kyzivat , "rtcweb@ietf.org" Date: Mon, 13 May 2013 09:40:20 -0700 Importance: Normal In-Reply-To: <5190F6E7.3090801@alum.mit.edu> References: , <5190F6E7.3090801@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 16:40:20.0802 (UTC) FILETIME=[8EE29220:01CE4FF8] Subject: Re: [rtcweb] Comments on draft-uberti-rtcweb-plan-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 16:40:29 -0000 --_76bdc5de-d50f-4de5-8922-2ba2aa162c10_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:=20 > IMO the 2-way handshake as always depended on an implicit commonality > b= etween caller and callee=2C and/or applications simple enough that it is=20 > feasible to encompass all possible options within the first offer. >=20 > So it works well when you are calling from a "phone" and it is likely=20 > that the thing you are calling is also a phone. But it doesn't work very= =20 > well if you are a telepresence system calling another telepresence system= . >=20 > Even in more complex cases you can probably get things to work in one=20 > O/A exchange if a large percentage of the things you may call have=20 > similar configurations. >=20 > But the general case is going to require multiple O/A exchanges=2C or els= e=20 > exchange of info via some other channel prior to the O/A exchange. [BA] I agree that the "general case" may require multiple O/A exchanges. Ho= wever=2C it would be desirable for common WebRTC cases to be handled with a= single O/A exchange=2C since common WebRTC cases are presumably less invo= lved then CLUE scenarios.=20 Paul said: > Certainly the offer can describe a bunch of sendonly streams. That is=20 > the easy part. The hard part is describing what you want to receive=2C=20 > without knowing what is available to be received. [BA] I would distinguish statements about capabilities (e.g. what you are c= apable of receiving) from indications about what you want to receive. In a = CLUE scenario=2C there can be number of very different configurations that= need to be expressed and decided between (e.g. multiple streams to be disp= layed on multiple screens=2C etc.). Whereas in WebRTC=2C there are a numbe= r of use cases (such as multiple RTP streams sent by a mixer=2C to be displ= ayed on a single screen) that we want to support in as simple a way as poss= ible. So the question in my mind is "what do we need to do to allow those = WebRTC use cases to be handled in a single O/A exchange" while at the same = time=2C not ruling out support for more complex cases=2C which would requir= e multiple O/A exchanges (or use of out-of-band signaling=2C as advocated i= n CLUE). > Also=2C it is hard to describe the content of those sendonly st= reams=20 > sufficiently in the offer so that the answerer will know whether it=20 > wants them or not. [BA] In WebRTC use cases=2C I'd suggest that the decision is somewhat simpl= er than it would be for CLUE (e.g. it doesn't make sense to reject a screen= sharing video stream in a presentation scenario). So if an Offerer provid= es some basic info (how many streams it can handle=2C how much bandwidth=2C= the resolutions it supports=2C etc.) that will often be enough for the Ans= werer to send something reasonable=2C and for the negotiation to conclude i= n a single O/A. Of course=2C the Answerer could select something that the = Offerer finds unacceptable=2C which would need to be cleaned up in an addit= ional O/A exchange. I'm just saying that we should strive to be able to co= mplete some common uses cases in a single O/A=2C if possible. =20 > This assumes that the Offerer can handle incoming RTP streams up to the m= aximum number of receive SSRCs before it receives the Answer which can expl= icitly declare the SSRCs. [BA] Yes=2C that is my assumption -- and I believe that it is possible to e= ngineer things so that this will work.=20 > > In addition=2C since the > > sources are known ahead of time by the recipient of said sources=2C= it > > is prepared to demux them by SSRC without any signaling/media race. >=20 > *How* are the sources known ahead of time by the recipient??? [BA] I think that Justin was noting that in the "Plan B" proposal=2C media = doesn't flow until each side has gotten the list of declared SSRCs and resp= onded to it. So the recipient knows the sources ahead of time. = = --_76bdc5de-d50f-4de5-8922-2ba2aa162c10_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul said: =3B

>=3B IMO = the 2-way handshake as always depended on an implicit commonality =3B
>=3B between caller and callee=2C and/or applications sim= ple enough that it is
>=3B feasible to encompass all possible options= within the first offer.
>=3B
>=3B So it works well when you are= calling from a "phone" and it is likely
>=3B that the thing you are = calling is also a phone. But it doesn't work very
>=3B well if you ar= e a telepresence system calling another telepresence system.
>=3B
= >=3B Even in more complex cases you can probably get things to work in on= e
>=3B O/A exchange if a large percentage of the things you may call = have
>=3B similar configurations.
>=3B
>=3B But the genera= l case is going to require multiple O/A exchanges=2C or else
>=3B exc= hange of info via some other channel prior to the O/A exchange.
<= br>
[BA] I agree that the "general case" may require multiple O/A= exchanges. =3B
However=2C it would be desirable for common W= ebRTC cases to be handled with a single O/A exchange=2C  =3B
= since common WebRTC cases are presumably less involved then CLUE scenarios.=  =3B

Paul said:

>= =3B Certainly the offer can describe a bunch of sendonly streams. That is <= br>>=3B the easy part. The hard part is describing what you want to recei= ve=2C
>=3B without knowing what is available to be received.

[BA] I would distinguish statements about capabilities (e.= g. what you are capable of receiving) from indications about what you want = to receive. =3B
In a CLUE scenario=2C there can be  =3Bnu= mber of very different configurations that need to be expressed and decided= between (e.g. multiple streams to be displayed on multiple screens=2C etc.= ).  =3BWhereas in WebRTC=2C there are a number of use cases (such as mu= ltiple RTP streams sent by a mixer=2C to be displayed on a single screen) t= hat we want to support in as simple a way as possible.  =3BSo the quest= ion in my mind is "what do we need to do to allow those WebRTC use cases to= be handled in a single O/A exchange" while at the same time=2C not ruling = out support for more complex cases=2C which would require multiple O/A exch= anges (or use of out-of-band signaling=2C as advocated in CLUE). =3B
 =3B
>=3B Also=2C it is hard to describe the conten= t of those sendonly streams
>=3B sufficiently in the offer so that th= e answerer will know whether it
>=3B wants them or not.
[BA] In WebRTC use cases=2C I'd suggest that the decision is so= mewhat simpler than it would be for CLUE (e.g. it doesn't make sense to rej= ect a screen sharing video stream in a presentation scenario).  =3BSo i= f an Offerer provides some basic info (how many streams it can handle=2C ho= w much bandwidth=2C the resolutions it supports=2C etc.) that will often be= enough for the Answerer to send something reasonable=2C and for the negoti= ation to conclude in a single O/A.  =3BOf course=2C the Answerer could = select something that the Offerer finds unacceptable=2C which would need to= be cleaned up in an additional O/A exchange.  =3BI'm just saying that = we should strive to be able to complete some common uses cases in a single = O/A=2C if possible.  =3B

>=3B This assumes t= hat the Offerer can handle incoming RTP streams up to the maximum number of= receive SSRCs before it receives the Answer which can explicitly declare t= he SSRCs.

[BA] Yes=2C that is my assumption -- and= I believe that it is possible to engineer things so that this will work.&n= bsp=3B

>=3B >=3B In addition=2C since the<= br>>=3B >=3B sources are known ahead of time by the recipient of sa= id sources=2C it
>=3B >=3B is prepared to demux them by SSRC wit= hout any signaling/media race.
>=3B
>=3B *How* are the sources k= nown ahead of time by the recipient???

[BA] I think that = Justin was noting that in the "Plan B" proposal=2C media doesn't flow until= each side has gotten the list of declared SSRCs and responded to it.  = =3BSo the recipient knows the sources ahead of time.  =3B
=
= --_76bdc5de-d50f-4de5-8922-2ba2aa162c10_-- From mary.ietf.barnes@gmail.com Mon May 13 09:44:59 2013 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 D9F1121F90EB for ; Mon, 13 May 2013 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vtSPHJzxZ8z for ; Mon, 13 May 2013 09:44:59 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E481521F90AC for ; Mon, 13 May 2013 09:44:57 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s11so3491857qcw.29 for ; Mon, 13 May 2013 09:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ll5JtRGH2QxsO94kRxTGGkrSY/vHUD6+FTRwrB6Q65U=; b=JmVnX8T4Zsq7zGmnuhO15S7BRTTbBCK2iMyMGvvaNtzAfC2ezb6My3uE1jVTWiTC0u Dq1mV92GGkJGawi/unj8XShIFNI6qwejWRMD1etnedBvvSMztTfBoB2lkDWORAJRL4uF dSXtJrTPxfN8CVB7rAGbJLJupREOHRQ6FJiqd9nedV9AY3xNFXCFYGvee8ZoXs8n+yx7 pB4AdGbugCs0WBhj1CunthpG22F9MkJLOlNRThMcXNGG7hg82kOwZ+wqUMTdXXXL1p16 gd7yhd9b9SfWNNc1jGSE9b8PLtzsKfoRzbW8lDnBRls7XNUBtgZWHSoCsqumoJLp8XxK Hvyw== MIME-Version: 1.0 X-Received: by 10.229.90.5 with SMTP id g5mr587973qcm.26.1368463497021; Mon, 13 May 2013 09:44:57 -0700 (PDT) Received: by 10.49.116.172 with HTTP; Mon, 13 May 2013 09:44:56 -0700 (PDT) In-Reply-To: <518D6C76.5060606@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> <518D6C76.5060606@alum.mit.edu> Date: Mon, 13 May 2013 11:44:56 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 16:45:00 -0000 Responses inline below [MB]. Mary. On Fri, May 10, 2013 at 4:53 PM, Paul Kyzivat wrote: > On 5/10/13 5:03 PM, Ted Hardie wrote: >> >> On Fri, May 10, 2013 at 10:10 AM, Cullen Jennings > > wrote: >> >> >> >> I want to be able to build a multi-screen telepresence systems that >> when it constructs an Offer, that offer could be going to a webrtc >> compliant browser, or it could be going to another CLUE complains >> endpoint. When it constructs the offer, it does not know where it >> going and based on the answer, the right thing will happen. >> >> >> So, I think you have elided some of the steps in this process because >> you presume we share an understanding. I'm really serious that I want >> this unpacked, because I think there's been a lot of talking past each >> other (no doubt some of it from me) > > > Fair enough > > >> What you've written says the offer is going to a "webrtc compliant >> browser", but the webrtc system is a compound of a browser and a >> specific downloaded javascript application. Can you unpack whether this >> offer is going to a downloaded javascript application *built to work >> with the telepresence system*? For example, a company manufacturing >> hardware telepresence systems could market a general web-based >> conference system that interworked with it-*if you used their specific >> downloaded javascript app*. > > > It could be either. > > CLUE is being designed to interop with "legacy" sip endpoints. A clue client > will send an offer that will downgrade to vanilla SIP if the other end > doesn't understand the clue specific stuff. > > But the interesting case is where the web server for the target intends to > support clue - providing suitable javascript so that the browser can do the > clue stuff. > > >> If that's not meant to be sharing resources at the same time as other >> apps, it's not very different than a browser than can load a Hangout or >> start a Webex app now (You'll remember we actually even mixed those two >> apps at the Stockholm interim--by not mixing the resources). But if it >> works that way, the question of how to detect whether the downloaded >> javascript application supports CLUE or not seems to be answered--you >> know because you know what app is downloaded, right? > > > The issue is the SDP stuff that is wired into the rtcweb browser machinery. > Specifically, if rtcweb has one way to indicate the use of plan B, via MSID > that identifies a MediaStreamTrack, and clue uses something else to indicate > use of plan B and to bind a capture-encoding to an SSRC, then we have a > problem. > > Maybe the answer is that CLUE needs to use MSIDs. But we first need to > ensure that the semantics are right. Clue doesn't have media stream tracks. > Maybe we will sort out the equivalences via the taxonomy, but that is moving > along very well. [MB] I think you meant to say"..but that is NOT moving along very well." I do not believe we can make any statements as to how CLUE identifiers map to MSIDs without doing that taxonomy. Of course, given that this discussion is happening entirely on the RTCWEB mailing list as opposed to MMUSIC or even AVTEXT, which is where we've agreed that the taxonomy work will happen, means that we don't have the right people to make this decision nor is any conclusion that might occur on this list relative to CLUE and RTCWEB meaningful in the CLUE context. I would love it if all the CLUE principles/document authors were on the RTCWEB mailing list and were following these discussions, but honestly given the volume of email on the RTCWEB list, it's not reasonable to expect such. What is reasonable is for folks to take these threads of discussion to the MMUSIC and AVT related mailing lists. [/MB] > > I would hate to require the web server to be getting SDP from the browser > and having to translate it from rtcweb-dialect-sdp to clue-dialect-sdp. > [MB] As an individual, I think that it will be even worse than that, as ISTM that some of the information that CLUE might be sending in the CLUE channel will be sent in SDP in the RTCWEB context. [/MB] > >> If you mean interworking a CLUE telepresence system with an arbitrary >> downloaded javascript app, I think that's just flat off the table--why >> would pokerstars want to support CLUE? > > > Only in the "legacy" sense I mentioned above, and then only if the > javascript is intended to support legacy sip. > > >> I have the strong feeling I'm missing something obvious here, which >> would make it great if we could speak in long, slow sentences with short >> words. > > > Does the above help? > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Mon May 13 10:10:34 2013 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 2ED6321F9360 for ; Mon, 13 May 2013 10:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2MlJcIR8rS6 for ; Mon, 13 May 2013 10:10:28 -0700 (PDT) Received: from blu0-omc1-s2.blu0.hotmail.com (blu0-omc1-s2.blu0.hotmail.com [65.55.116.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2666421F9344 for ; Mon, 13 May 2013 10:10:28 -0700 (PDT) Received: from BLU169-W82 ([65.55.116.9]) by blu0-omc1-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 10:10:28 -0700 X-EIP: [Nr1GrYLmEg1lCZdfzx3kn+s+y2vm8QSf] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_df8da58f-eea0-4509-8b9f-b4e6e07af02c_" From: Bernard Aboba To: Mary Barnes Date: Mon, 13 May 2013 10:10:26 -0700 Importance: Normal In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 17:10:28.0003 (UTC) FILETIME=[C40F8F30:01CE4FFC] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 17:10:34 -0000 --_df8da58f-eea0-4509-8b9f-b4e6e07af02c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > [MB] I think you meant to say"..but that is NOT moving along very well." = I do not believe we can make any > statements as to how CLUE identifiers m= ap to MSIDs without doing that taxonomy.=20 [BA] MSID has some aspects similar to CLUE identifiers=2C but it is also tr= ying to do some things that are WebRTC-specific. This leads me to wonder w= hether in fact those two aspects couldn't be separated. If an onaddstream = event is thrown when a new SSRC is received=2C the event handler could hand= le WebRTC-specific aspects. If this were done=2C it seems to me that we mi= ght be able to utilize the concept of CLUE capture in both CLUE and WebRTC= =2C and might also get some signaling simplifications in the process. =20 > Of course=2C given that this discussion is happening entirely> on the RTC= WEB mailing list as opposed to MMUSIC or even AVTEXT=2C > which is where we= 've agreed that the taxonomy > work will happen=2C means that we don't have the right people to make > this decision nor is any conclusion that might occur on this list relativ= e > to CLUE and RTCWEB meaningful in the CLUE context. [BA] While I sympathize with the desire to try to segregate discussions by = topic and WG=2C the reality is that this particular WebRTC topic is just on= e "inter-wingled" big ball of string=2C with inter-related RTP/RTCP and SDP= discussions co-mingling with WebRTC and CLUE-specific considerations. Whi= le I know that the orthodox response is that "we don't do architecture (wel= l) in the IETF" if there was ever an argument for a wholistic discussion=2C= it would probably be in a case such as this.=20 > I would love it if all the CLUE principles/document authors were on> the = RTCWEB mailing list and were following these discussions=2C but > honestly = given the volume of email on the RTCWEB list=2C it's not > reasonable to expect such. What is reasonable is for folks to take > these threads of discussion to the MMUSIC and AVT related mailing lists. = [/MB] [BA] While it might be reasonable for folks to take easily characterized is= sues to the MMUSIC or AVTCORE mailing lists=2C I am not sure that discussio= ns over the relative roles of RTP/RTCP and SDP or CLUE capture vs. MSID can= be handled on individual lists. Also=2C there may be a distinction betwee= n what is "reasonable" and what is likely to be "productive" (although I'm = not sure we have enough empirical evidence yet to understand what approache= s are likely to fall in the latter bucket). =20 > [MB] As an individual=2C I think that it will be even worse than that=2C > as ISTM that some of the information that CLUE might be sending in > the = CLUE channel will be sent in SDP in the RTCWEB context. [/MB] [BA] Or even "worser" than that=2C some information that CLUE implementatio= ns might send in RTP or RTCP will be sent in SDP in the RTCWEB context. = = --_df8da58f-eea0-4509-8b9f-b4e6e07af02c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B [MB] I think you mea= nt to say"..but that is NOT moving along very =3Bwell." I do not belie= ve we =3Bcan make any =3B
>=3B statements as to how CLU= E identifiers map to MSIDs =3Bwithout doing that =3Btaxonomy. = =3B

[BA] MSID&= nbsp=3Bhas some aspects similar to CLUE identifiers=2C but it is also tryin= g to do some things that are WebRTC-specific.  =3BThis leads me to wonder whether in fact those two asp= ects couldn't be separated.  =3BIf an onaddstream event is thrown when a new SSRC is received=2C the = event =3Bhandler could handl= e WebRTC-specific aspects.  =3BIf this were done=2C it seems to me that= we might =3Bbe able to util= ize the concept of CLUE capture in both CLUE and WebRTC=2C and might also g= et =3Bsome signaling simplif= ications in the process.  =3B

>=3B Of course=2C given that this discussion i= s happening entirely
>=3B on the RTCWEB mailing =3Bl= ist as opposed to MMUSIC or even AVTEXT=2C =3B
>=3B which i= s where we've agreed =3Bthat the taxonomy
>=3B work will happen=2C= means that we don't have the right people to make
>=3B this decision = nor is any =3Bconclusion that might occur on this list relative =3B=
>=3B to CLUE and RTCWEB =3Bmeaningful in the CLUE context.=

[BA] While I sympathize with the desire to try to= segregate discussions by topic and WG=2C the reality is that this particul= ar WebRTC topic is just one "inter-wingled" big ball of string=2C with inte= r-related RTP/RTCP and SDP discussions co-mingling with WebRTC and CLUE-spe= cific considerations.  =3BWhile I know that the orthodox response is th= at "we don't do architecture (well) in the IETF" if there was ever an argum= ent for a wholistic discussion=2C it would probably be in a case such as th= is. =3B

&g= t=3B I would love it if all the CLUE principles/document authors were on
>=3B the RTCWEB mailing list and were =3Bfollowing the= se discussions=2C but =3B
>=3B honestly given the volume of= email on =3Bthe RTCWEB list=2C it's not
>=3B reasonable to expect= such. What is reasonable is for folks to take
>=3B these threads of = discussion to =3Bthe MMUSIC and AVT related mailing lists. [/MB]
=

[BA] While it might be reasonable for folks to take eas= ily characterized issues to the MMUSIC or AVTCORE mailing lists=2C I am not= sure that discussions over the relative roles of RTP/RTCP and SDP or CLUE capture vs. MSID can be handled on indi= vidual lists.  =3BAlso=2C there may be a distinction between what is "r= easonable" and =3B
what is likely to be "productive" (although I'm not sure we have enough em= pirical evidence yet to understand what approaches are likely to fall in th= e latter bucket).  =3B

>=3B [MB] As a= n individual=2C I think that it will be even worse than that=2C
>=3B a= s ISTM that some of the information that =3BCLUE might be sending in&nb= sp=3B
>=3B the CLUE channel will be sent in SDP in the =3BR= TCWEB context. [/MB]

[BA] Or even "worser" than th= at=2C some information that CLUE implementations might send in RTP or RTCP = will be sent in SDP in the RTCWEB context. =3B
<= /body> = --_df8da58f-eea0-4509-8b9f-b4e6e07af02c_-- From bernard_aboba@hotmail.com Mon May 13 10:59:06 2013 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 E7B9A21F9377; Mon, 13 May 2013 10:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6a6f3MrIcJO; Mon, 13 May 2013 10:58:59 -0700 (PDT) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7921F923C; Mon, 13 May 2013 10:58:49 -0700 (PDT) Received: from BLU405-EAS289 ([65.55.116.74]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 10:58:49 -0700 X-EIP: [C1ZSRuta2/no7ZqncPt4qV90Wo440ztx] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> Date: Mon, 13 May 2013 10:58:49 -0700 To: =?utf-8?Q?Stefan_H=C3=A5kansson_LK?= X-OriginalArrivalTime: 13 May 2013 17:58:49.0273 (UTC) FILETIME=[855A3A90:01CE5003] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 17:59:07 -0000 DQoNCk9uIE1heSAxMiwgMjAxMywgYXQgMTA6MTgsICJTdGVmYW4gSMOla2Fuc3NvbiBMSyIgPHN0 ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPj4gSSB3b3VsZCBob3Bl IHRoZXJlIHdpbGwgbm9ybWFsbHkgbm90IGJlIFNEUCBjaGFuZ2VzIGZvciBlaXRoZXIgb2YgdGhv c2UNCj4+IGV2ZW50cy4NCj4gDQo+IEkgd291bGQgbGlrZSB0byBhdm9pZCB0aGVtIHRvbywgYnV0 IEknbSBub3Qgc3VyZSBob3cuDQoNCltCQV0gSXQgaXMgcHJvYmFibHkgbm90IHBvc3NpYmxlIHRv IGF2b2lkIHRoZW0gaW4gYWxsIGNhc2VzLCBidXQgd2UgY2FuIGRlZmluZSBSVENQIGZ1bmN0aW9u YWxpdHkgd2hpY2ggYWxvbmcgd2l0aCBzb21lIHNldCBvZiBmdW5jdGlvbmFsaXR5IChlLmcuIFNp bXVsY2FzdCwgbGF5ZXJlZCBjb2RpbmcpIHdpbGwgbWluaW1pemUgdGhlbS4gVGhpcyBpcyB3b3J0 aCBkb2luZyAoYW5kIHNvb24pLg== From martin.thomson@gmail.com Mon May 13 13:24:59 2013 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 5511721F85F4 for ; Mon, 13 May 2013 13:24:59 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X49-QKSKTfuS for ; Mon, 13 May 2013 13:24:58 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5F721F8574 for ; Mon, 13 May 2013 13:24:58 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hn14so995484wib.2 for ; Mon, 13 May 2013 13:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Tt3PrbcSluckvHVeZum5oZoF1SC+K3e0ocMwoGdGosg=; b=V43xMQH4nWBztmKNzgZXt6Pfr7cf6T88XQaR4imOTpLj6lFzNOJWTGUsUBcA6jzbAf moSCi3Xrw00MhBm6AzGz/8cimfZviojSFA+JFSgUsb/Sa8MtyMDxUALR1L47go32SSLu HkSqp9cH2ho8xbg31zfzH624OZqlQw2bqDNOJV/LgFNeKvkKGM2MnMdxz3fAor0aSRj7 CNM1kUMa8w1TN70pe5ym4kouONXIMGJ6U56Qg0d6R0uiSz5uk+Ft65lQMh6twgOXi2q/ ymTAahFYT0Iqn3Ik47k2Mcg2B1nRMvMoiq8fwihQP9KNu5AopX02JmWvWPg+k0wC1maJ bbZQ== MIME-Version: 1.0 X-Received: by 10.180.212.3 with SMTP id ng3mr22318732wic.22.1368476697453; Mon, 13 May 2013 13:24:57 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 13 May 2013 13:24:57 -0700 (PDT) In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> Date: Mon, 13 May 2013 13:24:57 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 20:24:59 -0000 On 11 May 2013 14:08, Bernard Aboba wrote: > Paul Kyzivat said: > >> I don't have a specific action to recommend here. This just seems like a >> somewhat fundamental shift that out to be recognized. It probably isn't >> just RTCWEB and CLUE, it is really related to more complex communication >> scenarios. ISTM that CLUE is addressing this by building a layer on top >> of O/A, while RTCWEB is *battling* with O/A. > > [BA] IMHO, the distinction between CLUE and RTCWEB may not be that clear > cut, and so the issues (and considerations) that arise in CLUE may also come > up in RTCWEB, although they may not be recognized as such. I think that the following statement - if true - would be key: WebRTC defines an API that I can use to implement CLUE. I would like that statement to be true. That is why I find the following just as disturbing as Bernard: > This is why I find it disturbing for WebRTC and CLUE RTP usage documents to > come to different conclusions about required RTP functionality *for similar > scenarios*. For example, I do not think that the concept of MSID and CLUE > capture are all that different, so that I do not buy that supporting each of > these concepts require different solutions. So if we are debating whether an > RTP extension (or SDES item) is needed to indicate the CLUE capture to which > an RTP flow pertains, then I would assert that the same logic would apply > (or not apply) to msid. From martin.thomson@gmail.com Mon May 13 13:35:58 2013 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 17ED821F91BF for ; Mon, 13 May 2013 13:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoci6xUN8G6l for ; Mon, 13 May 2013 13:35:57 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6770321F8BBA for ; Mon, 13 May 2013 13:35:57 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so3379384wib.16 for ; Mon, 13 May 2013 13:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=lH7l4sjWQv1UX4zaLfQprBp85z8nr1+3vg6tqfhWlA0=; b=hjXpGKpOuHgo4zcjxEUGrRAp/kj0kIXI7oxWZaO62alDdkDo6zhpbNQGrdwisfSiMS iudyP30CtC+euGh7xdZdTnrcuJxl/rqIM5gZHgcTOKHJZIGoiyZ0XMjFK7skxdK0ZvCA P6pR8eWxy3FumrPzY9LqCK2Vxa5pamjzwNl/kRrCqKoCRVzD0UzrNyt9G2/onjJfcy5m w0VO7PeTtmfJDWq9e9DGIn0lMARP8/+9R4BKrRKdc5tlY8sXou92eG895TWjOfXn7n9B CxURd9HRXJRkIyI3Ike1QX8L6yVlghW5Gfil36GII4kLRJ3dpNMp++qBx17e1ZBnF0FE ZeBA== MIME-Version: 1.0 X-Received: by 10.180.212.3 with SMTP id ng3mr22394784wic.22.1368477352728; Mon, 13 May 2013 13:35:52 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 13 May 2013 13:35:52 -0700 (PDT) In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> Date: Mon, 13 May 2013 13:35:52 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 13 May 2013 20:35:58 -0000 On 12 May 2013 22:22, Justin Uberti wrote: > On Sat, May 11, 2013 at 5:20 AM, Stefan H=C3=A5kansson LK > wrote: >> >> As I read draft-uberti-rtcweb-plan-00, no API changes are needed or >> proposed, and the call flows could stay the same (but as I recollect the >> discussion at the Boston interim they should be changed for other >> reasons). >> > The sole API change that is proposed is the new .content property, to all= ow > a MST to have its a=3Dcontent property set, and as such be placed on its = own > m=3D line. The rest works using the existing APIs; the necessary a=3Dremo= te-ssrc > lines can be generated (to enable or disable a stream) based on whether a > received MST is hooked up to an output or not. [...] On 11 May 2013 07:14, Eric Rescorla wrote: > I believe that both Plan A and Plan B require at least one change to > the API: the ability to indicate that a stream is important and thus > requires backward-compatible treatment. In Plan A this means > not marking it bundle-only. In Plan B it means putting it on its own > m-line. The .content property in Plan B goes some way to addressing this need, but it does nothing to provide control over which of the tracks are selected from the set that are on the same m-line in the backwards-compatibility mode. Neither option makes addressing simulcast streams easy for this case. From juberti@google.com Mon May 13 17:31:39 2013 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 7358121F882A for ; Mon, 13 May 2013 17:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.228 X-Spam-Level: X-Spam-Status: No, score=-100.228 tagged_above=-999 required=5 tests=[AWL=1.749, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPn5xMZnBnWE for ; Mon, 13 May 2013 17:31:38 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id AF50C21F84F8 for ; Mon, 13 May 2013 17:31:37 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id l27so2459614iae.39 for ; Mon, 13 May 2013 17:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ScTWlwqT6Af7cf9XxkFgkt4RscZDDZfgPNlQMWX7QtY=; b=TGZ7+1vcniWfYCQ0XV7h/nETJOOIf3nKc6XnT6j7sPjmlaT67P//d4BSOJmUtnDaBD JyPLmBiLAWL9+6iCmP4lGOKbeY+v3uXEazkSl7qwV4l7W6syBHNsPBlmltoSU93IE+B9 IirOEIXKqOTf/XmMnMkvTPGBx/SOsO1oWrFU3BXCNJXtjTz0rwV9nWPBow80jv2C4/eQ 8PwdcwKN2H6t6fqVnUwOPBlKKdUxHmjbo/edThl+/AkJ/QfUnrP1TEJ8yn4WyGvVkKt4 gzKUOFIulGnypjsYfuV6epsG6OMI76itROE2sN4c8054DmM12RrMrkDz8B5b+nasOHq9 qO6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ScTWlwqT6Af7cf9XxkFgkt4RscZDDZfgPNlQMWX7QtY=; b=GKgcqOaAvPwRZPJofs/vsdVM6SFAZHt99grHdRVGK7ylFJYZMgWS5llAY/NAapoWNU 4R7HEQwuDnU/5hqyHekAcalY9ZV3DWxKAT9RCxKDbl0xzBpRh/6Rp6gwaKw8yCYue9Oj fahldP9VQZ+36t0/tdTKxa8Vo0G8yYIv9kxmpnq5xVF+r+J0Q3zKfziZaCxkAB+pYkGT pG96/FiDWEVGWBQQt359k9N11l3LBliYJPMy4GMuRTGfs/qM/C/FitXt3TEJ9JWV9RzZ ENGktH6iuoEQWEJGmbSna94i+gXDTWT+phHteC5I54UwGrd8hd3O1F4DZWqc590JTbOg 4uiw== X-Received: by 10.50.117.101 with SMTP id kd5mr453619igb.12.1368491497237; Mon, 13 May 2013 17:31:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Mon, 13 May 2013 17:31:17 -0700 (PDT) In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> From: Justin Uberti Date: Mon, 13 May 2013 17:31:17 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e011826f892467804dca2c1af X-Gm-Message-State: ALoCoQmP5BWnEzzN3PIHZS83+QWRLHYUi0FzzCT/MK6PmDqKG+wu9jv7aCC5+gn/1WjZPPI4R0IS0kHJrzhMlro8FiINbsC8snINbBOTr13MCss+MzpjYk8FHRq8vjxi96Ox0le2V8c1tVBv4cxYIsHePhDjZO8aRJomscZYwWV0DLNEi580Kuse3YE4/8w8/i8m0Wx9gt2I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 00:31:39 -0000 --089e011826f892467804dca2c1af Content-Type: text/plain; charset=UTF-8 On Mon, May 13, 2013 at 1:24 PM, Martin Thomson wrote: > On 11 May 2013 14:08, Bernard Aboba wrote: > > Paul Kyzivat said: > > > >> I don't have a specific action to recommend here. This just seems like a > >> somewhat fundamental shift that out to be recognized. It probably isn't > >> just RTCWEB and CLUE, it is really related to more complex communication > >> scenarios. ISTM that CLUE is addressing this by building a layer on top > >> of O/A, while RTCWEB is *battling* with O/A. > > > > [BA] IMHO, the distinction between CLUE and RTCWEB may not be that clear > > cut, and so the issues (and considerations) that arise in CLUE may also > come > > up in RTCWEB, although they may not be recognized as such. > > I think that the following statement - if true - would be key: > > WebRTC defines an API that I can use to implement CLUE. > > I would like that statement to be true. > That is also how I have been looking at the situation. > > That is why I find the following just as disturbing as Bernard: > > > This is why I find it disturbing for WebRTC and CLUE RTP usage documents > to > > come to different conclusions about required RTP functionality *for > similar > > scenarios*. For example, I do not think that the concept of MSID and > CLUE > > capture are all that different, so that I do not buy that supporting > each of > > these concepts require different solutions. So if we are debating > whether an > > RTP extension (or SDES item) is needed to indicate the CLUE capture to > which > > an RTP flow pertains, then I would assert that the same logic would apply > > (or not apply) to msid. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e011826f892467804dca2c1af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 13, 2013 at 1:24 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
On 11 May 2013 14:08, Bern= ard Aboba <bernard_aboba@ho= tmail.com> wrote:
> Paul Kyzivat said:
>
>> I don't have a specific action to recommend here. This just se= ems like a
>> somewhat fundamental shift that out to be recognized. It probably = isn't
>> just RTCWEB and CLUE, it is really related to more complex communi= cation
>> scenarios. ISTM that CLUE is addressing this by building a layer o= n top
>> of O/A, while RTCWEB is *battling* with O/A.
>
> [BA] IMHO, the distinction between CLUE and RTCWEB may not be that cle= ar
> cut, and so the issues (and considerations) that arise in CLUE may als= o come
> up in RTCWEB, although they may not be recognized as such.

I think that the following statement - if true - would be key:

=C2=A0 WebRTC defines an API that I can use to implement CLUE.

I would like that statement to be true.

That is also how I have been looking at the situation.

That is why I find the following just as disturbing as Bernard:

> This is why I find it disturbing for WebRTC and CLUE RTP usage documen= ts to
> come to different conclusions about required RTP functionality *for si= milar
> scenarios*. =C2=A0For example, I do not think that the concept of MSID= and CLUE
> capture are all that different, so that I do not buy that supporting e= ach of
> these concepts require different solutions. So if we are debating whet= her an
> RTP extension (or SDES item) is needed to indicate the CLUE capture to= which
> an RTP flow pertains, then I would assert that the same logic would ap= ply
> (or not apply) =C2=A0to msid.
_____________________________= __________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e011826f892467804dca2c1af-- From juberti@google.com Mon May 13 17:37:24 2013 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 CC1E721F8605 for ; Mon, 13 May 2013 17:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.102 X-Spam-Level: X-Spam-Status: No, score=-101.102 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIZphIVMJ5X0 for ; Mon, 13 May 2013 17:37:23 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6E62121F85E8 for ; Mon, 13 May 2013 17:37:21 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id i9so4204391iad.23 for ; Mon, 13 May 2013 17:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=a+3zuANDyA3usKF0mEh8pae2Nuxq9fCcGB18WQmJCIA=; b=JIubuPklhLrHjtOoYeRWXjD6v1la/S9MMOFU+CWbOgMkK7oirpxdtKxl3gjZwTFw8l y1PXD71h45rDZDvFndLm921SokHdaE9nMe9NCpf7yZ6t9/s43jmrGCdmKyveT/M7lZbX AzUE8U54BMNlhT0roWvknufRvjlP8rDs14QF9EFUf35tPGwafivUR4meBF8L8og0ALa+ QwbJEXZUzwfUledmc46in++kLZavaUhTMoiywAvQPk6PdWLsRZL5lY54AJ7ZoTAqWxbm PWWE3a4Fm+CvKosvifS9HKg+ExENawP4PIzGYyylAV4/90KNRlsVfAEqfs0rO9c6a2Pf v8xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=a+3zuANDyA3usKF0mEh8pae2Nuxq9fCcGB18WQmJCIA=; b=QD23rGz79dh1aCMjKuyeTIP5sgXf1DkBbakEceWZtO0rG6kvUn4pdyK5n9vDikdEQd J+EgSoN/brOoPuGP1Vkji8e16IHy4da8oWb5GElq3sxXa+cU2z7y/7DCoXgZMdcdI+B7 bU0O5+67USi28XgZ4f6DRwbaSBLvH8UJp1lumgIv1e9+zMKGKuenos6RTH9G8uS28RKL 8K6e2alvpBn/uPW5yguHBfo5rc/21QUpagpFjIIeD/or2QOaI3yGrFpQdXEjDOScT9lR 4HsCTCYuO3vXdfifKzxpl3WKI/1BfaGB2Dz4oUv53kdqE3pAJGheWy+O30fMe7lKKGP0 icDQ== X-Received: by 10.50.136.199 with SMTP id qc7mr420008igb.42.1368491841046; Mon, 13 May 2013 17:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Mon, 13 May 2013 17:37:00 -0700 (PDT) In-Reply-To: <518F67E1.3040205@jitsi.org> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> <518F67E1.3040205@jitsi.org> From: Justin Uberti Date: Mon, 13 May 2013 17:37:00 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=089e0139fb4210563d04dca2d653 X-Gm-Message-State: ALoCoQmig3KV77mJkLXfbyxG+i4Q0nJ7EZB9Br1ZL5LHEHJ8lzuqy7na4qMy9ZGSQTPYDi2+PPl5eE7e8FO1250Eunlt1TTNHe7J5FK/VqAG48m5VLADaaYYPUC0cqVXM0LZRt+kGT2DShVMmbhQEvY8jy9e7t51BxuTI449PZ+hbXg3gPBVpNgw4pft7MYZpKOcfCkCGG/G Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 00:37:24 -0000 --089e0139fb4210563d04dca2d653 Content-Type: text/plain; charset=UTF-8 On Sun, May 12, 2013 at 2:58 AM, Emil Ivov wrote: > > > On 11.05.13, 19:51, Paul Kyzivat wrote: > > I don't have a specific action to recommend here. This just seems like a > > somewhat fundamental shift that out to be recognized. It probably isn't > > just RTCWEB and CLUE, it is really related to more complex communication > > scenarios. ISTM that CLUE is addressing this by building a layer on top > > of O/A, while RTCWEB is *battling* with O/A. > > That's a nice way to put it. Interestingly the CLUE approach to take > this out of O/A seems to be more in line with the RTCWEB paradigm than > both Plan A or Plan B. > > The decision not to implement an official signalling RTCWEB protocol was > taken very early in this working group and there was very strong > consensus on the fact that imposing a specific signalling protocol would > be incompatible with the web in general. > > Still, it seems to me that we are now trying to compensate for the lack > of such a signalling protocol by piggybacking on top of O/A and SDP with > things such as the possibility to turn off individual SSRCs. > > Why do we need these things? Aren't they better handled by the API? > The same could be said for anything currently handled by SDP, it could be better handled by a JS-friendly API. I don't see anything special about turning on individual streams though. IOW, if SDP is the surface we use to communicate information to the other side, then it is de facto the best fit for these stream requests. --089e0139fb4210563d04dca2d653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, May 12, 2013 at 2:58 AM, Emil Ivov <emcho@jitsi.org><= /span> wrote:


On 11.05.13, 19:51, Paul Kyzivat wrote:
> I don't have a specific action to recommend here. This just seems = like a
> somewhat fundamental shift that out to be recognized. It probably isn&= #39;t
> just RTCWEB and CLUE, it is really related to more complex communicati= on
> scenarios. ISTM that CLUE is addressing this by building a layer on to= p
> of O/A, while RTCWEB is *battling* with O/A.

That's a nice way to put it. Interestingly the CLUE approach to t= ake
this out of O/A seems to be more in line with the RTCWEB paradigm than
both Plan A or Plan B.

The decision not to implement an official signalling RTCWEB protocol was taken very early in this working group and there was very strong
consensus on the fact that imposing a specific signalling protocol would be incompatible with the web in general.

Still, it seems to me that we are now trying to compensate for the =C2=A0la= ck
of such a signalling protocol by piggybacking on top of O/A and SDP with things such as the possibility to turn off individual SSRCs.

Why do we need these things? Aren't they better handled by the API?
=

The same could be said for anything = currently handled by SDP, it could be better handled by a JS-friendly API. = I don't see anything special about turning on individual streams though= .

IOW, if SDP is the surface we use to commun= icate information to the other side, then it is de facto the best fit for t= hese stream requests.
--089e0139fb4210563d04dca2d653-- From emil@sip-communicator.org Mon May 13 22:56:57 2013 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 EDC8321F8AA6 for ; Mon, 13 May 2013 22:56:57 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGKClc3CorVq for ; Mon, 13 May 2013 22:56:57 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 007C321F8A7B for ; Mon, 13 May 2013 22:56:56 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg9so57741bkc.6 for ; Mon, 13 May 2013 22:56:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=iGxeaG06oMLtdlWJBfRnvP0DDxj2nLdfyclI/9GtExA=; b=HxOCYa9TffFL3PHfurZ3/UnKrr7qVtJlFpN1lg1NoZcvjbRciu1/fnHlHDHSSc8WFR sodiA94nrIhNHZfVbCU1533ROeOqFU0776B4tSyR95oEtplG0mrC4Yvx/jIUiztsZc++ 6aUF5ztc6MQk1uyenqsqX5Bc3kwsOGPkWH5tJCMHvSLnuiNGZz/DK3irCrP+xEUP/Yb9 LzIHvhNY5ntq57Gp/fttVuAbsOxXf94dEGTf188dpLBMTRp+4KtTi3Qvnr6KZU/IcDYM b6sFRK1wX0MWOtiXLYG806deElU65i8lT9PgpiQ4agc4BtdmRfiXUh0pvTNpJ6ngV4G8 BaRg== X-Received: by 10.204.231.198 with SMTP id jr6mr6785829bkb.104.1368511015569; Mon, 13 May 2013 22:56:55 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id fz10sm3053004bkc.9.2013.05.13.22.56.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 22:56:54 -0700 (PDT) Message-ID: <5191D225.5070301@jitsi.org> Date: Tue, 14 May 2013 08:56:53 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Uberti References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> <518F67E1.3040205@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmMNEQB/MdzT5Tf/5yJjd7XoyhgGVkUyr0ba1EFRLzP8xpHWv4s3gdogb4Fj7Qt6xW8B/s6 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 05:56:58 -0000 On 14.05.13, 03:37, Justin Uberti wrote: > > On Sun, May 12, 2013 at 2:58 AM, Emil Ivov > wrote: > > Still, it seems to me that we are now trying to compensate for the lack > of such a signalling protocol by piggybacking on top of O/A and SDP with > things such as the possibility to turn off individual SSRCs. > > Why do we need these things? Aren't they better handled by the API? > > > The same could be said for anything currently handled by SDP, it could > be better handled by a JS-friendly API. Right, and we chose to use SDP O/A, in spite of its shortcomings, for interoperability reasons. > I don't see anything special > about turning on individual streams though. The difference is that this is no longer a choice driven by interoperability. All those applications that we wanted WebRTC clients to easily talk to and that we sometimes refer to as legacy or Pre-WebRTC, well they rarely support individual stream control. Those that do, implement it without using SDP. > IOW, if SDP is the surface we use to communicate information to the > other side, then it is de facto the best fit for these stream requests. SDP is not going to be the only surface we use to communicate information to the other side. We'll always have another layer of WebSocket signalling and we'll always have RTCP. Emil -- https://jitsi.org From emil@sip-communicator.org Mon May 13 23:16:40 2013 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 BE31021F90AC for ; Mon, 13 May 2013 23:16:40 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA9xWpvzpoth for ; Mon, 13 May 2013 23:16:39 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C75621F8FEB for ; Mon, 13 May 2013 23:16:38 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg9so65082bkc.6 for ; Mon, 13 May 2013 23:16:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=VuSfM7XcriWZ0KQzGcl/iJ2vr2s2mnwp9bQww8cBXUk=; b=YUDAoET1FZ4jQuE6U4cVWGklTargN49ZfRrlZub3DtU6Jk8xaGj/qEqgUQoF86ofnn KRn3AITm30TcQ9xDz0bB32xCh3OgU5OHOVzhcoCulMgT2u8OQvdKrOOi4v5h4yOrhfmn xyawKOyuIWDD85C7gE0aJP5URXaCltSNS4q+w4O9ZrtB5KXUHQNk1BA2inkvgyxHWdek dbJtBo1DPLk8+DBmHKPGK8BrTVsLPHrzgq8eZ6MTozPZtUCISMjHd2S8i8AeLWjhuhZR Hd0gEn5BnjKqcDczV6LCX7BB02kFY2/ZH9zGKYvFR8hR0vYjOxVLpgqTCDLtXwk+AKCG Z+kA== X-Received: by 10.204.175.198 with SMTP id bb6mr6908633bkb.9.1368512196985; Mon, 13 May 2013 23:16:36 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id jm15sm3068614bkb.13.2013.05.13.23.16.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 23:16:36 -0700 (PDT) Message-ID: <5191D6C3.4090604@jitsi.org> Date: Tue, 14 May 2013 09:16:35 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> In-Reply-To: <518FF3AE.4050505@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnxwU387h57FICWVZhtSIh5qCCUoiQCTm33pujO03q8KtXheMQ6ntRDqKrFQuQUIrISFSLA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 06:16:41 -0000 Hey Harald, On 12.05.13, 22:55, Harald Alvestrand wrote: > On 05/12/2013 06:03 PM, Emil Ivov wrote: >> >>> Or you could signal none of them and depend on the fallback case in >>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>> use other methods to figure out how to handle them... >> >> If you are referring to section 4.1 that you also pasted earlier in >> this thread, it only talks about one track, per stream, per m= line. >> This doesn't cover the conferencing case I described in my previous >> mail (quoted above). >> > Changing subject as I'm replying to a subtopic, and because I was > misunderstanding what Emil was arguing in favour of..... > > when I wrote that text, I didn't intend it to cover only one SSRC per > stream. > What I intended to say was that when, in an RTP session, a browser gets > several SSRCs that were not mentioned in signalling, it will send > several onaddstream signals to the application, each indicating a new > stream being added, which has exactly one track. Aha! OK, I understand and it sounds better now that I do. That's only half of it though. We would also need ways in the API to control these streams if we weren't using SDP O/A. Incidentally, when people have tried this with Chrome it didn't work as described above and the unannounced SSRCs were handled in unpredictable ways. I suppose this is just a matter of time and that the implementation would eventually get there? > If the language doesn't > say that, I need to change it. Well obviously I hadn't understood but that might be just me. Incidentally, we might want to replace Pre-WebRTC with Non-WebRTC or something similar. Applications that don't aggressively rely on SDP O/A for stream control are not necessarily a thing of the past. Emil -- https://jitsi.org From stefan.lk.hakansson@ericsson.com Tue May 14 01:24:33 2013 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 C0EB121F8F7A; Tue, 14 May 2013 01:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU1giYeyIDB0; Tue, 14 May 2013 01:24:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3521F853A; Tue, 14 May 2013 01:24:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-ea-5191f4b8aeeb Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 45.18.28165.8B4F1915; Tue, 14 May 2013 10:24:25 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 10:24:24 +0200 Message-ID: <5191F4B8.2020602@ericsson.com> Date: Tue, 14 May 2013 10:24:24 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Bernard Aboba References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3Vnfnl4mBBmdesVrsX3KZ2WLq8scs Fmv/tbM7MHs87jnD5rFkyU+mAKYoLpuU1JzMstQifbsEroy//dcYC3axVBx/f4mxgXEfcxcj B4eEgInEvcUyXYycQKaYxIV769m6GLk4hAROMUosOP8BylnLKNHQO48VpIpXQFvi5+mbjCA2 i4CqxIqT3UwgNptAsMT+5SDdnByiAlES/97uZoSoF5Q4OfMJC8gyEQFdib9dRiBhZgF/iXNX 9oOVCAt4S2zbsJAZYtdjZokrs1+xgyQ4BWwlfuztYoJosJBY/OYgO4QtL9G8dTYziC0ENPPd 63usExgFZyFZNwtJyywkLQsYmVcxsucmZuaklxtuYgQG58Etv3V3MJ46J3KIUZqDRUmcN4mr MVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY1vFIc/Yx91qr89cN5Qzc0g9IVe17vTyGUeC Iz72PMvcdkk5ctm86fx3F2s5XVwxMajDstmk3LnoZla3jazi5tTo3a1K737OEnp/ye57d8pO pimX+hd/ic2V1vk91di7JD45RTCKYcaFpOv7k1Z/DueKL90reYEtoSzoZQffcpvKQ8fycjP7 lViKMxINtZiLihMBk+7HTxwCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:24:33 -0000 On 2013-05-13 19:58, Bernard Aboba wrote: > > > On May 12, 2013, at 10:18, "Stefan HĆ„kansson LK" > wrote: > >>> I would hope there will normally not be SDP changes for either of >>> those events. >> >> I would like to avoid them too, but I'm not sure how. > > [BA] It is probably not possible to avoid them in all cases, but we > can define RTCP functionality which along with some set of > functionality (e.g. Simulcast, layered coding) will minimize them. > This is worth doing (and soon). I agree to this! > From stefan.lk.hakansson@ericsson.com Tue May 14 01:44:00 2013 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 D489B21F8D69 for ; Tue, 14 May 2013 01:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArgeoTEyI2te for ; Tue, 14 May 2013 01:43:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3636521F8F83 for ; Tue, 14 May 2013 01:43:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-6c-5191f94960f2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DB.44.32006.949F1915; Tue, 14 May 2013 10:43:53 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 10:43:53 +0200 Message-ID: <5191F948.3040402@ericsson.com> Date: Tue, 14 May 2013 10:43:52 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvra7nz4mBBj1vRSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsp3E1gKdvFXbDz2kb2BcT5PFyMnh4SAicTDmw/YIWwxiQv3 1rN1MXJxCAmcYpR4NW0VM4SzllFizuoNLCBVvALaEitO7GcEsVkEVCU+n1/ABGKzCQRKXP// C8wWFYiS+Pd2NyNEvaDEyZlPwHpFBIQltr7qBasRFgiS+LLgHiPEglmsEg8XzAM6g4ODU8BK 4sTnKpAaZgFbiQtzrrNA2PIS29/OYQaxhQR0Jd69vsc6gVFgFpIVs5C0zELSsoCReRUje25i Zk56udEmRmCgHdzyW3UH451zIocYpTlYlMR5k7kaA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUw1su82q8vMGtC3cN97xKXcDNNmhqaGn9uNQuPqcLxFlk5058GxQ3BGpNWZB88kxn7Wk/x UPqm+sKK5wqLg728NOWlbRd+zlCTKprz3cZxBTN7Ucv8XQGbFdvuJkZYl/utTUvesYyBjzM5 pu9mk2xkbnSS0RLbJW66dqki39bK+rF0ZE2Z3K/EUpyRaKjFXFScCADspa5zAgIAAA== Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:44:00 -0000 On 2013-05-13 19:10, Bernard Aboba wrote: > > [MB] I think you meant to say"..but that is NOT moving along > very well." I do not believe we can make any > > statements as to how CLUE identifiers map to MSIDs without doing > that taxonomy. > > [BA] MSID has some aspects similar to CLUE identifiers, but it is also > trying to do some things that are WebRTC-specific. This leads me to > wonder whether in fact those two aspects couldn't be separated. If an > onaddstream event is thrown when a new SSRC is received, the event > handler could handle WebRTC-specific aspects. If this were done, it > seems to me that we might be able to utilize the concept of CLUE capture > in both CLUE and WebRTC, and might also get some signaling > simplifications in the process. As it looks like now, onaddstream would not be fired as a result of a new SSRC being received, but rather as a result of an SDP (offer or answer) informing the browser of the new SSRC. (Of course there is an escape mechanism that handles this if the offer or answer contains no SSRC info to be able to handle legacy). I think signaling of some kind is needed - how would the browser otherwise know whether the new SSRC represents a new MediaStream, a new MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for an already set up track? But, exactly how the signaling is made can be discussed (and I guess that is what we're doing now). And, I am always fond of simplifications! A perhaps very naive thought: could we separate things up a bit? E.g. something like: * Description and negotiation of codecs, PTs, SSRCs - this would be SDP * Description of how those SSRCs map to a MediaStream+MediaStreamTrack structure // Clue captures * Handling of in session changes (pause/resume, resolution changes) Perhaps not all of the above should be done using SDP O/A, and perhaps we should not push all the functionality into the "core" SDP. From emil@sip-communicator.org Tue May 14 01:59:43 2013 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 A64A921F90B9 for ; Tue, 14 May 2013 01:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3gs4YN4U9N4 for ; Tue, 14 May 2013 01:59:42 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 13AFC21F90B3 for ; Tue, 14 May 2013 01:59:41 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id ik5so147750bkc.37 for ; Tue, 14 May 2013 01:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=xadb48yZZsVyIub9cHAhysZ/eS6G0HpdmG0X7LQ4gxY=; b=ZCA4zs2NMvSLzCZ5Xge89xlTxrxcXmTXD904pmj2dyVoIOeXXEDQzJ1c4JKXtyQKRV BI5NH8tqXslTzuArzpB7egyF8yQymLKaeiURXollmf8GDLHIF7zlOywyZdTQlHl+PnsZ fBPOWCvyZXnzjVdd1dkqDs5s0rSli8+hOg+ENG5rzIUG0lAm9HOElO4vimR8SuR5Ixij FGgZ9InH/wpMgkyKVwRqjPT//ukVBrGlyEcerj1AFysT8H7lGCBt3SBA3+ET2EUxbSoU sGlWm2ZgsLCoZIUtnaxztlwZFGFHsaU3QSVLpL+J2AeWUvrplz5JzLax0iYZf2985MG6 smyg== X-Received: by 10.204.163.130 with SMTP id a2mr7135492bky.62.1368521980860; Tue, 14 May 2013 01:59:40 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id tc9sm3257000bkb.18.2013.05.14.01.59.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 01:59:39 -0700 (PDT) Message-ID: <5191FCFB.3090704@jitsi.org> Date: Tue, 14 May 2013 11:59:39 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> In-Reply-To: <5191D6C3.4090604@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlpgilNpUIqoLhQTik5zXmdWrQBNcGyIhRWEHxZXTQJEF1CzNR/c9nJfYK3PcNhUfftlcpf Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:59:43 -0000 On 14.05.13, 09:16, Emil Ivov wrote: > Hey Harald, > > On 12.05.13, 22:55, Harald Alvestrand wrote: >> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>> >>>> Or you could signal none of them and depend on the fallback case in >>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>> use other methods to figure out how to handle them... >>> >>> If you are referring to section 4.1 that you also pasted earlier in >>> this thread, it only talks about one track, per stream, per m= line. >>> This doesn't cover the conferencing case I described in my previous >>> mail (quoted above). >>> >> Changing subject as I'm replying to a subtopic, and because I was >> misunderstanding what Emil was arguing in favour of..... >> >> when I wrote that text, I didn't intend it to cover only one SSRC per >> stream. >> What I intended to say was that when, in an RTP session, a browser gets >> several SSRCs that were not mentioned in signalling, it will send >> several onaddstream signals to the application, each indicating a new >> stream being added, which has exactly one track. > > Aha! OK, I understand and it sounds better now that I do. Oh, just thought of something else while reading Stefan's mail: is it really necessary that this should only happen in case no SSRCs have been defined? Why not apply that to any unknown SSRC regardless of whether or not others exist in SDP? The second bullet there talks about a possible race condition but I am not sure I see how this could occur with valid use of O/A. Emil -- https://jitsi.org From emil@sip-communicator.org Tue May 14 02:17:17 2013 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 8931B21F9017 for ; Tue, 14 May 2013 02:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aD9Ku6zHi7F for ; Tue, 14 May 2013 02:17:17 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id AE43D21F8FF2 for ; Tue, 14 May 2013 02:17:16 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id jc3so158560bkc.14 for ; Tue, 14 May 2013 02:17:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=pWZoClTW+zwDJlOSioReaJv9gTI/+j4j8rp8e7VLXcI=; b=T6oXg2ptbXX2tTINJc2SLjrWqg/dwdCpFh09TV1uw5hXq5iyV0JQ/lZyMAhbwoYnFY 7zZ4R/NXkvjk42yZ/K546psh7NaOr/L4e64OIwCtO5F01+gQ8LZ29vZwj7DV+Be6bkMI IX1jgGK35NXLyBhobWlj4uWE3ghaMdBvz3SIozs1FNrc0K6CKeL1vA2cQfFG8mR6W7JN zYFox7EDJHrgV07C9Kt50qlZnQy1XZ2JZz9ljT2BlKHgUECF7wvH7u+y65ybnmitvK65 uaY9Miz0FhCMN7OoV7dU89S3d2rwNQabEryKQXpg+EewcfhDf3ajSz+f0VIKgT243ZFW aFqQ== X-Received: by 10.205.46.193 with SMTP id up1mr7222053bkb.65.1368523035503; Tue, 14 May 2013 02:17:15 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id tl1sm3292819bkb.7.2013.05.14.02.17.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 02:17:14 -0700 (PDT) Message-ID: <5192011A.8030903@jitsi.org> Date: Tue, 14 May 2013 12:17:14 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5191F4B8.2020602@ericsson.com> In-Reply-To: <5191F4B8.2020602@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnQcuJWfX29dG0/aX5CHcikswU7yIerE1uibBMylPdxOgIB3TehnwGah0wX+6r/A0XPr6JI Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:17:17 -0000 On 14.05.13, 11:24, Stefan H=C3=A5kansson LK wrote: > On 2013-05-13 19:58, Bernard Aboba wrote: >> >> >> On May 12, 2013, at 10:18, "Stefan H=C3=A5kansson LK" >> wrote: >> >>>> I would hope there will normally not be SDP changes for either of >>>> those events. >>> >>> I would like to avoid them too, but I'm not sure how. >> >> [BA] It is probably not possible to avoid them in all cases, but we >> can define RTCP functionality which along with some set of >> functionality (e.g. Simulcast, layered coding) will minimize them. >> This is worth doing (and soon). >=20 > I agree to this! RTCP `certainly sounds a lot better than SDP O/A Emil --=20 https://jitsi.org From emil@sip-communicator.org Tue May 14 02:23:15 2013 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 F09D521F9003 for ; Tue, 14 May 2013 02:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyHpDxopE57K for ; Tue, 14 May 2013 02:23:15 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id E988C21F8FFC for ; Tue, 14 May 2013 02:23:14 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id mz1so162704bkb.11 for ; Tue, 14 May 2013 02:23:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=eRD6IhSlXtlyaHREqZHeFLy2ghkGJ1iNYyWNmPsJZbs=; b=dRC5m5LSGBZt0WhtyX/LixnPgy4xPrCpMeUWsMH+Ub8pvouLQJGQjL3nAx7Nm9Fgs5 DkK4Xlnim5T1gIZtIByRsLxAzBTqyvA2BhMqCgia7+5K/JLoUe12M3kQlsxBTDvk6osg meF07BxLNU4uBl6PnMnNQK0YJVqWOarqGrtTP9qOykhLCio0LniI+gIK8iZtYM0A4ipu E0RHxDNRUwK4IzhHt4jx9QddaJUHwTNYpTE/6wOTQRTD7DodCjiBLi1D6sHPNZBhxIy2 UfMgoiqlBE6QhBZmPAbxrfioHKRZCoegComsWiXbA1OOk7e5UxXuFpl3ISp0JS6q7zxz Bs/Q== X-Received: by 10.205.104.138 with SMTP id dm10mr7433856bkc.51.1368523393794; Tue, 14 May 2013 02:23:13 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id tl1sm3301922bkb.7.2013.05.14.02.23.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 02:23:12 -0700 (PDT) Message-ID: <51920280.3080308@jitsi.org> Date: Tue, 14 May 2013 12:23:12 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> In-Reply-To: <5191F948.3040402@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkr+vAckkdDECTRZyJ1CURdHGEzZrXAIHx1TqKFGVFpXn48X6GEyC774j+3zivhnKKLnXxu Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:23:16 -0000 On 14.05.13, 11:43, Stefan H=E5kansson LK wrote: > On 2013-05-13 19:10, Bernard Aboba wrote: >> > [MB] I think you meant to say"..but that is NOT moving along >> very well." I do not believe we can make any >> > statements as to how CLUE identifiers map to MSIDs without doing >> that taxonomy. >> >> [BA] MSID has some aspects similar to CLUE identifiers, but it is also= >> trying to do some things that are WebRTC-specific. This leads me to >> wonder whether in fact those two aspects couldn't be separated. If an >> onaddstream event is thrown when a new SSRC is received, the event >> handler could handle WebRTC-specific aspects. If this were done, it >> seems to me that we might be able to utilize the concept of CLUE captu= re >> in both CLUE and WebRTC, and might also get some signaling >> simplifications in the process. >=20 > As it looks like now, onaddstream would not be fired as a result of a=20 > new SSRC being received, but rather as a result of an SDP (offer or=20 > answer) informing the browser of the new SSRC. (Of course there is an=20 > escape mechanism that handles this if the offer or answer contains no=20 > SSRC info to be able to handle legacy). Hopefully at some point we'd stop dismissing non-reliance on SDP for every single thing as "legacy". > I think signaling of some kind is needed - how would the browser=20 > otherwise know whether the new SSRC represents a new MediaStream, a new= =20 > MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for= =20 > an already set up track? If I understand the MSID draft and Harald's mail correctly, everything would be bubbled up as separate streams and tracks and it will be up to the application to handle them and sync them one way or another. (Keeping in mind that syncing can also be auto-handled by CNAMEs) I believe that option (which works with no default signalling) is one good option. Having a second option that implements a default signalling solution is also a good idea as long as we don't consider that to be the "right way" and refer to the former as the "legacy" catch-all. > But, exactly how the signaling is made can be discussed (and I guess=20 > that is what we're doing now). And, I am always fond of simplifications= ! >=20 > A perhaps very naive thought: could we separate things up a bit? E.g.=20 > something like: >=20 > * Description and negotiation of codecs, PTs - this would be SDP Right! > SSRCs - this would be SDP Again, including SSRCs in SDP O/A is tricky in conferencing scenarios. > * Description of how those SSRCs map to a MediaStream+MediaStreamTrack = > structure // Clue captures > * Handling of in session changes (pause/resume, resolution changes) >=20 > Perhaps not all of the above should be done using SDP O/A, and perhaps > we should not push all the functionality into the "core" SDP. Thank you! :) Emil --=20 https://jitsi.org From harald@alvestrand.no Tue May 14 04:41:18 2013 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 E705821F8F7B for ; Tue, 14 May 2013 04:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDjhN86bYsjb for ; Tue, 14 May 2013 04:41:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AD26921F8F20 for ; Tue, 14 May 2013 04:41:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B69439E18D; Tue, 14 May 2013 13:41:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnfLAWKjs0Qc; Tue, 14 May 2013 13:41:09 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f444:dc63:8cb:d3f4] (unknown [IPv6:2001:470:de0a:27:f444:dc63:8cb:d3f4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8645939E03B; Tue, 14 May 2013 13:41:09 +0200 (CEST) Message-ID: <519222D5.2080404@alvestrand.no> Date: Tue, 14 May 2013 13:41:09 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> In-Reply-To: <5191D6C3.4090604@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:41:19 -0000 On 05/14/2013 08:16 AM, Emil Ivov wrote: > Hey Harald, > > On 12.05.13, 22:55, Harald Alvestrand wrote: >> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>>> Or you could signal none of them and depend on the fallback case in >>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>> use other methods to figure out how to handle them... >>> If you are referring to section 4.1 that you also pasted earlier in >>> this thread, it only talks about one track, per stream, per m= line. >>> This doesn't cover the conferencing case I described in my previous >>> mail (quoted above). >>> >> Changing subject as I'm replying to a subtopic, and because I was >> misunderstanding what Emil was arguing in favour of..... >> >> when I wrote that text, I didn't intend it to cover only one SSRC per >> stream. >> What I intended to say was that when, in an RTP session, a browser gets >> several SSRCs that were not mentioned in signalling, it will send >> several onaddstream signals to the application, each indicating a new >> stream being added, which has exactly one track. > Aha! OK, I understand and it sounds better now that I do. > > That's only half of it though. We would also need ways in the API to > control these streams if we weren't using SDP O/A. > > Incidentally, when people have tried this with Chrome it didn't work as > described above and the unannounced SSRCs were handled in unpredictable > ways. I suppose this is just a matter of time and that the > implementation would eventually get there? Yes - please file a bug; that helps prioritize what gets done first! > >> If the language doesn't >> say that, I need to change it. > Well obviously I hadn't understood but that might be just me. > > Incidentally, we might want to replace Pre-WebRTC with Non-WebRTC or > something similar. Applications that don't aggressively rely on SDP O/A > for stream control are not necessarily a thing of the past. Non-WebRTC sounds good. Or even "applications that don't use MSID for SSRC indications". > > Emil > From stefan.lk.hakansson@ericsson.com Tue May 14 04:44:45 2013 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 E568921F8425 for ; Tue, 14 May 2013 04:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk2BGkezAroF for ; Tue, 14 May 2013 04:44:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 31D2621F8F7B for ; Tue, 14 May 2013 04:44:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-ae-519223a12117 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 33.B3.32006.1A322915; Tue, 14 May 2013 13:44:33 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 13:44:33 +0200 Message-ID: <519223A0.1040908@ericsson.com> Date: Tue, 14 May 2013 13:44:32 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> In-Reply-To: <51920280.3080308@jitsi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Vneh8qRAgxVXjC3W7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyrgw+T9jwQ6ZincrzrA2MO4W62Lk5JAQMJFo 33iBGcIWk7hwbz1bFyMXh5DAKUaJ1Wu6oZy1jBJ/vl1kBaniFdCWaOpfxAZiswioSpydcQvM ZhMIlLj+/xcTiC0qECXx7+1uRoh6QYmTM5+wgNgiAvIS3W2LwGqYBYQlNlxsA4sLCwRJfFlw jxFi2XVWiZ+LXwElODg4BTQlGi9pQNTbSlyYc50FwpaXaN46G+xqIQFdiXev77FOYBSchWTd LCQts5C0LGBkXsXInpuYmZNebrSJERiSB7f8Vt3BeOecyCFGaQ4WJXHeZK7GQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2M856ZzjjYn+vq7JphnaXiJONieJo3vNhr3T7GcHfnORm1PbMb Nt+ftqDy1HMN4U0Zl29wTNNJaygtPPVA8Pdf7pZr6f+YZOSl4lgdK2W6V+tlnav1qXqe1WS3 Tedvltyiu1+Wyk7REEnv8TB+eHMe+9bHYoEOXk9EZ+hdX6SZItC4+beObaoSS3FGoqEWc1Fx IgDxwYSNFwIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:44:46 -0000 On 2013-05-14 11:23, Emil Ivov wrote: > > > On 14.05.13, 11:43, Stefan Håkansson LK wrote: >> On 2013-05-13 19:10, Bernard Aboba wrote: >>> > [MB] I think you meant to say"..but that is NOT moving along >>> very well." I do not believe we can make any >>> > statements as to how CLUE identifiers map to MSIDs without doing >>> that taxonomy. >>> >>> [BA] MSID has some aspects similar to CLUE identifiers, but it is also >>> trying to do some things that are WebRTC-specific. This leads me to >>> wonder whether in fact those two aspects couldn't be separated. If an >>> onaddstream event is thrown when a new SSRC is received, the event >>> handler could handle WebRTC-specific aspects. If this were done, it >>> seems to me that we might be able to utilize the concept of CLUE capture >>> in both CLUE and WebRTC, and might also get some signaling >>> simplifications in the process. >> >> As it looks like now, onaddstream would not be fired as a result of a >> new SSRC being received, but rather as a result of an SDP (offer or >> answer) informing the browser of the new SSRC. (Of course there is an >> escape mechanism that handles this if the offer or answer contains no >> SSRC info to be able to handle legacy). > > > Hopefully at some point we'd stop dismissing non-reliance on SDP for > every single thing as "legacy". > >> I think signaling of some kind is needed - how would the browser >> otherwise know whether the new SSRC represents a new MediaStream, a new >> MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for >> an already set up track? > > If I understand the MSID draft and Harald's mail correctly, everything > would be bubbled up as separate streams and tracks and it will be up to > the application to handle them and sync them one way or another. > (Keeping in mind that syncing can also be auto-handled by CNAMEs) > > I believe that option (which works with no default signalling) is one > good option. Having a second option that implements a default signalling > solution is also a good idea as long as we don't consider that to be the > "right way" and refer to the former as the "legacy" catch-all. > >> But, exactly how the signaling is made can be discussed (and I guess >> that is what we're doing now). And, I am always fond of simplifications! >> >> A perhaps very naive thought: could we separate things up a bit? E.g. >> something like: >> >> * Description and negotiation of codecs, PTs - this would be SDP > > Right! > >> SSRCs - this would be SDP > > Again, including SSRCs in SDP O/A is tricky in conferencing scenarios. Here seems to be something that I have missed. That there are existing implementations that do not signal SSRC is fine, and in most cases there would be only one audio and one video SSRC used anyway. And rtcweb (and Clue?) should be able to interoperate (but perhaps your web app need to be designed in a specific way). But if we design something forward looking, that can handle many streams, that can handle layered codecs and FEC data, signaling SSRCs seems like a must to me. But I have missed that this is problematic in conferencing scenarios, could you tell me why (and I probably should know :) )? > >> * Description of how those SSRCs map to a MediaStream+MediaStreamTrack >> structure // Clue captures >> * Handling of in session changes (pause/resume, resolution changes) >> >> Perhaps not all of the above should be done using SDP O/A, and perhaps >> we should not push all the functionality into the "core" SDP. > > Thank you! :) > > Emil > From harald@alvestrand.no Tue May 14 05:09:06 2013 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 1D14B21F9050 for ; Tue, 14 May 2013 05:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRNxVN80B3bV for ; Tue, 14 May 2013 05:09:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8696C21F901F for ; Tue, 14 May 2013 05:09:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97FDF39E18D; Tue, 14 May 2013 14:08:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CYHFTX6DtjD; Tue, 14 May 2013 14:08:57 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f444:dc63:8cb:d3f4] (unknown [IPv6:2001:470:de0a:27:f444:dc63:8cb:d3f4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8F33339E03B; Tue, 14 May 2013 14:08:57 +0200 (CEST) Message-ID: <51922959.3070708@alvestrand.no> Date: Tue, 14 May 2013 14:08:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> In-Reply-To: <5191FCFB.3090704@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:09:06 -0000 On 05/14/2013 10:59 AM, Emil Ivov wrote: > > On 14.05.13, 09:16, Emil Ivov wrote: >> Hey Harald, >> >> On 12.05.13, 22:55, Harald Alvestrand wrote: >>> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>>>> Or you could signal none of them and depend on the fallback case in >>>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>>> use other methods to figure out how to handle them... >>>> If you are referring to section 4.1 that you also pasted earlier in >>>> this thread, it only talks about one track, per stream, per m= line. >>>> This doesn't cover the conferencing case I described in my previous >>>> mail (quoted above). >>>> >>> Changing subject as I'm replying to a subtopic, and because I was >>> misunderstanding what Emil was arguing in favour of..... >>> >>> when I wrote that text, I didn't intend it to cover only one SSRC per >>> stream. >>> What I intended to say was that when, in an RTP session, a browser gets >>> several SSRCs that were not mentioned in signalling, it will send >>> several onaddstream signals to the application, each indicating a new >>> stream being added, which has exactly one track. >> Aha! OK, I understand and it sounds better now that I do. > Oh, just thought of something else while reading Stefan's mail: is it > really necessary that this should only happen in case no SSRCs have been > defined? Why not apply that to any unknown SSRC regardless of whether or > not others exist in SDP? > > The second bullet there talks about a possible race condition but I am > not sure I see how this could occur with valid use of O/A. The worrying case is: A sends offer B sends answer (either with or without MSID) B starts sending data on some SSRCs A receives the data, but has not yet seen the answer The two cases are: - B sends with MSID. In this case, he expects those specific IDs to be signalled in onaddstream. - B sends without MSID. In this case, he expects that A will announce a locally generated ID in onaddstream. A can't know the difference between those two before he sees the answer from B. In this spec, I've "solved" it by saying that we don't signal onaddstream before we see the answer. After the first answer has been seen, either party knows that new SSRCs always will be signalled, so any data on an unknown SSRC can be held until the negotiation announcing it is complete - or discarded as "bad data" if signalling doesn't happen in a reasonable time. If we were to permit unknown SSRCs when there are some MSIDs, the decision to announce as "Unsignalled MediaStream" or wait for the offer/answer announcing the MSID it should be announced with has to depend on some other resolution mechanism. I don't like timers, and haven't found a better way to do it. Note: If we follow "plan B"'s idea of having B send an offer with its own streams immedately after sending the answer to A, and only announce its streams in the counter-offer, not in the answer, and not sending data until it gets the answer, this problem goes away; there cannot be a case where A gets an SSRC that was intended to be signalled before he gets the signalling message that announces it. I'm sure there's a cost to this solution (the extra half RTT is one obvious cost. Are there others?) > > Emil > From ted.ietf@gmail.com Tue May 14 09:38:48 2013 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 DD64521F9128 for ; Tue, 14 May 2013 09:38:47 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtuG2E5A8YvC for ; Tue, 14 May 2013 09:38:46 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44621F9121 for ; Tue, 14 May 2013 09:38:46 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id b11so1459424iee.23 for ; Tue, 14 May 2013 09:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0Hqym6ykdN/k3rO+71w+L8U8JNRRjM8987aFerWzfAI=; b=JhM6R6aUasOg3q0nLv7mvVZRgfBbMHdyDOhnn07Jm9ZLkJ1LgLXsm5/U4mtt4zAQuX Lp6J2ey5HUibI4dqqGdUqN+YMC1+u8SXva9hVmv4jdGEDrvnSoQ75tF5q2Rpz/NTh0wk 4H1adApqC8kvtS/zidDQk/gMa1PKKavW/1A3w11ccD2Nta2PestD1jUkj0qJSah3zDMh KIYrF/zYUKVwTA4tmoVvTaEn1MecQrxd+5taepILdEgdfoBO2FUEQbm4EKRPVFEG5HKE /kBryAV28KVXwRnGJ7NbMlK8+x/qpKTJQukmgQ5OGxrg3THTNQiSaakz3LFXP9WGHJc0 qScQ== MIME-Version: 1.0 X-Received: by 10.50.128.227 with SMTP id nr3mr2778266igb.24.1368549519245; Tue, 14 May 2013 09:38:39 -0700 (PDT) Received: by 10.42.79.73 with HTTP; Tue, 14 May 2013 09:38:39 -0700 (PDT) In-Reply-To: <518E7700.1080906@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> Date: Tue, 14 May 2013 09:38:39 -0700 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b10c81bf3c91404dcb0438f Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:38:48 -0000 --047d7b10c81bf3c91404dcb0438f Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 11, 2013 at 9:51 AM, Paul Kyzivat wrote: > In clue we are addressing that by exchanging (in a separate channel) > advertisements of what the endpoints are willing to send, and only doing > O/A to set up the media that is of interest. > > In rtcweb it isn't so structured, but I suspect something is happening > implicitly, though it may be more hard-wired per application. > So, I repeat what I said before, I think you can get to there in RTCWEB, but it won't be the same way pokerstars gets to where it wants to go. The simplest thing I can imagine, to just put it out there, is to start RTCWEB with just a data channel, pass the clue messages on top, then start the media channels after that's done. That seems to be reasonably in line with what you've described above and it's well within the RTCWEB APIs. What won't happen is for *every* application to adopt that procedure; some will want behaviour that looks closer to vanilla offer/answer; some will want behaviour that is more-or-less directed by the server, and some will want blueberry jam (that is, something we don't know about yet). regards, Ted --047d7b10c81bf3c91404dcb0438f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 11, 2013 at 9:51 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
In clue we are addressing that by exchanging (in a separate channel) advert= isements of what the endpoints are willing to send, and only doing O/A to s= et up the media that is of interest.

In rtcweb it isn't so structured, but I suspect something is happening = implicitly, though it may be more hard-wired per application.

So, I repeat what I said before, I think you can get to there i= n RTCWEB, but it won't be the same way pokerstars gets to where it want= s to go.

The simplest thing I can imagine, to just put it out there, is to start= RTCWEB with just a data channel, pass the clue messages on top, then start= the media channels after that's done.=A0 That seems to be reasonably i= n line with what you've described above and it's well within the RT= CWEB APIs.=A0

What won't happen is for *every* application to adopt that procedur= e; some will want behaviour that looks closer to vanilla offer/answer; some= will want behaviour that is more-or-less directed by the server, and some = will want blueberry jam (that is, something we don't know about yet).
regards,

Ted
--047d7b10c81bf3c91404dcb0438f-- From paalh@ifi.uio.no Tue May 14 11:27:56 2013 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 7F3A811E810E; Tue, 14 May 2013 11:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7icqfgrbcST; Tue, 14 May 2013 11:27:55 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7211E810D; Tue, 14 May 2013 11:27:38 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UcJwj-0004vX-Nr; Tue, 14 May 2013 20:27:33 +0200 Received: from [148.122.14.90] (helo=[10.10.1.180]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1UcJwj-0002n6-7u; Tue, 14 May 2013 20:27:33 +0200 From: =?iso-8859-1?Q?P=E5l_Halvorsen?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 May 2013 20:27:32 +0200 Message-Id: To: bloat@lists.bufferbloat.net, iccrg@cs.ucl.ac.uk, rmcat@ietf.org, rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 43 msgs/h 15 sum rcpts/h 46 sum msgs/h 16 total rcpts 3746 max rcpts/h 73 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 67A55365DF2BE3690FBA58E0CDC496E8052261AB X-UiO-SPAM-Test: remote_host: 148.122.14.90 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 15 total 22 max/h 15 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] [Packet Video 2013] Submission deadline in 4 weeks X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:27:56 -0000 Packet Video 2013 Sponsored by IEEE Communications Society December 12 and 13th San Jose, CA USA ------------------------------------------------------------- Call for Papers The 20th International Packet Video Workshop (PV 2013) is devoted to presenting technological advancements and innovations in video and multimedia transmission over packet networks, in particular wireless and Internet networks. The workshop provides a unique venue for people from the media coding and networking fields to meet, interact and exchange ideas. Its charter is to promote the research and development in both established and emerging areas of video streaming and multimedia networking. PV 2013 will be held in San Jose, CA USA on December 12 and 13th. As in previous years, the workshop will be a single-track event and welcomes paper submissions from both cutting-edge research, and business and consumer applications. PV 2013 will be immediately following the Picture Coding Symposium, which will be held also in San Jose, CA. There will be both regular and special sessions. In general, the workshop seeks papers in all areas of media delivery over packet-based networks. Authors are especially encouraged to submit papers with real- world experimental results and real datasets. Topics of interest include (but are not limited to): - Cloud and peer-to-peer system architectures - Media streaming, distribution and storage support - Multimedia communications and system security - Multi-core and many-core architecture support - Networked GPUs, graphics and virtual environments - Networked games, real-time immersive systems - Operating system, middleware and network support - Web 2.0 systems and social networks - Next-generation video like multi-view, panorama and 3D - Wireless networks and embedded systems for multimedia applications - Content-centric networking In particular, we are interested in soliciting papers that discuss system-level support improving performance with multi-core and many-core processors, as well as papers that focus on multimedia applications on mobile devices and/or in a cloud-computing environment. Prospective authors are invited to submit an electronic version of full papers, in PDF format, up to 8 printed pages in length (double column IEEE conference format). The proceedings will be published by the IEEE Xplore shortly after the workshop. For the Technical Program Committee and details regarding special = sessions, refer to the PV 2013 Web site at http://pv2013.itec.aau.at/. ORGANIZATION General Co-Chairs Ali C. Begen, Cisco (Canada) Bernd Girod, Stanford Univ. Technical Program Co-Chairs John Apostolopoulos, Cisco (USA) P=E5l Halvorsen, University of Oslo Publicity Chair Christian Timmerer, AAU Klagenfurt Publications Chair Zhi Li, Cisco (USA) Steering Committee Chang Wen Chen, SUNY Buffalo, USA Tsuhan Chen, Cornell, USA Reha Civanlar, Ozyegin Univ., Turkey Pascal Frossard, EPFL, Switzerland Bernd Girod, Stanford Univ., USA Jin Li, Microsoft, USA Fernando Pereira, IST-IT, Portugal Amy Reibman, AT&T, USA Mihaela van der Schaar, UCLA, USA Ralf Schaefer, HHI, Germany Eckehard Steinbach, TUM, Germany Ming-Ting Sun, Univ. of Wash., USA Important Dates All Papers due: June 10th=20 Acceptance Notifications: Sept. 13th=20 Camera-ready: Oct. 18th Further Information http://pv2013.itec.aau.at/ From pkyzivat@alum.mit.edu Tue May 14 11:34:31 2013 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 F15CE21F8F53 for ; Tue, 14 May 2013 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmrjP9V8gsIC for ; Tue, 14 May 2013 11:34:25 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id DC20421F8F9E for ; Tue, 14 May 2013 11:34:22 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id btta1l0050QuhwU5DuaMSs; Tue, 14 May 2013 18:34:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id buaL1l01g3ZTu2S3NuaM1M; Tue, 14 May 2013 18:34:21 +0000 Message-ID: <519283AC.9020908@alum.mit.edu> Date: Tue, 14 May 2013 14:34:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Hardie References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368556461; bh=J1V4pYfQdtYJQl8KWU9N/Wu+fcaHRbJvXFjouU+ZBWQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ihjt8p+2oR/Nu+1MOsNCSBDuqI6j/YXVqw1B4PGyA5ImSTw8CkC3x6OtJWpBtmT9z mwkah506GuN2C0MJMz/p6gDFBZuFgmiwFyO8JRcVM0a0cBGcKjUgW2JCHjp8o+8ny+ QlFzTZq7Yq0RWw2IcNCSZ3hCRScE7c7rKHRYFzASmmNmpuW1TFI69QL/23C3dua9fL fy8GCnPHaRiTJ8oNhZ6N+zwhU8p9Xw6y0zMZ/8TRDXBOF/bEIUUeTHHDJuV64iS9Vy 4nHEo+I/Ur7N8A06XfBocpTJHW81UdyjvGbJ9V2Rz1G4DmxtJpsxto3S7tVGdHB/lL PVHaGgkJBBCeQ== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:34:31 -0000 On 5/14/13 12:38 PM, Ted Hardie wrote: > On Sat, May 11, 2013 at 9:51 AM, Paul Kyzivat > wrote: > > In clue we are addressing that by exchanging (in a separate channel) > advertisements of what the endpoints are willing to send, and only > doing O/A to set up the media that is of interest. > > In rtcweb it isn't so structured, but I suspect something is > happening implicitly, though it may be more hard-wired per application. > > > So, I repeat what I said before, I think you can get to there in RTCWEB, > but it won't be the same way pokerstars gets to where it wants to go. > > The simplest thing I can imagine, to just put it out there, is to start > RTCWEB with just a data channel, pass the clue messages on top, then > start the media channels after that's done. That seems to be reasonably > in line with what you've described above and it's well within the RTCWEB > APIs. I expect the same thing to happen with rtcweb as without it: An initial offer proposes a data channel and some initial media. If the other end also supports clue, then it will accept the data channel, and some or all of the media, as it sees fit, given that it doesn't know what the purpose of that media is yet. (E.g. the media might consist of one audio and one video. But it also might be optimistic and assume the other end is configured just like it is.) Then the two sides will exchange clue advertisements over the data channel. Based on the advertisements, the two sides will then decide what they want to receive, and send clue configure messages describing that. Before or after the configuration messages, if necessary, a new O/A (or two) may be exchanged to arrange the media to be consistent with the advertisements and configurations. > What won't happen is for *every* application to adopt that procedure; > some will want behaviour that looks closer to vanilla offer/answer; some > will want behaviour that is more-or-less directed by the server, and > some will want blueberry jam (that is, something we don't know about yet). Certainly. If the web server supporting the browser does't support clue then this isn't going to result in a clue call. But that would only come up for *received* calls, and receiving such a call via rtcweb depends on having an app that is at least addressable by a clue client. That means it must have a sip address. If so, then at least it will probably be able to connect as a "legacy" sip device. My concern it that it be *possible* to do this with rtcweb, preferably obscure gateway code. Thanks, Paul From emil@sip-communicator.org Tue May 14 12:46:13 2013 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 36A1C21F8F4F for ; Tue, 14 May 2013 12:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwCysEGRXT+T for ; Tue, 14 May 2013 12:46:12 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AF83121F8F43 for ; Tue, 14 May 2013 12:46:11 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jk13so572333bkc.17 for ; Tue, 14 May 2013 12:46:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=2UwJnjwLT+wzEhHBHhY4yIBvSnZ+Er8VzJVJmguYiO0=; b=H2nxQF+dXXpX7F8hocDdiovIem5a96w6pE+O4UjAPa+Rfgg2mL09PMe55IM9XbBcac wCpjYWuV9P6gM8e0oq72Q2KvdcDwHHDikEeOKFQxEdyxSe2W8FqttrWmV+V33HGuLm8Q n29+6SIYC00vz94njfeqcNLObHTlW3MyotXz3vuhp8S+svnbf5DGL94VRBCL2EAPFzOT Nm63rmZRI2W/JB+VnwpOnq5yYGNhmh+9cOQWP6/6rvUN5IagUQywbb5fxWFqedKZGom+ GeerbADXg1TPWmtQFbWG//S6YdDU+1WVLRpnPvhDapQ2GxhE+3yPkkFTdODNJk0R7W7m 1zag== X-Received: by 10.204.65.69 with SMTP id h5mr9508244bki.59.1368560770628; Tue, 14 May 2013 12:46:10 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id es13sm4093752bkc.8.2013.05.14.12.46.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 12:46:09 -0700 (PDT) Message-ID: <5192947F.90206@jitsi.org> Date: Tue, 14 May 2013 22:46:07 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> In-Reply-To: <519223A0.1040908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnNZweSeLvLiEhDebyZPUNBqgOdNgCT8nYYhUob6gpBOMb9ooVKjHoxkRz0xvAwFCLfrkNG Cc: rtcweb@ietf.org Subject: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:46:13 -0000 Hey Stefan, On 14.05.13, 14:44, Stefan H=E5kansson LK wrote: >>> SSRCs - this would be SDP >> >> Again, including SSRCs in SDP O/A is tricky in conferencing scenarios.= >=20 > Here seems to be something that I have missed. That there are existing = > implementations that do not signal SSRC is fine, and in most cases ther= e=20 > would be only one audio and one video SSRC used anyway. And rtcweb (and= =20 > Clue?) should be able to interoperate (but perhaps your web app need to= =20 > be designed in a specific way). >=20 > But if we design something forward looking, that can handle many=20 > streams, that can handle layered codecs and FEC data, signaling SSRCs=20 > seems like a must to me. >=20 > But I have missed that this is problematic in conferencing scenarios,=20 > could you tell me why (and I probably should know :) )? The issue that I am referring to (I describe this in an earlier mail to Harald here http://goo.gl/M8NbQ ) is that of a conference based on an RTP translator. It's basically what we do in Jitsi Videobridge. Let's say that I am a WebRTC app that can act as a conference focus and that has access to an RTP translator somewhere. I'd like to organise a conference with 10 people (you and I among them). I ask the RTP translator to allocate 10 ports for me and then I start calling participants. You are the first one that I am going to join into this new call. At this point, the only SSRC(s) that I could possibly give you are those that I am going to use. I won't be able to tell you anything for the eight other participants. For all I know, some or all of these participants could turn out to be RTP translators themselves and there could be a number of SSRCs behind each of them too. The very logical and easy thing that your webapp could do here is not to care and simply render each and every SSRC that you get. Most apps are going to be perfectly happy with that. If, on the other hand you needed me to re-offer you every time a new participant joins in order to work properly, then things would easily get quite messy even if everyone is using WebRTC. Then, note that some of the participants can be simple SIP endpoints (that's why we bothered with SDP in the first place right?) so the only way I can get their SSRCs is with some extra signalling between me and the RTP translator. This is not a problem per se, but it can only happen after the SIP participants have joined the call and started streaming data, that has reached the translator. And even then they will have no MSIDs. All in all, we would be enforcing some very laborious signalling when it is absolutely unnecessary. Does this make sense? Emil --=20 https://jitsi.org From ted.ietf@gmail.com Tue May 14 13:45:01 2013 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 347B121F8E7C for ; Tue, 14 May 2013 13:45:01 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0y1Q6CO3KAk for ; Tue, 14 May 2013 13:45:00 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7774021F8F6E for ; Tue, 14 May 2013 13:45:00 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id aq17so2115818iec.1 for ; Tue, 14 May 2013 13:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I+26YESaG+2g4GimqH98aeY7emP7Yh5PC0Mb8yoj9ig=; b=C2fzIQZPSci3qu/pGbA7Sa9H+nR1WqvGrDnqgjrC/tFmVTuUuLjeI5Pedzn7sMhQXd t+P8ay9mOz8ckCK5R8uZ9rZZvqmMe9LSCD9K3TN5jxpXxoXY0YqgESVCDw3zqnhfZvhr I0KP4gPldRlEmkE0tripd9IoMHpDBe0GfZ7a1WDoDgGpZxN7xfnJSS7scWLPKHxrAjKG Eou3QgxxOJGGpCBtc1j19a2UMdE26EAukb0NUcO0+ufO+3DrNvyHbkg3iLkUL+HP0VSO WyaXPupgDxQi8H2N5HtMbELnBaU2gZO9Dwq/Yxkg/lJqxhA18FrqGtScffq1jEJB64RV Zdew== MIME-Version: 1.0 X-Received: by 10.50.117.101 with SMTP id kd5mr3455532igb.12.1368564300036; Tue, 14 May 2013 13:45:00 -0700 (PDT) Received: by 10.42.79.73 with HTTP; Tue, 14 May 2013 13:44:59 -0700 (PDT) In-Reply-To: <519283AC.9020908@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> <519283AC.9020908@alum.mit.edu> Date: Tue, 14 May 2013 13:44:59 -0700 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e011826f8f50b3c04dcb3b4c6 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:45:01 -0000 --089e011826f8f50b3c04dcb3b4c6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 14, 2013 at 11:34 AM, Paul Kyzivat wrote: Certainly. If the web server supporting the browser I assume by this you meant the javascript application; it's possible for the web server to support the CLUE semantics but a particular client not to (e.g. a mobile client connecting to the server). > does't support clue then this isn't going to result in a clue call. But > that would only come up for *received* calls, and receiving such a call via > rtcweb depends on having an app that is at least addressable by a clue > client. That means it must have a sip address. If so, then at least it will > probably be able to connect as a "legacy" sip device. > > So, just to confirm my understanding, in this scenario, the webrtc client is sitting in an open screen somewhere, connected to a web server (it could be headless, but bare with me). When a CLUE conference starts that the webserver believes is of interest to the webrtc client it uses the existing connection to notify it and give it conference details. Is that right so far? If that is the case, I'm not sure what you mean by "must have a SIP address". Can you clarify this? My concern it that it be *possible* to do this with rtcweb, preferably > obscure gateway code. > > I'm assuming that a "without" is missing here, but can you confirm? regards, Ted > Thanks, > Paul > > --089e011826f8f50b3c04dcb3b4c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2013 at 11:34 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<= /a>> wrote:

Certainly. If the web server supporting the browser
=A0
I assume by this you meant the javascript application; it's po= ssible for the web server to support the CLUE semantics but a particular cl= ient not to (e.g. a mobile client connecting to the server).
=A0
does't support clue then this i= sn't going to result in a clue call. But that would only come up for *r= eceived* calls, and receiving such a call via rtcweb depends on having an a= pp that is at least addressable by a clue client. That means it must have a= sip address. If so, then at least it will probably be able to connect as a= "legacy" sip device.


So, just to confirm my understanding, in this sce= nario, the webrtc client is sitting in an open screen somewhere, connected = to a web server (it could be headless, but bare with me).=A0 When a CLUE co= nference starts that the webserver believes is of interest to the webrtc cl= ient it uses the existing connection to notify it and give it conference de= tails.=A0 Is that right so far?=A0
=A0
If that is the case, I'm not sure what you mean by "must ha= ve a SIP address".=A0 Can you clarify this?

My concern it that it be *possible* to do this with rtcweb, preferably obsc= ure gateway code.


I'm assuming that a "without" is mi= ssing here, but can you confirm?

regards,

Ted
=A0
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


--089e011826f8f50b3c04dcb3b4c6-- From hangzhou.chenxin@huawei.com Tue May 14 18:40:23 2013 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 A9A5121F8AE2; Tue, 14 May 2013 18:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iJSI1SoRwCo; Tue, 14 May 2013 18:40:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CBCBE21F84D4; Tue, 14 May 2013 18:40:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU55151; Wed, 15 May 2013 01:40:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 02:39:51 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 02:40:14 +0100 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Wed, 15 May 2013 09:40:06 +0800 From: "Chenxin (Xin)" To: "behave@ietf.org" , "rtcweb@ietf.org" , "dispatch-bounces@ietf.org" Thread-Topic: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzA Date: Wed, 15 May 2013 01:40:05 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 01:40:23 -0000 VGhpcyBkcmFmdCBkZWZpbmVzIGEgd2Vic29ja2V0IGV4dGVuc2lvbiB0byBUVVJOIHRvIG1ha2Ug VFVSTiBkYXRhIGhhdmUgdGhlIGFiaWxpdHkgdG8gdHJhbnNwb3J0IG92ZXIgdGhlIHdlYnNvY2tl dCBjb25uZWN0aW9uLg0KDQpUaGlzIG1ldGhvZCBjb3VsZCBiZSBhIG9wdGlvbiB0byBzb2x2ZSB0 aGUgSHR0cC1mYWxsYmFjayByZXF1aXJlbWVudCBpbiBSVENXRUIuIA0KDQogICAgRjM3ICAgICAg ICAgICAgVGhlIGJyb3dzZXIgTVVTVCBiZSBhYmxlIHRvIHNlbmQgc3RyZWFtcyBhbmQNCiAgICAg ICAgICAgICAgICAgICBkYXRhIHRvIGEgcGVlciBpbiB0aGUgcHJlc2VuY2Ugb2YgRldzIHRoYXQg b25seQ0KICAgICAgICAgICAgICAgICAgIGFsbG93cyBodHRwKHMpIHRyYWZmaWMuDQoNCkJlc2lk ZXMsIFR1cm4gc2VydmVyIHdpdGggd2Vic29rY2V0IGV4dGVuc2lvbiBjb3VsZCBiZSBhIGdlbmVy YWwgcmVsYXkgc2VydmVyIGZvciBzb21lIG92ZXIgd2Vic29ja2V0IHByb3RvY29sLCBzdWNoIGFz IEJGQ1Agb3ZlciB3ZWJzb2NrZXQgb3IgTVNSUCBvdmVyIHdlYnNvY2tldC4gVGhpcyBjb3VsZCBz YXRpc2Z5IHNvbWUgUGVlciB0byBQZWVyIHNjZW5lIHdoZW4gdXNpbmcgdGhlc2UgcHJvdG9jb2wg aW4gdGhlIHdlYiBlbnZpcm9ubWVudCAsIHdpdGhvdXQgYSBzcGVjaWZpYyBjZW50ZXIgc2VydmVy Lg0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgUmVnYXJk cywNCiAgICAgWGluIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogVHVlc2RheSwgTWF5IDE0LCAyMDEzIDk6MTUgQU0NClRvOiBDaGVueGluIChYaW4pOyBD aGVueGluIChYaW4pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGluIENoZW4gYW5kIHBvc3RlZCB0byB0aGUN CklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJu LXdlYnNvY2tldA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgVHJhdmVyc2FsIFVzaW5nIFJlbGF5 cyBhcm91bmQgTkFUIChUVVJOKSBFeHRlbnNpb25zIGZvciBXZWJzb2NrZXQgQWxsb2NhdGlvbnMN CkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTEzDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCk51bWJlciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0w MC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldA0KSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tl dC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4dGVuc2lv biB0byBUVVJOIHRoYXQgYWxsb3dzIGl0IHRvIHJ1biBvdmVyDQogICBhIFdlYnNvY2tldCBbUkZD NjQ1NV0gY2hhbm5lbC4gIFRoaXMgd2lsbCBhbGxvdyBhIGNsaWVudCBpbiBhDQogICByZXN0cmlj dGl2ZSBuZXR3b3JrIHRvIGV4Y2hhbmdlIGFuZCByZWxheSBtZWRpYSBvciBkYXRhIG92ZXIgdGhl DQogICB3ZWJzb2NrZXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From emil@sip-communicator.org Tue May 14 22:37:01 2013 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 E392D21F898A for ; Tue, 14 May 2013 22:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8YnOZOVOdL7 for ; Tue, 14 May 2013 22:37:01 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A78B321F8960 for ; Tue, 14 May 2013 22:37:00 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji2so765026bkc.38 for ; Tue, 14 May 2013 22:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=sSY88NeUZjibvQ/KeOTbuLDtjNu+lk9MnAFLEh0Ws8c=; b=ge8mYkEJbywVZyO92rV2gXYGJDc8gizGU3aytIIKmOQdjzAzsO64dVhrFY/wsl/BCr TaD7WGpP3BkxSP+SRNBl4ac3wjZmKkHY8en5CCSMNRMDfOhlIrfibN0TF7Z149t073Cb ZVrvUv5PQgRNweTbHZHJUEbM/MIW5eDBWDQ4fKsVrTGoYepnb5mHTvY9b9PQqrkAVeKa bssF7kuE7HUdVf14xBtscS6LM49ozV6g/Dplr/guUD3F2k0Z+WurQdUmM02WhpvQEaPt TF1w1WssB6Dca3SVQPNWAz5DKqElj8lNm6d4COeoZ42dvgjIxsJ3b6THRHW7VlhLOwIU becg== X-Received: by 10.205.38.73 with SMTP id th9mr9899190bkb.0.1368596219072; Tue, 14 May 2013 22:36:59 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id fh8sm283486bkc.10.2013.05.14.22.36.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 22:36:57 -0700 (PDT) Message-ID: <51931EF3.7080108@jitsi.org> Date: Wed, 15 May 2013 08:36:51 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> <51922959.3070708@alvestrand.no> In-Reply-To: <51922959.3070708@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkvd9/sTsJJoW7qeqPOllVRwPwIZgx2rQ157AdpWbuSgjJWTT2D30LI95KaF+uqMuqDbIs3 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 05:37:02 -0000 On 14.05.13, 15:08, Harald Alvestrand wrote: > On 05/14/2013 10:59 AM, Emil Ivov wrote: >> >> On 14.05.13, 09:16, Emil Ivov wrote: >>> Hey Harald, >>> >>> On 12.05.13, 22:55, Harald Alvestrand wrote: >>>> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>>>>> Or you could signal none of them and depend on the fallback case in >>>>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>>>> use other methods to figure out how to handle them... >>>>> If you are referring to section 4.1 that you also pasted earlier in >>>>> this thread, it only talks about one track, per stream, per m= line. >>>>> This doesn't cover the conferencing case I described in my previous >>>>> mail (quoted above). >>>>> >>>> Changing subject as I'm replying to a subtopic, and because I was >>>> misunderstanding what Emil was arguing in favour of..... >>>> >>>> when I wrote that text, I didn't intend it to cover only one SSRC per >>>> stream. >>>> What I intended to say was that when, in an RTP session, a browser gets >>>> several SSRCs that were not mentioned in signalling, it will send >>>> several onaddstream signals to the application, each indicating a new >>>> stream being added, which has exactly one track. >>> Aha! OK, I understand and it sounds better now that I do. >> Oh, just thought of something else while reading Stefan's mail: is it >> really necessary that this should only happen in case no SSRCs have been >> defined? Why not apply that to any unknown SSRC regardless of whether or >> not others exist in SDP? >> >> The second bullet there talks about a possible race condition but I am >> not sure I see how this could occur with valid use of O/A. > > The worrying case is: > > A sends offer > B sends answer (either with or without MSID) > B starts sending data on some SSRCs > A receives the data, but has not yet seen the answer > > The two cases are: > > - B sends with MSID. In this case, he expects those specific IDs to be > signalled in onaddstream. > - B sends without MSID. In this case, he expects that A will announce a > locally generated ID in onaddstream. > > A can't know the difference between those two before he sees the answer > from B. > In this spec, I've "solved" it by saying that we don't signal > onaddstream before we see the answer. > > After the first answer has been seen, either party knows that new SSRCs > always will be signalled, so any data on an unknown SSRC can be held > until the negotiation announcing it is complete - or discarded as "bad > data" if signalling doesn't happen in a reasonable time. > > If we were to permit unknown SSRCs when there are some MSIDs, the > decision to announce as "Unsignalled MediaStream" or wait for the > offer/answer announcing the MSID it should be announced with has to > depend on some other resolution mechanism. I don't like timers, and > haven't found a better way to do it. I didn't get this part. While I see the race condition that occurs during offer/answer, I am not sure I understand why a new SSRC received mid-session by either side is ambiguous. If the application had any intent to announce it, then presumably it would be on the verge of initiating a new offer/answer. If that were the case, sending the new stream/track could have been held off until completion of that offer/answer. This way one would be able to only announce SSRCs for things such as FEC and simulcasting (where available) while simple streams could be delivered immediately. Emil -- https://jitsi.org From juberti@google.com Tue May 14 22:53:51 2013 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 5E09C21F8E4C for ; Tue, 14 May 2013 22:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.561 X-Spam-Level: X-Spam-Status: No, score=-100.561 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM0zV9oUAOqV for ; Tue, 14 May 2013 22:53:50 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD921F8A7B for ; Tue, 14 May 2013 22:53:50 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id a14so2854704iee.41 for ; Tue, 14 May 2013 22:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tF91nc5+znDz7Nxre2/mJcEta22jcXKRuhmSbqKXPws=; b=JUMDF4T5HvAWkCRTgFdNcKm06OrHCd5ToGEv6miDXYHoNc59fDDUy5STrzJc9QDQtm lVOmn5Zxd/xu2Oa2ELx9pF+v+uepbb/++sRNTuZPOb2PpJ7QkeWqALi/4/FRa90rdgcw nKCaiFkQKEsOQ6sBCLtfMcK8QugsibhclV6yie05p9lbF35j/KFTdoHwVwmGpji60IOk umQ4uzv7gc6EPyaZL9zQ25+xkgI4O/a0jv7BQnzZj5/PYwi8HbL6j+/cJLuSkFvBjYC5 JLy5PP9c5TBJLglroUymVRzI681ra0bv4trC9Oft2Xb6mnROT1QZnys1C3Pojote8Dgu 3n6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=tF91nc5+znDz7Nxre2/mJcEta22jcXKRuhmSbqKXPws=; b=Vh2PiglXFlxDUM9yelPM5Dx7PG8fJHkd11sYm6uCYlO2Sw0SiVrJ+xq5YszyVjMwnU Y7RMvMguAJX+tarzd5HdRBZ2p2iJijYcrV+9CcsB+Dd4G97osai4NZN9yKE5NAHElPzD dhwTflizRqMffhGQku2bCQ4erSdQheLHoRlXdg93fTN1rXEmL0nW8Ru27JGghlPpPOaD QrwQa5TsRzBqEHUGHQtPzQLXtT3Eilb5fO+BEtDDOQcoSyXkUQGjWQxqClk/QX8G5DBZ UktAcbQpnlUh1IhWuOGcOc6ArgNglI+Sh5VqBi3v5oqSkqhDeNrUZrPPM5Ym19cTP0iF kRXQ== X-Received: by 10.43.63.140 with SMTP id xe12mr7033223icb.52.1368597229766; Tue, 14 May 2013 22:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.153.69 with HTTP; Tue, 14 May 2013 22:53:29 -0700 (PDT) In-Reply-To: <5192947F.90206@jitsi.org> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> <518D6C76.5060606@alum.mit.edu> <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> From: Justin Uberti Date: Tue, 14 May 2013 22:53:29 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=bcaec51b1e3bb89f3004dcbb5f11 X-Gm-Message-State: ALoCoQkMVMeAqGi4TWm/+jvfGg2aBoyPk04ImTgHtRz/Z4FaWFtQ9ZUqnK7J8JIgFttIxF20ofEpYOuOmLYGKumB6T04ORnymrJzcEsQ9dAMk00jfdu9IEeWL3oGccfsttw+X01mKEzteCAAGX/MGq/tFJK6gbm30UxrE9xhncN+qqijF9Xlt6s8JM5Q/KRx9rPsGswGFIUe Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 05:53:51 -0000 --bcaec51b1e3bb89f3004dcbb5f11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2013 at 12:46 PM, Emil Ivov wrote: > Hey Stefan, > > On 14.05.13, 14:44, Stefan H=C3=A5kansson LK wrote: > >>> SSRCs - this would be SDP > >> > >> Again, including SSRCs in SDP O/A is tricky in conferencing scenarios. > > > > Here seems to be something that I have missed. That there are existing > > implementations that do not signal SSRC is fine, and in most cases ther= e > > would be only one audio and one video SSRC used anyway. And rtcweb (and > > Clue?) should be able to interoperate (but perhaps your web app need to > > be designed in a specific way). > > > > But if we design something forward looking, that can handle many > > streams, that can handle layered codecs and FEC data, signaling SSRCs > > seems like a must to me. > > > > But I have missed that this is problematic in conferencing scenarios, > > could you tell me why (and I probably should know :) )? > > The issue that I am referring to (I describe this in an earlier mail to > Harald here http://goo.gl/M8NbQ ) is that of a conference based on an > RTP translator. It's basically what we do in Jitsi Videobridge. > > Let's say that I am a WebRTC app that can act as a conference focus and > that has access to an RTP translator somewhere. I'd like to organise a > conference with 10 people (you and I among them). > > I ask the RTP translator to allocate 10 ports for me and then I start > calling participants. > > You are the first one that I am going to join into this new call. > > At this point, the only SSRC(s) that I could possibly give you are those > that I am going to use. I won't be able to tell you anything for the > eight other participants. For all I know, some or all of these > participants could turn out to be RTP translators themselves and there > could be a number of SSRCs behind each of them too. > > The very logical and easy thing that your webapp could do here is not to > care and simply render each and every SSRC that you get. Most apps are > going to be perfectly happy with that. > > If, on the other hand you needed me to re-offer you every time a new > participant joins in order to work properly, then things would easily > get quite messy even if everyone is using WebRTC. > > Then, note that some of the participants can be simple SIP endpoints > (that's why we bothered with SDP in the first place right?) so the only > way I can get their SSRCs is with some extra signalling between me and > the RTP translator. This is not a problem per se, but it can only happen > after the SIP participants have joined the call and started streaming > data, that has reached the translator. And even then they will have no > MSIDs. > > All in all, we would be enforcing some very laborious signalling when > it is absolutely unnecessary. > > How do you plan to demultiplex the media sources without knowing whose SSRC belongs to whom? Consider especially the case of repair flows, for which one must know which primary flow the repair flow corresponds with. Given the complexities here, I don't think it's entirely fair to call the signaling "absolutely unnecessary". --bcaec51b1e3bb89f3004dcbb5f11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, May 14, 2013 at 12:46 PM, Emil Ivov <<= a href=3D"mailto:emcho@jitsi.org" target=3D"_blank">emcho@jitsi.org>= wrote:
Hey Stefan,

On 14.05.13, 14:44, Stefan H=C3=A5kansson LK wrote:
>>> SSRCs - this would be SDP
>>
>> Again, including SSRCs in SDP O/A is tricky in conferencing scenar= ios.
>
> Here seems to be something that I have missed. That there are existing=
> implementations that do not signal SSRC is fine, and in most cases the= re
> would be only one audio and one video SSRC used anyway. And rtcweb (an= d
> Clue?) should be able to interoperate (but perhaps your web app need t= o
> be designed in a specific way).
>
> But if we design something forward looking, that can handle many
> streams, that can handle layered codecs and FEC data, signaling SSRCs<= br> > seems like a must to me.
>
> But I have missed that this is problematic in conferencing scenarios,<= br> > could you tell me why (and I probably should know :) )?

The issue that I am referring to (I describe this in an earlier mail to
Harald here http://goo.gl= /M8NbQ ) is that of a conference based on an
RTP translator. It's basically what we do in Jitsi Videobridge.

Let's say that I am a WebRTC app that can act as a conference focus and=
that has access to an RTP translator somewhere. I'd like to organise a<= br> conference with 10 people (you and I among them).

I ask the RTP translator to allocate 10 ports for me and then I start
calling participants.

You are the first one that I am going to join into this new call.

At this point, the only SSRC(s) that I could possibly give you are those that I am going to use. I won't be able to tell you anything for the eight other participants. For all I know, some or all of these
participants could turn out to be RTP translators themselves and there
could be a number of SSRCs behind each of them too.

The very logical and easy thing that your webapp could do here is not to care and simply render each and every SSRC that you get. Most apps are
going to be perfectly happy with that.

If, on the other hand you needed me to re-offer you every time a new
participant joins in order to work properly, then things would easily
get quite messy even if everyone is using WebRTC.

Then, note that some of the participants can be simple SIP endpoints
(that's why we bothered with SDP in the first place right?) so the only=
way I can get their SSRCs is with some extra signalling between me and
the RTP translator. This is not a problem per se, but it can only happen after the SIP participants have joined the call and started streaming
data, that has reached the translator. And even then they will have no
MSIDs.

All in all, we would be enforcing some very laborious signalling when
it is absolutely unnecessary.


How do you plan to demultiplex the media sources without knowing whose SSR= C belongs to whom? Consider especially the case of repair flows, for which = one must know which primary flow the repair flow corresponds with.

Given the complexities here, I don't th= ink it's entirely fair to call the signaling "absolutely unnecessa= ry".
--bcaec51b1e3bb89f3004dcbb5f11-- From harald@alvestrand.no Tue May 14 23:24:09 2013 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 426DD21F8D7A for ; Tue, 14 May 2013 23:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.7 X-Spam-Level: X-Spam-Status: No, score=-106.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK8nC337iW7M for ; Tue, 14 May 2013 23:24:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2478821F8B45 for ; Tue, 14 May 2013 23:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D614039E11A; Wed, 15 May 2013 08:24:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8qsHMDsV4sI; Wed, 15 May 2013 08:23:59 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E396C39E01E; Wed, 15 May 2013 08:23:59 +0200 (CEST) Message-ID: <51932A2B.1080700@alvestrand.no> Date: Wed, 15 May 2013 08:24:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> <51922959.3070708@alvestrand.no> <51931EF3.7080108@jitsi.org> In-Reply-To: <51931EF3.7080108@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 06:24:09 -0000 On 05/15/2013 07:36 AM, Emil Ivov wrote: > > On 14.05.13, 15:08, Harald Alvestrand wrote: >> On 05/14/2013 10:59 AM, Emil Ivov wrote: >>> On 14.05.13, 09:16, Emil Ivov wrote: >>>> Hey Harald, >>>> >>>> On 12.05.13, 22:55, Harald Alvestrand wrote: >>>>> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>>>>>> Or you could signal none of them and depend on the fallback case in >>>>>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>>>>> use other methods to figure out how to handle them... >>>>>> If you are referring to section 4.1 that you also pasted earlier in >>>>>> this thread, it only talks about one track, per stream, per m= line. >>>>>> This doesn't cover the conferencing case I described in my previous >>>>>> mail (quoted above). >>>>>> >>>>> Changing subject as I'm replying to a subtopic, and because I was >>>>> misunderstanding what Emil was arguing in favour of..... >>>>> >>>>> when I wrote that text, I didn't intend it to cover only one SSRC per >>>>> stream. >>>>> What I intended to say was that when, in an RTP session, a browser gets >>>>> several SSRCs that were not mentioned in signalling, it will send >>>>> several onaddstream signals to the application, each indicating a new >>>>> stream being added, which has exactly one track. >>>> Aha! OK, I understand and it sounds better now that I do. >>> Oh, just thought of something else while reading Stefan's mail: is it >>> really necessary that this should only happen in case no SSRCs have been >>> defined? Why not apply that to any unknown SSRC regardless of whether or >>> not others exist in SDP? >>> >>> The second bullet there talks about a possible race condition but I am >>> not sure I see how this could occur with valid use of O/A. >> The worrying case is: >> >> A sends offer >> B sends answer (either with or without MSID) >> B starts sending data on some SSRCs >> A receives the data, but has not yet seen the answer >> >> The two cases are: >> >> - B sends with MSID. In this case, he expects those specific IDs to be >> signalled in onaddstream. >> - B sends without MSID. In this case, he expects that A will announce a >> locally generated ID in onaddstream. >> >> A can't know the difference between those two before he sees the answer >> from B. >> In this spec, I've "solved" it by saying that we don't signal >> onaddstream before we see the answer. >> >> After the first answer has been seen, either party knows that new SSRCs >> always will be signalled, so any data on an unknown SSRC can be held >> until the negotiation announcing it is complete - or discarded as "bad >> data" if signalling doesn't happen in a reasonable time. >> >> If we were to permit unknown SSRCs when there are some MSIDs, the >> decision to announce as "Unsignalled MediaStream" or wait for the >> offer/answer announcing the MSID it should be announced with has to >> depend on some other resolution mechanism. I don't like timers, and >> haven't found a better way to do it. > I didn't get this part. While I see the race condition that occurs > during offer/answer, I am not sure I understand why a new SSRC received > mid-session by either side is ambiguous. If the application had any > intent to announce it, then presumably it would be on the verge of > initiating a new offer/answer. If that were the case, sending the new > stream/track could have been held off until completion of that > offer/answer. Exactly - IF the party sending the SSRC is able to see when the offer/answer completes. The offerer is the only party that can actually know if the offer/answer exchange is complete. So the ambiguity only applies if the answerer is able to announce new SSRCs in an answer. Is it reasonable to remove this functionality (and thereby mandating Plan B's double offer/answer) in order to achieve this functionality? > > This way one would be able to only announce SSRCs for things such as FEC > and simulcasting (where available) while simple streams could be > delivered immediately. As long as you don't need any information not carried in the RTP packet in order to announce the stream correctly, this would work. > > Emil > > From ron.even.tlv@gmail.com Wed May 15 02:26:47 2013 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 883D021F8F32 for ; Wed, 15 May 2013 02:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZQMNXFU-aZ9 for ; Wed, 15 May 2013 02:26:46 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB121F89FF for ; Wed, 15 May 2013 02:26:45 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so1405778wgh.30 for ; Wed, 15 May 2013 02:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=oJ0kDqrjyO7KSBWCF8ZzgOUc+rBTq/lpWTAA7sZfH6w=; b=KOVl0CNng/8DzXCUOzNwHxZhTjIf93nCy18uV4fo2ro1fV+1uFyiyiRPKt/3KEiD1s y0TZFwu834rVIq4XFM8eWwBAHbAo7gXCjKOKoWkt9kMAnSGdHVEZN+0Ifh0L+7SslB98 YSzQvB+qDqjYEyxC4icOHFoIR1uGPKlJVVJsvdNj899MnkoQrTUk4JWfVavUax9PVxOa bJ+NCB4GPqoxCnFEY0tH+ItNOHDUM615KdBZINuhe1O4fi7l1wKl8G4t9uVE7th4kdjZ BCRkrXMf1d0B3oSesy0/ulmJ42W/JioKRWJyMNLSEHy611ZxoO59CekXHU1se61YuPvj qcbA== X-Received: by 10.194.134.134 with SMTP id pk6mr2622199wjb.59.1368610005194; Wed, 15 May 2013 02:26:45 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id e5sm914707wiy.5.2013.05.15.02.26.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 May 2013 02:26:43 -0700 (PDT) From: "Roni Even" To: "'Justin Uberti'" , "'Emil Ivov'" References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> <518D6C76.5060606@alum.mit.edu> <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> In-Reply-To: Date: Wed, 15 May 2013 12:25:48 +0300 Message-ID: <01a501ce514e$313d1a30$93b74e90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A6_01CE5167.568B63A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfgBm/E5GwI97agwAp+/pLsCyytiXwDIVonUAlmxJFACHZYargFsQzTKAe86FxsCoc74OQFXL3XqAiJ5QYoB4ehCCAENusDml2X2oIA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:26:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A6_01CE5167.568B63A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Justin Uberti Sent: 15 May, 2013 8:53 AM To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a = problem for conferencing ( Was: New Version Notification for = draft-uberti-rtcweb-plan-00.txt ) =20 =20 =20 On Tue, May 14, 2013 at 12:46 PM, Emil Ivov wrote: Hey Stefan, On 14.05.13, 14:44, Stefan H=C3=A5kansson LK wrote: >>> SSRCs - this would be SDP >> >> Again, including SSRCs in SDP O/A is tricky in conferencing = scenarios. > > Here seems to be something that I have missed. That there are existing > implementations that do not signal SSRC is fine, and in most cases = there > would be only one audio and one video SSRC used anyway. And rtcweb = (and > Clue?) should be able to interoperate (but perhaps your web app need = to > be designed in a specific way). > > But if we design something forward looking, that can handle many > streams, that can handle layered codecs and FEC data, signaling SSRCs > seems like a must to me. > > But I have missed that this is problematic in conferencing scenarios, > could you tell me why (and I probably should know :) )? The issue that I am referring to (I describe this in an earlier mail to Harald here http://goo.gl/M8NbQ ) is that of a conference based on an RTP translator. It's basically what we do in Jitsi Videobridge. Let's say that I am a WebRTC app that can act as a conference focus and that has access to an RTP translator somewhere. I'd like to organise a conference with 10 people (you and I among them). I ask the RTP translator to allocate 10 ports for me and then I start calling participants. You are the first one that I am going to join into this new call. At this point, the only SSRC(s) that I could possibly give you are those that I am going to use. I won't be able to tell you anything for the eight other participants. For all I know, some or all of these participants could turn out to be RTP translators themselves and there could be a number of SSRCs behind each of them too. The very logical and easy thing that your webapp could do here is not to care and simply render each and every SSRC that you get. Most apps are going to be perfectly happy with that. If, on the other hand you needed me to re-offer you every time a new participant joins in order to work properly, then things would easily get quite messy even if everyone is using WebRTC. Then, note that some of the participants can be simple SIP endpoints (that's why we bothered with SDP in the first place right?) so the only way I can get their SSRCs is with some extra signalling between me and the RTP translator. This is not a problem per se, but it can only happen after the SIP participants have joined the call and started streaming data, that has reached the translator. And even then they will have no MSIDs. All in all, we would be enforcing some very laborious signalling when it is absolutely unnecessary. =20 How do you plan to demultiplex the media sources without knowing whose = SSRC belongs to whom? Consider especially the case of repair flows, for = which one must know which primary flow the repair flow corresponds with. =20 Given the complexities here, I don't think it's entirely fair to call = the signaling "absolutely unnecessary". =20 RE: This is the topology where the intermediary (RTP Translator) switch = the sources and pass through the SSRCs of the original source. In this = topology for FEC even when using a separate UDP port for the main and = repair streams the association is probably based on the SDES information = having same CNAME for both streams. If we multiplex multiple RTP streams = without having the SSRC explicitly signaled the combination of CNAME and = SSRC are still available. What we looked at is how to distinguish = between similar RTP streams ( Video was first from A and now B replaces = it). In CLUE we talked about RTP header extension for signaling the = replacement and we will probably need a new SDES packet to signal the = switch. I do not think that you can know the SSRC in advance. The SDP = should at least say how many RTP streams can be sent and received based = on the m-line using a proposed maxssrc SDP attribute. =20 Roni Even =20 ------=_NextPart_000_01A6_01CE5167.568B63A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Justin Uberti
Sent: 15 May, 2013 8:53 AM
To: = Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] = Why requiring pre-announcement of SSRCs is a problem for conferencing ( = Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt = )

 

 

 

On Tue, May 14, 2013 at 12:46 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Stefan,

On = 14.05.13, 14:44, Stefan H=C3=A5kansson LK wrote:
>>> SSRCs - = this would be SDP
>>
>> Again, including SSRCs in SDP = O/A is tricky in conferencing scenarios.
>
> Here seems to = be something that I have missed. That there are existing
> = implementations that do not signal SSRC is fine, and in most cases = there
> would be only one audio and one video SSRC used anyway. = And rtcweb (and
> Clue?) should be able to interoperate (but = perhaps your web app need to
> be designed in a specific = way).
>
> But if we design something forward looking, that = can handle many
> streams, that can handle layered codecs and FEC = data, signaling SSRCs
> seems like a must to me.
>
> = But I have missed that this is problematic in conferencing = scenarios,
> could you tell me why (and I probably should know :) = )?

The issue that I am referring to (I describe this in an = earlier mail to
Harald here http://goo.gl/M8NbQ ) is that of a conference = based on an
RTP translator. It's basically what we do in Jitsi = Videobridge.

Let's say that I am a WebRTC app that can act as a = conference focus and
that has access to an RTP translator somewhere. = I'd like to organise a
conference with 10 people (you and I among = them).

I ask the RTP translator to allocate 10 ports for me and = then I start
calling participants.

You are the first one that = I am going to join into this new call.

At this point, the only = SSRC(s) that I could possibly give you are those
that I am going to = use. I won't be able to tell you anything for the
eight other = participants. For all I know, some or all of these
participants could = turn out to be RTP translators themselves and there
could be a number = of SSRCs behind each of them too.

The very logical and easy thing = that your webapp could do here is not to
care and simply render each = and every SSRC that you get. Most apps are
going to be perfectly = happy with that.

If, on the other hand you needed me to re-offer = you every time a new
participant joins in order to work properly, = then things would easily
get quite messy even if everyone is using = WebRTC.

Then, note that some of the participants can be simple = SIP endpoints
(that's why we bothered with SDP in the first place = right?) so the only
way I can get their SSRCs is with some extra = signalling between me and
the RTP translator. This is not a problem = per se, but it can only happen
after the SIP participants have joined = the call and started streaming
data, that has reached the translator. = And even then they will have no
MSIDs.

All in all, we would be = enforcing some very laborious signalling when
it is absolutely = unnecessary.

 

How do you plan to demultiplex the media sources = without knowing whose SSRC belongs to whom? Consider especially the case = of repair flows, for which one must know which primary flow the repair = flow corresponds with.

 

Given the complexities here, I don't think it's = entirely fair to call the signaling "absolutely = unnecessary".

 

RE: This is the topology where the intermediary (RTP Translator) = switch the sources and pass through the SSRCs of the original source. In = this topology for FEC even when using a separate UDP port for the main = and repair streams the association is probably based on the SDES = information having same CNAME for both streams. If we multiplex multiple = RTP streams without having the SSRC explicitly signaled the combination = of CNAME and SSRC are still available. What we looked at is how to = distinguish between similar RTP streams ( Video was first from A and now = B replaces it). In CLUE we talked about RTP header extension for = signaling the replacement and we will probably need a new SDES packet to = signal the switch. I do not think that you=C2=A0 can know the SSRC in = advance. The SDP should at least say how many RTP streams can be sent = and received based on the m-line using a proposed maxssrc SDP = attribute.

 

Roni Even

 

------=_NextPart_000_01A6_01CE5167.568B63A0-- From steing@ifi.uio.no Wed May 15 08:11:50 2013 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 53DBF21F8F83; Wed, 15 May 2013 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGIrVo0PEbGg; Wed, 15 May 2013 08:11:45 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA821F8AD8; Wed, 15 May 2013 08:11:44 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcdMl-0005Wl-5S; Wed, 15 May 2013 17:11:43 +0200 Received: from 1x-193-157-202-195.uio.no ([193.157.202.195]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1UcdMk-0004fY-EU; Wed, 15 May 2013 17:11:43 +0200 From: Stein Gjessing Content-Type: multipart/alternative; boundary="Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93" Date: Wed, 15 May 2013 17:11:41 +0200 Message-Id: To: aqm@ietf.org, rtcweb@ietf.org, lmap@ietf.org, tsvwg@ietf.org, rmcat@ietf.org, multipathtcp@ietf.org, video-codec@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 2607 max rcpts/h 28 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 45A26AF8F0515C0711EDC4E4402EEAD2BB95E78D X-UiO-SPAM-Test: remote_host: 193.157.202.195 spam_score: -54 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 36 max/h 6 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:11:50 -0000 --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Here is an excellent venue for discussions and publication of results. Cheers,=20 Stein __________________________________________________________ Packet Video 2013 - Special Session on Low-Latency Interactive Video Sponsored by IEEE Communications Society December 12. and 13., 2013, San Jose, Ca, USA Call for papers. =20 http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1 Several years ago, it was found that users do not like video quality = fluctuations. At that time the predominant belief was that network rate = fluctuations should be minimized, in order to reasonably interoperate = with TCP in the network. This led to the creation of a number of = so-called "TCP-friendly" congestion controls that exhibit a smoother = sending rate than TCP, while avoiding to send more than a conformant TCP = under similar conditions. TFRC is perhaps the best known example of such = a congestion control mechanism. A lot has happened since then: =95 The notion of TCP-friendliness has received massive = criticism; the widespread deployment of a more aggressive TCP variant, = CUBIC, has not led to an Internet meltdown, making the case that = diverging from strict TCP-friendliness is possible. =95 Latency minimization has become a major goal, especially in = the face of =93bufferbloat=94: large delays from large buffers with = simplistic FIFO-queue management. =95 Codecs have improved; novel video codecs are able to adjust = the data rate, but modern codecs may also produce variable bitrate = transmissions with burstier packet flows than before. =95 TFRC has been embedded in the DCCP protocol, which has = probably never been used for anything other than experiments; instead of = running over DCCP, RTP-based applications now contain proprietary = congestion control mechanisms. The emergence of the RTCWEB protocol suite for real-time communication = between Web browsers has renewed the interest in developing congestion = control standards for real-time media. This time, however, the goal is = to get things right: delay should be minimized, and standards should = realize congestion control using RTP with RTCP signaling. The IETF = =93Real-time Media Congestion Avoidance Techniques=94 (RMCAT) working = group has been founded to address this need. New questions arise: what = type of congestion controls do we need? How much feedback should we = send? How do we make this work in multi-user scenarios, e.g., for video = conferencing? What should be the API between a video codec and a new = delay-based congestion controlled RTP stream? What is the quality that = can be expected from the combination of a codec and congestion control = mechanism, when we consider better metrics than plain PSNR? Topics of interest include, but are not limited to: =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms =95 Necessary RTP/RTCP extensions =95 Field experience with video codecs in a low-delay, real-time = setting =95 Interactions between applications and RTP flows =95 Failing to meet real-time schedules: impact, techniques to = detect, instrument or diagnose it Organizers: =95 Michael Welzl, University of Oslo (michawe at ifi.uio.no) =95 Stein Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://pv2013.itec.aau.at/call-for-papers/accepted-special-session= s/#ss1

Several years ago, it was found that users do not like = video quality fluctuations. At that time the predominant belief was that = network rate fluctuations should be minimized, in order to reasonably = interoperate with TCP in the network. This led to the creation of a = number of so-called "TCP-friendly" congestion controls that exhibit a = smoother sending rate than TCP, while avoiding to send more than a = conformant TCP under similar conditions. TFRC is perhaps the best known = example of such a congestion control mechanism.

A lot has = happened since then:
=95 The notion of = TCP-friendliness has received massive criticism; the widespread = deployment of a more aggressive TCP variant, CUBIC, has not led to an = Internet meltdown, making the case that diverging from strict = TCP-friendliness is possible.
=95 Latency minimization has = become a major goal, especially in the face of =93bufferbloat=94: large = delays from large buffers with simplistic FIFO-queue = management.
=95 TFRC = has been embedded in the DCCP protocol, which has probably never been = used for anything other than experiments; instead of running over DCCP, = RTP-based applications now contain proprietary congestion control = mechanisms.

The emergence of the RTCWEB protocol suite for = real-time communication between Web browsers has renewed the interest in = developing congestion control standards for real-time media. This time, = however, the goal is to get things right: delay should be minimized, and = standards should realize congestion control using RTP with RTCP = signaling. The IETF =93Real-time Media Congestion Avoidance Techniques=94 = (RMCAT) working group has been founded to address this need. New = questions arise: what type of congestion controls do we need? How much = feedback should we send? How do we make this work in multi-user = scenarios, e.g., for video conferencing? What should be the API between = a video codec and a new delay-based congestion controlled RTP stream? = What is the quality that can be expected from the combination of a codec = and congestion control mechanism, when we consider better metrics than = plain PSNR?

Topics of interest include, but are not limited = to:
= =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms
=95 = Necessary RTP/RTCP extensions
=95 Field experience with video = codecs in a low-delay, real-time setting
=95 Interactions between = applications and RTP flows
=95 Failing to meet real-time = schedules: impact, techniques to detect, instrument or diagnose = it

Organizers:
=95 Michael Welzl, University of = Oslo (michawe at ifi.uio.no)
=95 Stein = Gjessing, University of Oslo (steing at ifi.uio.no)
= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93-- From emil@sip-communicator.org Wed May 15 09:06:35 2013 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 F399F11E80D1 for ; Wed, 15 May 2013 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-1.837, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTYn291uyQDp for ; Wed, 15 May 2013 09:06:34 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6621F8FF2 for ; Wed, 15 May 2013 09:06:33 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id mz10so311471bkb.39 for ; Wed, 15 May 2013 09:06:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=xGJiwM5eYX0uygob38j+IyVhcISod6g55BuTaoNoOfQ=; b=mbwcZxxvBmM5bc1uyqVhvWj8adN1/NiymE2x538LIfNlLfrZe4UnAUB58ju/jYGZzV gpImEYN6F0lPC4lIOUjfBeOmVU6e9/U0tH8z1uYrMNVvmYywxMEOVKI4n10YciOFMFwV EAyTK9td8FETvdb0IWZ/RfpR6Zif0cwa5lXT06Yv5bFYY6TCKlYyuIiyH4xkElsDdZmd GywmddDRdShQGkGaEmKXVKDqyrZNCGhE84hdRzjUURWWauXd7VK/8aG2PpTLxrjVJEcs LGKpW8xvmynnHhQb4GhtmqZfFcAlm4iRMVQFO2ho7Qug0ojWna+8OflKPZ6m3t3Z2lHw FdfQ== X-Received: by 10.204.186.143 with SMTP id cs15mr842200bkb.104.1368633992486; Wed, 15 May 2013 09:06:32 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id j8sm1035255bky.17.2013.05.15.09.06.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 09:06:31 -0700 (PDT) Message-ID: <5193B285.8090604@jitsi.org> Date: Wed, 15 May 2013 19:06:29 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> <51922959.3070708@alvestrand.no> <51931EF3.7080108@jitsi.org> <51932A2B.1080700@alvestrand.no> In-Reply-To: <51932A2B.1080700@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn6Lq+IfTEGMgDGNjJ+xWSMSAB0Mvxk+BltR0Ur/jD4Qma4bM1wAjsEHNXsO4PDW/7KwsXm Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:06:35 -0000 On 15.05.13, 09:24, Harald Alvestrand wrote: > On 05/15/2013 07:36 AM, Emil Ivov wrote: >> >> On 14.05.13, 15:08, Harald Alvestrand wrote: >>> On 05/14/2013 10:59 AM, Emil Ivov wrote: >>>> On 14.05.13, 09:16, Emil Ivov wrote: >>>>> Hey Harald, >>>>> >>>>> On 12.05.13, 22:55, Harald Alvestrand wrote: >>>>>> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>>>>>>> Or you could signal none of them and depend on the fallback case in >>>>>>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>>>>>> use other methods to figure out how to handle them... >>>>>>> If you are referring to section 4.1 that you also pasted earlier in >>>>>>> this thread, it only talks about one track, per stream, per m= line. >>>>>>> This doesn't cover the conferencing case I described in my previous >>>>>>> mail (quoted above). >>>>>>> >>>>>> Changing subject as I'm replying to a subtopic, and because I was >>>>>> misunderstanding what Emil was arguing in favour of..... >>>>>> >>>>>> when I wrote that text, I didn't intend it to cover only one SSRC per >>>>>> stream. >>>>>> What I intended to say was that when, in an RTP session, a browser gets >>>>>> several SSRCs that were not mentioned in signalling, it will send >>>>>> several onaddstream signals to the application, each indicating a new >>>>>> stream being added, which has exactly one track. >>>>> Aha! OK, I understand and it sounds better now that I do. >>>> Oh, just thought of something else while reading Stefan's mail: is it >>>> really necessary that this should only happen in case no SSRCs have been >>>> defined? Why not apply that to any unknown SSRC regardless of whether or >>>> not others exist in SDP? >>>> >>>> The second bullet there talks about a possible race condition but I am >>>> not sure I see how this could occur with valid use of O/A. >>> The worrying case is: >>> >>> A sends offer >>> B sends answer (either with or without MSID) >>> B starts sending data on some SSRCs >>> A receives the data, but has not yet seen the answer >>> >>> The two cases are: >>> >>> - B sends with MSID. In this case, he expects those specific IDs to be >>> signalled in onaddstream. >>> - B sends without MSID. In this case, he expects that A will announce a >>> locally generated ID in onaddstream. >>> >>> A can't know the difference between those two before he sees the answer >>> from B. >>> In this spec, I've "solved" it by saying that we don't signal >>> onaddstream before we see the answer. >>> >>> After the first answer has been seen, either party knows that new SSRCs >>> always will be signalled, so any data on an unknown SSRC can be held >>> until the negotiation announcing it is complete - or discarded as "bad >>> data" if signalling doesn't happen in a reasonable time. >>> >>> If we were to permit unknown SSRCs when there are some MSIDs, the >>> decision to announce as "Unsignalled MediaStream" or wait for the >>> offer/answer announcing the MSID it should be announced with has to >>> depend on some other resolution mechanism. I don't like timers, and >>> haven't found a better way to do it. >> I didn't get this part. While I see the race condition that occurs >> during offer/answer, I am not sure I understand why a new SSRC received >> mid-session by either side is ambiguous. If the application had any >> intent to announce it, then presumably it would be on the verge of >> initiating a new offer/answer. If that were the case, sending the new >> stream/track could have been held off until completion of that >> offer/answer. > Exactly - IF the party sending the SSRC is able to see when the > offer/answer completes. > The offerer is the only party that can actually know if the offer/answer > exchange is complete. OK, got it. Then, going back to your second bullet, we could apply the same buffering as the one you currently describe there. Only this time, once we are done with the offer/answer things could go either way: we could end up either signalling a new track or determining that packets actually belong to some specific stream. If this makes sense, I'd be happy to propose text if it helps. > So the ambiguity only applies if the answerer is able to announce new > SSRCs in an answer. > Is it reasonable to remove this functionality (and thereby mandating > Plan B's double offer/answer) in order to achieve this functionality? > >> >> This way one would be able to only announce SSRCs for things such as FEC >> and simulcasting (where available) while simple streams could be >> delivered immediately. > > As long as you don't need any information not carried in the RTP packet > in order to announce the stream correctly, this would work. I suppose we'll get there eventually. RTCP is one option here but what I am personally hoping is that we'll agree that the APIs can also start providing that information so that web apps can exchange it any way they wish. Before, with, or after the SDP O/A has taken place. Cheers, Emil -- https://jitsi.org From andrew.hutton@siemens-enterprise.com Wed May 15 09:14:57 2013 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 BDCD421F8C69; Wed, 15 May 2013 09:14:57 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me5UEFsQd3TR; Wed, 15 May 2013 09:14:53 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A7D5A21F8EFC; Wed, 15 May 2013 09:14:52 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 86FF91EB8473; Wed, 15 May 2013 18:14:51 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 15 May 2013 18:14:51 +0200 From: "Hutton, Andrew" To: "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" , "dispatch-bounces@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzAgAD0rVA= Date: Wed, 15 May 2013 16:14:50 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:14:57 -0000 This is an interesting addition to the debate about how best to achieve con= nectivity for RTCWeb when the client is behind a restrictive firewall. When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-= firewall-considerations-00 we did not include this option because we did no= t see the benefit of additional transport options for TURN given that the e= xisting options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. So what would be the benefits that justify this addition transport option f= or TURN? Regarding F37 then this does need some rewording as I think the WG previous= ly discussed as it needs to talk about the need for traffic to originate fr= om the HTTP Proxy rather than allowing http traffic. That is probably worth= a separate thread. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Chenxin (Xin) > Sent: 15 May 2013 02:40 > To: behave@ietf.org; rtcweb@ietf.org; dispatch-bounces@ietf.org > Subject: [rtcweb] FW: New Version Notification for draft-chenxin- > behave-turn-websocket-00.txt >=20 > This draft defines a websocket extension to TURN to make TURN data have > the ability to transport over the websocket connection. >=20 > This method could be a option to solve the Http-fallback requirement in > RTCWEB. >=20 > F37 The browser MUST be able to send streams and > data to a peer in the presence of FWs that only > allows http(s) traffic. >=20 > Besides, Turn server with websokcet extension could be a general relay > server for some over websocket protocol, such as BFCP over websocket or > MSRP over websocket. This could satisfy some Peer to Peer scene when > using these protocol in the web environment , without a specific center > server. >=20 > Comments and suggestions are welcome. >=20 > Best Regards, > Xin >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, May 14, 2013 9:15 AM > To: Chenxin (Xin); Chenxin (Xin) > Subject: New Version Notification for draft-chenxin-behave-turn- > websocket-00.txt >=20 >=20 > A new version of I-D, draft-chenxin-behave-turn-websocket-00.txt > has been successfully submitted by Xin Chen and posted to the > IETF repository. >=20 > Filename: draft-chenxin-behave-turn-websocket > Revision: 00 > Title: Traversal Using Relays around NAT (TURN) Extensions > for Websocket Allocations > Creation date: 2013-05-13 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-chenxin- > behave-turn-websocket-00.txt > Status: http://datatracker.ietf.org/doc/draft-chenxin-behave- > turn-websocket > Htmlized: http://tools.ietf.org/html/draft-chenxin-behave-turn- > websocket-00 >=20 >=20 > Abstract: > This document defines an extension to TURN that allows it to run > over > a Websocket [RFC6455] channel. This will allow a client in a > restrictive network to exchange and relay media or data over the > websocket. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pkyzivat@alum.mit.edu Wed May 15 09:24:56 2013 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 5B9C021F8ED3 for ; Wed, 15 May 2013 09:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMc+ElYUAubo for ; Wed, 15 May 2013 09:24:50 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB521F8E4E for ; Wed, 15 May 2013 09:24:49 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id cBlk1l00A1c6gX856GQoBp; Wed, 15 May 2013 16:24:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id cGQo1l00W3ZTu2S3jGQoBw; Wed, 15 May 2013 16:24:48 +0000 Message-ID: <5193B6D0.7040301@alum.mit.edu> Date: Wed, 15 May 2013 12:24:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> In-Reply-To: <5191F948.3040402@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368635088; bh=cwHVND8OX2BS3qxj4JffG9CY7Z5LEs8yoNVqQeohcpc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jaXLkOcfSqR3i6xGKP4iBOfDKZjzbNa+24mIgGTXTTqX5YEQFhcvXXgUzI6qAW1Wn GrF5j0HQ0PpAdeicOXcBfU1yxxq55RJov5c6C3vjX2JUDmCUf5WjtWY3FrkawLtO4i Hd5yVoCqBgF3kXw+ikrnWEcjqvrjAgZSHhFY4t8RrrOgZUXqhJ5ruk/KavtmBoEn8S B2eeywmUfRzmVvw4nedqsIV5vFbABy+6EoV40j8NHYdWLveos6SduanmfWGc3T2qrk GDLcUbpswaBQEIQetcL3iXx2I8w/m2kCouMSgGDGqQjlRBzWFTeHSuvavpRZAyOo+s BuG8h8XZg/ktA== Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:24:56 -0000 On 5/14/13 4:43 AM, Stefan Håkansson LK wrote: > On 2013-05-13 19:10, Bernard Aboba wrote: >> > [MB] I think you meant to say"..but that is NOT moving along >> very well." I do not believe we can make any >> > statements as to how CLUE identifiers map to MSIDs without doing >> that taxonomy. >> >> [BA] MSID has some aspects similar to CLUE identifiers, but it is also >> trying to do some things that are WebRTC-specific. This leads me to >> wonder whether in fact those two aspects couldn't be separated. If an >> onaddstream event is thrown when a new SSRC is received, the event >> handler could handle WebRTC-specific aspects. If this were done, it >> seems to me that we might be able to utilize the concept of CLUE capture >> in both CLUE and WebRTC, and might also get some signaling >> simplifications in the process. > > As it looks like now, onaddstream would not be fired as a result of a > new SSRC being received, but rather as a result of an SDP (offer or > answer) informing the browser of the new SSRC. (Of course there is an > escape mechanism that handles this if the offer or answer contains no > SSRC info to be able to handle legacy). > > I think signaling of some kind is needed - how would the browser > otherwise know whether the new SSRC represents a new MediaStream, a new > MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for > an already set up track? > > But, exactly how the signaling is made can be discussed (and I guess > that is what we're doing now). And, I am always fond of simplifications! > > A perhaps very naive thought: could we separate things up a bit? E.g. > something like: > > * Description and negotiation of codecs, PTs, SSRCs - this would be SDP > * Description of how those SSRCs map to a MediaStream+MediaStreamTrack > structure // Clue captures > * Handling of in session changes (pause/resume, resolution changes) > > Perhaps not all of the above should be done using SDP O/A, and perhaps > we should not push all the functionality into the "core" SDP. I agree that we need to draw a line *somewhere* about what goes into SDP and what does not. I was hoping that the taxonomy document could help with this, by showing the relationships between all the *things*. Then we would have a better basis for organizing them all in layers. Thanks, Paul From bernard_aboba@hotmail.com Wed May 15 10:20:08 2013 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 CEAC921F8F4A; Wed, 15 May 2013 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3uaWNqn3+36; Wed, 15 May 2013 10:19:57 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57121F8F2E; Wed, 15 May 2013 10:19:55 -0700 (PDT) Received: from BLU169-W49 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 10:19:54 -0700 X-TMN: [YCpH8KRc73zNzffRzLHPKaHWbCqsrwAWsTybyylk99g=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_48f1096f-9729-41d6-be29-9042e4ea1ac7_" From: Bernard Aboba To: "Hutton, Andrew" , "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" Date: Wed, 15 May 2013 10:19:53 -0700 Importance: Normal In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 17:19:54.0554 (UTC) FILETIME=[6A93E1A0:01CE5190] Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:20:09 -0000 --_48f1096f-9729-41d6-be29-9042e4ea1ac7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Hutton said:=20 > When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-na= t-firewall-considerations-00 we did not include this option because we did = not see the benefit of additional transport options for TURN given that the= existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. >=20 > So what would be the benefits that justify this addition transport option= for TURN? [BA] In my experience=2C institutions with very restrictive security polic= ies (e.g. those that don't allow UDP in or out) also tend to deploy other m= easures such as deep packet inspection. So just because some traffic is a= llowed in or out on port 80 does not mean that TURN/TCP will be allowed on = that port - a DPI box may examine the traffic and complain if it doesn't se= e HTTP being used. On the other hand=2C unless the DPI box is upgraded=2C = it will also complain about websockets. So I think draft-chenxin only help= s in a situation where TURN over Websockets would be allowed when TURN/TCP = would not be. That scenario is rare=2C at least at the moment.=20 The argument for TURN over Websocket/TLS is even more difficult to make. Wh= ile DPI boxes may examine traffic destined to port 443 carefully to make su= re that TLS is really being used=2C assuming that the DPI box does not see= anything it considers fishy=2C the TLS exchange will complete and the DPI = box will lose visibility. After TLS is running=2C the DPI box does not hav= e much information available to distinguish TURN/TLS from HTTP over TLS=2C = with or without websockets -- and those things it does have (such as packet= size) are as likely to result in an objection to websocket transport as TU= RN/TLS. So I'm not sure that draft-chenxin will help in that situation eit= her. = --_48f1096f-9729-41d6-be29-9042e4ea1ac7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andrew Hutton said: =3B
<= br>
>=3B When we wrote the draft http://tools.ietf.org/html/draft-hut= ton-rtcweb-nat-firewall-considerations-00 we did not include this option be= cause we did not see the benefit of additional transport options for TURN g= iven that the existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet= our needs.
>=3B
>=3B So what would be the benefits that justify= this addition transport option for TURN?

[BA] In my experience=2C &= nbsp=3Binstitutions with very restrictive security policies (e.g. those tha= t don't allow UDP in or out) also tend to deploy other measures such as dee= p packet inspection.  =3B So just because some traffic is allowed in or= out on port 80 does not mean that TURN/TCP will be allowed on that port - = a DPI box may examine the traffic and complain if it doesn't see HTTP being= used.  =3BOn the other hand=2C unless the DPI box is upgraded=2C it wi= ll also complain about websockets.  =3BSo I think draft-chenxin only he= lps in a situation where TURN over Websockets would be allowed when TURN/TC= P would not be.  =3BThat scenario is rare=2C at least at the moment.&nb= sp=3B

The argument for TURN over Websocket/TLS is = even more difficult to make. While DPI boxes may examine traffic destined t= o port 443 carefully to make sure that TLS is really being used=2C  =3B= assuming that the DPI box does not see anything it considers fishy=2C the T= LS exchange will complete and the DPI box will lose visibility.  =3BAfter TLS is running=2C the DPI box does no= t have much information available to distinguish TURN/TLS from HTTP over TL= S=2C with or without websockets -- and those things it does have (such as p= acket size) are as likely to result in an objection to websocket transport = as TURN/TLS.  =3BSo I'm not s= ure that draft-chenxin will help in that situation either. =3B
= --_48f1096f-9729-41d6-be29-9042e4ea1ac7_-- From emil@sip-communicator.org Wed May 15 12:01:43 2013 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 0F48021F9195 for ; Wed, 15 May 2013 12:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6PZsXC0SKix for ; Wed, 15 May 2013 12:01:41 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 432A821F901D for ; Wed, 15 May 2013 12:01:28 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id na10so1211936bkb.22 for ; Wed, 15 May 2013 12:01:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=mooIEDcnLH6TtnBdOr6HZk9qS3hZVzAwtmD4hSYLQYU=; b=Ul0AzqCm3Jb7nrhq3XEy8WbGXnCFitS3RnHK6BqsYEecOlBtniI2CUVNL3BPFE89am W94sNiei+UJIT3KucNt4D0vthGy/b153Uq1PFq8HqwX1Lb+teaW731bCXEim8YbvoYWl XPqZyKqdCGEQdGIRSJ2un+fZ8Tqs7M66a4fxmoW8xaWKaI1z9z1s4lzbfG2Ywy0KFk7o R5OGiTcw74hTwbScDJdgCSZpB+kCI5Lquz7+pBffBDGy4JuxUOBQnftz8JfxyGPBhtc+ T52826JeE+LCvYsYZGT9933o6IX2flGM3zjpzC5lQtioYrxnakc1413tcjDyCd5u2nYl rKFw== X-Received: by 10.205.26.70 with SMTP id rl6mr187670bkb.54.1368644486884; Wed, 15 May 2013 12:01:26 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id kn5sm1214010bkb.20.2013.05.15.12.01.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 12:01:25 -0700 (PDT) Message-ID: <5193DB82.2030702@jitsi.org> Date: Wed, 15 May 2013 22:01:22 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Uberti References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca> <518D6C76.5060606@alum.mit.edu> <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkmH4bICGA4txyVYKCG4ltG7ZQqn7pTzMYKRMbhPS3wIwQzESfcdpaVsRjHi0f/8RfI+VLp Cc: "rtcweb@ietf.org" , Roni Even Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:01:43 -0000 Adding to what Roni said: On 15.05.13, 08:53, Justin Uberti wrote: > On Tue, May 14, 2013 at 12:46 PM, Emil Ivov The issue that I am referring to (I describe this in an earlier mail to > Harald here http://goo.gl/M8NbQ ) is that of a conference based on an > RTP translator. It's basically what we do in Jitsi Videobridge. > > Let's say that I am a WebRTC app that can act as a conference focus and > that has access to an RTP translator somewhere. I'd like to organise a > conference with 10 people (you and I among them). > > I ask the RTP translator to allocate 10 ports for me and then I start > calling participants. > > You are the first one that I am going to join into this new call. > > At this point, the only SSRC(s) that I could possibly give you are those > that I am going to use. I won't be able to tell you anything for the > eight other participants. For all I know, some or all of these > participants could turn out to be RTP translators themselves and there > could be a number of SSRCs behind each of them too. > > The very logical and easy thing that your webapp could do here is not to > care and simply render each and every SSRC that you get. Most apps are > going to be perfectly happy with that. > > If, on the other hand you needed me to re-offer you every time a new > participant joins in order to work properly, then things would easily > get quite messy even if everyone is using WebRTC. > > Then, note that some of the participants can be simple SIP endpoints > (that's why we bothered with SDP in the first place right?) so the only > way I can get their SSRCs is with some extra signalling between me and > the RTP translator. This is not a problem per se, but it can only happen > after the SIP participants have joined the call and started streaming > data, that has reached the translator. And even then they will have no > MSIDs. > > All in all, we would be enforcing some very laborious signalling when > it is absolutely unnecessary. > > > How do you plan to demultiplex the media sources without knowing whose > SSRC belongs to whom? Demultiplexing itself shouldn't be an issue. Handling the streams in the application (attributing them to a specific participant or discovering inter-stream relations) does require some knowledge of the SSRCs and the best way of solving this will always depend on the app: First, many applications may not require such information at all, as they may simply be rendering whatever stream they get. Others may need this only for presentation purposes (e.g. showing a name underneath a video). In this case they would be potentially happy with getting it later, asynchronously and merged with other display information that the focus may be sending their way. Others yet may require this information in order to allow for some level of control. One example is the case where a browser app participating in a conference, asks the conference focus (another WebRTC browser app) to ask the RTP translator (a server-side WebRTC compatible app) to stop streaming a specific SSRC in their direction. > Consider especially the case of repair flows, for > which one must know which primary flow the repair flow corresponds with. Applications using such repair flows would need to know about stream/SSRC relations relatively early in the process. Roni already indicated RTCP is widely used for this purpose and I believe this can also be a viable option here. Another option would be to have this information exchanged through application-specific signalling. Obviously, for this to work, the WebRTC APIs would need to provide means of obtaining and setting this information from/to the browser. Applications need to be able to start and stop specific streams, relate them as layers or FEC repair flows. > Given the complexities here, I don't think it's entirely fair to call > the signaling "absolutely unnecessary". My point is that it could be "absolutely unnecessary" and even prohibitive for some applications, nice to have in others, and required by others yet. Having SDP O/A as the (sole) mechanism that is available to all these categories sounds like a problem. Emil -- https://jitsi.org From bernard_aboba@hotmail.com Wed May 15 12:55:30 2013 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 AD51D21F845D for ; Wed, 15 May 2013 12:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvQuHU76dvKH for ; Wed, 15 May 2013 12:55:19 -0700 (PDT) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 2732821F848A for ; Wed, 15 May 2013 12:55:17 -0700 (PDT) Received: from BLU169-W123 ([65.55.116.72]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 12:55:10 -0700 X-TMN: [o8pnPAdOKM94BbydvXWb3rmA94HkGCH9E1eU7Cd5cbo=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c8c4ccd1-c257-4981-a13e-af4c11d67cb2_" From: Bernard Aboba To: Emil Ivov Date: Wed, 15 May 2013 12:55:09 -0700 Importance: Normal In-Reply-To: <5193DB82.2030702@jitsi.org> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, , , <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org>,<519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org>, , <5193DB82.2030702@jitsi.org> MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 19:55:10.0095 (UTC) FILETIME=[1B12A1F0:01CE51A6] Cc: "rtcweb@ietf.org" , Roni Even Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:55:30 -0000 --_c8c4ccd1-c257-4981-a13e-af4c11d67cb2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emil said:=20 >> How do you plan to demultiplex the media sources without knowing whose> = > SSRC belongs to whom?>> Demultiplexing itself shouldn't be an issue.... >= > First=2C many applications may not require such information at all=2C as > they may simply be rendering whatever stream they get. >=20 > Others may need this only for presentation purposes (e.g. showing a name > underneath a video). In this case they would be potentially happy with > getting it later=2C asynchronously and merged with other display > information that the focus may be sending their way. [BA] Scenarios where the media can be directly rendered=2C or the required = information can arrive later are idealfor potential handling outside SDP (e= .g. within RTP/RTCP). So "known whose SSRC belongs to whom" can be handle= d adequately without SDP in simple cases (e.g. single media stream per part= icipant).=20 > > Consider especially the case of repair flows=2C for > > which one must know which primary flow the repair flow corresponds with= . >=20 > Applications using such repair flows would need to know about > stream/SSRC relations relatively early in the process. Roni already > indicated RTCP is widely used for this purpose and I believe this can > also be a viable option here.> [BA] I believe that RTP and RTCP can be used successfully to provide repair= and FEC relationships=2C as well as simulcast and layered coding informati= on. However=2C this is trickier than the "simple rendering" or "name" case= =2C because until the relationships are known to the endpoints it may be di= fficult for them to properly utilize those streams. Having a reliable sign= aling mechanism only solves the problem once the Answer has arrived=2C but = it may be desirable to be able to handle media before then. Similarly=2C R= TP/RTCP info only helps once it has arrived=2C and of course packets can be= lost. Overall=2C I believe it is possible to make things work without SDP= over the wire=2C assuming our expectations are set appropriately. Having = RTP/RTCP alternatives available is useful within a framework such as WebRTC= where there is no mandatory signaling mechanism=2C but also in scenarios w= here rapid response to changing conditions is needed (such as in congestion= control). =20 > Obviously=2C for this to work=2C the WebRTC APIs would need to provide me= ans > of obtaining and setting this information from/to the browser. > Applications need to be able to start and stop specific streams=2C relate > them as layers or FEC repair flows. [BA] I hope that you're not talking about application-specific RTCP packets= =3B I would prefer to avoid that if possible. =20 > > Given the complexities here=2C I don't think it's entirely fair to call > > the signaling "absolutely unnecessary". >=20 > My point is that it could be "absolutely unnecessary" and even > prohibitive for some applications=2C nice to have in others=2C and requir= ed > by others yet. [BA] There are a number of current scenarios in which frequent signaling is= not desirable and in which RTP/RTCP is widely used instead. As an exampl= e=2C it is one thing to use SDP to communicate the envelope of what a recei= ver can handle (resolutions=2C frame rates=2C etc.). It is another to use = SDP to attempt to signal changes that can happen as frequently as multiple = times a second. If we don't make it possible for that to be "absolutely un= necessary" (or worse=2C not make it clear that this undesirable) we will ha= ve been negligent.=20 > Having SDP O/A as the (sole) mechanism that is available to all these > categories sounds like a problem. [BA] Since SDP O/A isn't a universal hammer=2C depending on it exclusively = is a fundamental design mistake. = --_c8c4ccd1-c257-4981-a13e-af4c11d67cb2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Emil said: =3B

&= gt=3B>=3B =3BHow do you plan to de= multiplex the media sources without knowing whose
>=3B >=3B SSRC belongs to whom?
=
>=3B
>=3B Demultiplexing itself shouldn't be an issue...= . =3B
>=3B =3B
>=3B First=2C many applications may not require such informat= ion at all=2C as
>=3B they may simply be rendering whatever stream the= y get.
>=3B
>=3B Others may need this only for presentation purp= oses (e.g. showing a name
>=3B underneath a video). In this case they = would be potentially happy with
>=3B getting it later=2C asynchronousl= y and merged with other display
>=3B information that the focus may be= sending their way.

[BA] Scenarios where the media= can be directly rendered=2C or the required information can arrive later a= re ideal
for potential handling outside SDP (e.g. within RTP/RTCP= ).  =3B So "known whose SSRC belongs to whom" can be handled adequately= without SDP in simple cases (e.g. single media stream per participant).&nb= sp=3B

>=3B >=3B Consider especially the case o= f repair flows=2C for
>=3B >=3B which one must know which primary fl= ow the repair flow corresponds with.
>=3B
>=3B Applications usin= g such repair flows would need to know about
>=3B stream/SSRC relation= s relatively early in the process. Roni already
>=3B indicated RTCP is= widely used for this purpose and I believe this can
>=3B also be a vi= able option here.
>=3B

[BA] I believe = that RTP and RTCP can be used successfully to provide repair and FEC relati= onships=2C as well as simulcast and layered coding information.  =3BHow= ever=2C this is trickier than the "simple rendering" or "name" case=2C beca= use until the relationships are known to the endpoints it may be difficult = for them to properly utilize those streams.  =3BHaving a reliable signa= ling mechanism only solves the problem once the Answer has arrived=2C but i= t may be desirable to be able to handle media before then.  =3BSimilarl= y=2C RTP/RTCP info only helps once it has arrived=2C and of course packets = can be lost.  =3BOverall=2C I believe it is possible to make things wor= k without SDP over the wire=2C assuming our expectations are set appropriat= ely.  =3BHaving RTP/RTCP alternatives available is useful within a fram= ework such as WebRTC where there is no mandatory signaling mechanism=2C but= also in scenarios where rapid response to changing conditions is needed (s= uch as in congestion control).  =3B

>=3B Obv= iously=2C for this to work=2C the WebRTC APIs would need to provide means>=3B of obtaining and setting this information from/to the browser.
= >=3B Applications need to be able to start and stop specific streams=2C r= elate
>=3B them as layers or FEC repair flows.

[BA] I hope that you're not talking about application-specific RTCP packe= ts=3B I would prefer to avoid that if possible.  =3B

>=3B >=3B Given the complexities here=2C I don't think it's enti= rely fair to call
>=3B >=3B the signaling "absolutely unnecessary".<= br>>=3B
>=3B My point is that it could be "absolutely unnecessary" = and even
>=3B prohibitive for some applications=2C nice to have in oth= ers=2C and required
>=3B by others yet.

[BA] = There are a number of current scenarios in which frequent signaling is not = desirable and in which RTP/RTCP is widely used instead.  =3B As an exam= ple=2C it is one thing to use SDP to communicate the envelope of what a rec= eiver can handle (resolutions=2C frame rates=2C etc.).  =3BIt is anothe= r to use SDP to attempt to signal changes that can happen as frequently as = multiple times a second.  =3BIf we don't make it possible for that to b= e "absolutely unnecessary" (or worse=2C not make it clear that this undesir= able) we will have been negligent. =3B

>=3B = Having SDP O/A as the (sole) mechanism that is available to all these
&g= t=3B categories sounds like a problem.

[BA] Since = SDP O/A isn't a universal hammer=2C depending on it exclusively is a fundam= ental design mistake. =3B
= --_c8c4ccd1-c257-4981-a13e-af4c11d67cb2_-- From mary.ietf.barnes@gmail.com Wed May 15 14:37:16 2013 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 13B1011E80DF for ; Wed, 15 May 2013 14:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMgbWKZ0OUoo for ; Wed, 15 May 2013 14:37:11 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id F265611E80D2 for ; Wed, 15 May 2013 14:37:10 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id q19so1585296qeb.27 for ; Wed, 15 May 2013 14:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=YSFyVYaDdHMx3h4woPIFszwrzlBZXgdbPTXr2JeDlEE=; b=LAEqXsmGpW3FR+Da6k1SGCW3UYLTtEo7Q+j6s7NuKyH6QDmzA241Lok3oPId6XrbTn aiZrwxT3b6yPrYRz4RFE5uZ1YtTDrUQxkdit9wJLLIqVytNZWn6mUIiiuPoLUasrV87i cZbT0W59sfdm8/P7MqOOCe5BOfABTEr75nOIPzdty/BC7w5LFPTlDk/d6oJ3KDo60qA/ v4F8yQFl2HsdihdAaMyeER2mbDqJBsDGdJnvEtKYUGjdWGxQpkM8EHB4ZtsdEXyTA+Gc 3SWe/m4pCryq+UYDjAVSxUJ0o8j3cyaMhWsoreYX0EecPg0TPiz9uT8OOz5aLeprPcqP MztQ== MIME-Version: 1.0 X-Received: by 10.229.72.130 with SMTP id m2mr12406986qcj.122.1368653830324; Wed, 15 May 2013 14:37:10 -0700 (PDT) Received: by 10.49.116.172 with HTTP; Wed, 15 May 2013 14:37:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 May 2013 16:37:10 -0500 Message-ID: From: Mary Barnes To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Fwd: Reminder: CLUE WG Interim Meeting - May 21st, 2013 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 21:37:16 -0000 Just in case any of you all are interested in what's going on with CLUE... ---------- Forwarded message ---------- From: Mary Barnes Date: Tue, May 14, 2013 at 3:41 PM Subject: Reminder: CLUE WG Interim Meeting - May 21st, 2013 To: CLUE Cc: Paul Kyzivat A reminder that we have scheduled a virtual (Webex) interim meeting for CLUE WG for May 21st, 2013 starting at 9am central. The Webex details are available here and on the wiki: http://www.ietf.org/mail-archive/web/clue/current/msg02547.html An agenda has been posted to the interim proceedings: http://www.ietf.org/proceedings/interim/2013/05/21/clue/proceedings.html The presentations will also be available there. At this time, there are no revised documents. Any document updates should be done no later than 5pm Pacific on Friday, May 17th. Presentations should be sent to the chairs no later than noon Pacific on Monday, May 20th. Also, an important reminder that there will be an MMUSIC interim meeting next week as well: http://www.ietf.org/mail-archive/web/clue/current/msg02569.html I strongly encourage CLUE folks to attend that session, as well. There has been lots of discussion on both the MMUSIC and RTCWEB WG mailing lists with regards to handling multiple media sources, including discussion of the following drafts from the RTCWEB WG: http://www.ietf.org/id/draft-uberti-rtcweb-plan-00.txt http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://datatracker.ietf.org/doc/draft-roach-rtcweb-glareless-add/ Folks that are not subscribed to the RTCWEB mailing list should at least review the discussion threads for those documents. Regards, Mary CLUE WG co-chair From emil@sip-communicator.org Wed May 15 16:41:28 2013 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 A26EE11E80D7 for ; Wed, 15 May 2013 16:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYqm3qPau6bn for ; Wed, 15 May 2013 16:41:28 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BFAAA11E80D3 for ; Wed, 15 May 2013 16:41:27 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id z7so1358596eaf.5 for ; Wed, 15 May 2013 16:41:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=AMaMDu1vbf79uAIyAVYrDD/zQDdiFRB2IrInBRmiOZw=; b=E55MgZ4FfK9FFk0sG4qTzCWnsJpn27/VpqQewGbTRxzuRyd7gIOgBpYW45UGfN1lGF nQ8pSdVXi3be59GVd4ZwIOAk0h4QoT+sTyrsFxfsZx7UVfESa/7lLhgaRVpOnwH1J71p LB9QpcX+oCoj9KcrdZVww2NkPZ6PmwUHHR82FQyojx9bJyCjOa+5Wkp4HawowQpyAxBb rpgMvxb1Wng4fYeNpqFOqPvwbOmKRBJQLjpMAQphrrPBVANzNrQw7Tq7NwFV41lrKAH7 xIziOFiIFTfw5pJvmxnmlihP53p7UPLXsFv1yxZGA+4Po8H6VDxBUawX3Svof2VXzMiY VE3A== X-Received: by 10.15.108.6 with SMTP id cc6mr48628869eeb.28.1368661286527; Wed, 15 May 2013 16:41:26 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id bp51sm6995097eeb.5.2013.05.15.16.41.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 16:41:25 -0700 (PDT) Message-ID: <51941D24.9090107@jitsi.org> Date: Thu, 16 May 2013 02:41:24 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Bernard Aboba References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, , , <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org>, <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org>, , <5193DB82.2030702@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlm8YuvNDlfBrWgu4xoibilsDNGCzd08eSBphmsQcU+p5QE4GiX2rNKcB7rtXLMcuf9/Pje Cc: "rtcweb@ietf.org" , Roni Even Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 23:41:28 -0000 On 15.05.13, 22:55, Bernard Aboba wrote: >> Obviously, for this to work, the WebRTC APIs would need to provide means >> of obtaining and setting this information from/to the browser. >> Applications need to be able to start and stop specific streams, relate >> them as layers or FEC repair flows. > > [BA] I hope that you're not talking about application-specific RTCP > packets; I would prefer to avoid that if possible. Not at all. In this particular case I was referring to the possibility of using application-specific signalling that two browsers (or a browser and some other app) can use to signal such things. Such signalling could go through websockets, clue data channels or e-mail for all it matters: it would be up to the application. -- https://jitsi.org From tireddy@cisco.com Wed May 15 21:56:01 2013 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 7ACD321F8F4D; Wed, 15 May 2013 21:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5fSawCtmv0q; Wed, 15 May 2013 21:55:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 75D7021F8EED; Wed, 15 May 2013 21:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9001; q=dns/txt; s=iport; t=1368680156; x=1369889756; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LljL0BCgc/S9OlnTFzucJdIefHsjX6E/UAyJHLdOQgQ=; b=PIexw9Qf5AmI9ND4K6nE9XGte8JPHzzaIVxWsMeT8Je5e+P+Wj2pCFIt rI65Jm1fvzKXgxLJ0qP6o2AwnE1iALNpnfx8UNFMaaPovHc2ZGSDi8DLt DHWrGSHxb+IbVqgRCB07/g/hXGEginpVv6nPPaBkIp4tDENzgspCnp9z2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFlmlFGtJV2b/2dsb2JhbABbgkNEN8B9gQEWdIIfAQEBAwEtSgcLAgEIEQQBAQsdBzIUCAEIAgQBEgiHfgYMvHiNeXQ3AYJ0YQOYXJAWgViBOIFqPA X-IronPort-AV: E=Sophos;i="4.87,681,1363132800"; d="scan'208,217";a="211108161" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 16 May 2013 04:55:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4G4tt2i000540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 04:55:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 15 May 2013 23:55:55 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Bernard Aboba , "Hutton, Andrew" , "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUYdcX1lIz7P+wE24JCIYCsgyvJkG0ZaAgABst3A= Date: Thu, 16 May 2013 04:55:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6DB83@xmb-rcd-x10.cisco.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.83] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 04:56:01 -0000 --_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline [TR] From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Wednesday, May 15, 2013 10:50 PM To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave= -turn-websocket-00.txt Andrew Hutton said: > When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-na= t-firewall-considerations-00 we did not include this option because we did = not see the benefit of additional transport options for TURN given that the= existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. > > So what would be the benefits that justify this addition transport option= for TURN? [BA] In my experience, institutions with very restrictive security policie= s (e.g. those that don't allow UDP in or out) also tend to deploy other mea= sures such as deep packet inspection. So just because some traffic is all= owed in or out on port 80 does not mean that TURN/TCP will be allowed on th= at port - a DPI box may examine the traffic and complain if it doesn't see = HTTP being used. On the other hand, unless the DPI box is upgraded, it wil= l also complain about websockets. So I think draft-chenxin only helps in a= situation where TURN over Websockets would be allowed when TURN/TCP would = not be. That scenario is rare, at least at the moment. The argument for TURN over Websocket/TLS is even more difficult to make. Wh= ile DPI boxes may examine traffic destined to port 443 carefully to make su= re that TLS is really being used, assuming that the DPI box does not see a= nything it considers fishy, the TLS exchange will complete and the DPI box = will lose visibility. After TLS is running, the DPI box does not have much= information available to distinguish TURN/TLS from HTTP over TLS, with or = without websockets -- and those things it does have (such as packet size) a= re as likely to result in an objection to websocket transport as TURN/TLS. = So I'm not sure that draft-chenxin will help in that situation either. [TR] Firewalls with restrictive policies in addition to DPI use various oth= er mechanisms like reputation, heuristics, HTTPS proxy etc to classify the = traffic and block it. --Tiru. --_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline [TR]

 

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, May 15, 2013 10:50 PM
To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org<= br> Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin= -behave-turn-websocket-00.txt

 

Andrew Hutton said: =

> When we wrote the draft http://tools.ietf.org/html/= draft-hutton-rtcweb-nat-firewall-considerations-00 we did not include this = option because we did not see the benefit of additional transport options for TURN given that the existing options (E.g. TURN/TCP and TURN/T= LS) seem to be meet our needs.
>
> So what would be the benefits that justify this addition transport opt= ion for TURN?

[BA] In my experience,  institutions with very restrictive security po= licies (e.g. those that don't allow UDP in or out) also tend to deploy othe= r measures such as deep packet inspection.   So just because some traf= fic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine th= e traffic and complain if it doesn't see HTTP being used.  On the othe= r hand, unless the DPI box is upgraded, it will also complain about websock= ets.  So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP w= ould not be.  That scenario is rare, at least at the moment. 

 

The argument for TURN over Websocket/TLS is even more di= fficult to make. While DPI boxes may examine traffic destined to port 443 c= arefully to make sure that TLS is really being used,  assuming that the DPI box does not see anything it considers fishy, the TLS exchang= e will complete and the DPI box will lose visibility.  After TLS is ru= nning, the DPI box does not have much information available to distinguish = TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as packet size) = are as likely to result in an objection to websocket transport as TURN/TLS.=  So I'm not sure that draft-chenxin will help in that situation eithe= r. 

 

[TR] Firewalls with restrictive policies in addition to DPI = use various other mechanisms like reputation, heuristics, HTTPS proxy etc t= o classify the traffic and block it.

 

--Tiru.

--_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_-- From andrew.hutton@siemens-enterprise.com Thu May 16 01:28:11 2013 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 EBC6121F854D; Thu, 16 May 2013 01:28:10 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnNNxCzXl5wa; Thu, 16 May 2013 01:28:06 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7921F8E84; Thu, 16 May 2013 01:28:06 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 67B5023F0481; Thu, 16 May 2013 10:28:04 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 16 May 2013 10:28:04 +0200 From: "Hutton, Andrew" To: Bernard Aboba , "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzAgAD0rVD///UigIABF7SQ Date: Thu, 16 May 2013 08:28:03 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:28:11 -0000 I agree with Bernard's comments regarding the impact of DPI but of course s= uch DPI devices do what they do and we can't and even don't want to stop th= em from doing it. However for the case when policy is such that the firewal= l will only allow traffic to traverse that comes from the HTTP Proxy or a n= etwork specific TURN server and there is no deliberate policy to block WebR= TC media we need a solution and this is what draft-hutton-rtcweb-nat-firewa= ll-considerations-00 addresses. So far I don't see the benefit that TURN over websockets would have in this= scenario and it needs additional implementation in the browser and the TUR= N server. Regards Andy > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: 15 May 2013 18:20 > To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org > Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- > behave-turn-websocket-00.txt >=20 > Andrew Hutton said: > > When we wrote the draft http://tools.ietf.org/html/draft-hutton- > rtcweb-nat-firewall-considerations-00 we did not include this option > because we did not see the benefit of additional transport options for > TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) seem > to be meet our needs. > > > > So what would be the benefits that justify this addition transport > option for TURN? >=20 > [BA] In my experience, =A0institutions with very restrictive security > policies (e.g. those that don't allow UDP in or out) also tend to > deploy other measures such as deep packet inspection. =A0 So just because > some traffic is allowed in or out on port 80 does not mean that > TURN/TCP will be allowed on that port - a DPI box may examine the > traffic and complain if it doesn't see HTTP being used. =A0On the other > hand, unless the DPI box is upgraded, it will also complain about > websockets. =A0So I think draft-chenxin only helps in a situation where > TURN over Websockets would be allowed when TURN/TCP would not be. =A0That > scenario is rare, at least at the moment. > > The argument for TURN over Websocket/TLS is even more difficult to > make. While DPI boxes may examine traffic destined to port 443 > carefully to make sure that TLS is really being used, =A0assuming that > the DPI box does not see anything it considers fishy, the TLS exchange > will complete and the DPI box will lose visibility. =A0After TLS is > running, the DPI box does not have much information available to > distinguish TURN/TLS from HTTP over TLS, with or without websockets -- > and those things it does have (such as packet size) are as likely to > result in an objection to websocket transport as TURN/TLS. =A0So I'm not > sure that draft-chenxin will help in that situation either. From stefan.lk.hakansson@ericsson.com Thu May 16 02:45:31 2013 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 0452D21F8FDD for ; Thu, 16 May 2013 02:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd6DDDE+meY8 for ; Thu, 16 May 2013 02:45:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36621F8F69 for ; Thu, 16 May 2013 02:45:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-c0-5194aab37988 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 43.E2.28165.3BAA4915; Thu, 16 May 2013 11:45:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Thu, 16 May 2013 11:45:23 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Emil Ivov Thread-Topic: Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) Thread-Index: AQHOUNuv7sx/DKV64Ei4hdgR8OpAYQ== Date: Thu, 16 May 2013 09:45:21 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvre7mVVMCDXpPq1is2TmBxWLtv3Z2 ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlbGj8RlzwUr5ir/z9rA0MLZLdjFyckgImEg0 bzvPBGGLSVy4t56ti5GLQ0jgMKPE/DO9jBDOEkaJ83sus4BUsQkESmzdt4ANxBYRkJfoblsE 1s0soC5xZ/E5dpAGYYE5jBK/9q4C6xYRmMsosW/JW6gOPYkpW1cwg9gsAqoSCxpfARVxcPAK +Eo0vy2B2LaGTWLd02Ng2xiBbvp+ag3UBnGJW0/mQ90qILFkz3lmCFtU4uXjf6wQtpLEjw2X WCDq9SRuTJ3CBmFrSyxb+BqsnldAUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmT Xm64iREYDwe3/NbdwXjqnMghRmkOFiVx3iSuxkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jIJrLt6RYG++8ezJDKPjexj+cn2wzru2WmBr8e7dCiXqnk75Pff7+DQzplXfaTdzc7N+nf7f ZtGmGx7Tb/vqi9eYnC25ybv+Xt7yoNch/Dk9U9V6dU9/uKfct1JoUpco9z/TY9+ZNZZuqZ/O JPx57c9D81mOrxN99WrryvdpdksSSvds9kxwiFZiKc5INNRiLipOBADsJQyOVQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:45:31 -0000 On 5/14/13 9:46 PM, Emil Ivov wrote:=0A= > Hey Stefan,=0A= >=0A= > On 14.05.13, 14:44, Stefan H=E5kansson LK wrote:=0A= >>>> SSRCs - this would be SDP=0A= >>>=0A= >>> Again, including SSRCs in SDP O/A is tricky in conferencing scenarios.= =0A= >>=0A= >> Here seems to be something that I have missed. That there are existing= =0A= >> implementations that do not signal SSRC is fine, and in most cases there= =0A= >> would be only one audio and one video SSRC used anyway. And rtcweb (and= =0A= >> Clue?) should be able to interoperate (but perhaps your web app need to= =0A= >> be designed in a specific way).=0A= >>=0A= >> But if we design something forward looking, that can handle many=0A= >> streams, that can handle layered codecs and FEC data, signaling SSRCs=0A= >> seems like a must to me.=0A= >>=0A= >> But I have missed that this is problematic in conferencing scenarios,=0A= >> could you tell me why (and I probably should know :) )?=0A= >=0A= > The issue that I am referring to (I describe this in an earlier mail to= =0A= > Harald here http://goo.gl/M8NbQ ) is that of a conference based on an=0A= > RTP translator. It's basically what we do in Jitsi Videobridge.=0A= >=0A= > Let's say that I am a WebRTC app that can act as a conference focus and= =0A= > that has access to an RTP translator somewhere. I'd like to organise a=0A= > conference with 10 people (you and I among them).=0A= >=0A= > I ask the RTP translator to allocate 10 ports for me and then I start=0A= > calling participants.=0A= >=0A= > You are the first one that I am going to join into this new call.=0A= >=0A= > At this point, the only SSRC(s) that I could possibly give you are those= =0A= > that I am going to use. I won't be able to tell you anything for the=0A= > eight other participants. For all I know, some or all of these=0A= > participants could turn out to be RTP translators themselves and there=0A= > could be a number of SSRCs behind each of them too.=0A= >=0A= > The very logical and easy thing that your webapp could do here is not to= =0A= > care and simply render each and every SSRC that you get. Most apps are=0A= > going to be perfectly happy with that.=0A= >=0A= > If, on the other hand you needed me to re-offer you every time a new=0A= > participant joins in order to work properly, then things would easily=0A= > get quite messy even if everyone is using WebRTC.=0A= >=0A= > Then, note that some of the participants can be simple SIP endpoints=0A= > (that's why we bothered with SDP in the first place right?) so the only= =0A= > way I can get their SSRCs is with some extra signalling between me and=0A= > the RTP translator. This is not a problem per se, but it can only happen= =0A= > after the SIP participants have joined the call and started streaming=0A= > data, that has reached the translator. And even then they will have no=0A= > MSIDs.=0A= >=0A= > All in all, we would be enforcing some very laborious signalling when=0A= > it is absolutely unnecessary.=0A= =0A= Thanks, I then understand the use-case you're envisioning.=0A= =0A= I think it could work under certain conditions, but as soon as there are = =0A= repair flows, enhancement layers or simulcast involved, there is a need =0A= anyway to somehow signal what each SSRC represents. Then it is another =0A= question if it happens via SDP or via RTP header extensions or some =0A= other means.=0A= =0A= There was a discussion at the Stockholm rtcweb interim on what =0A= topologies that would be supported, but I fail to remember if this case =0A= was included or excluded.=0A= =0A= It also seems to me that people have quite different views in the =0A= discussion. One view seems to be that SDP exchanges should be used even =0A= for things like pause/resume, resolution changes, another that we should = =0A= avoid SDP exchanges even when people join/leave a conference.=0A= =0A= >=0A= > Does this make sense?=0A= > Emil=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Thu May 16 02:46:14 2013 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 D61B421F91D8 for ; Thu, 16 May 2013 02:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+7aF5Obj0qC for ; Thu, 16 May 2013 02:46:09 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5523521F8F69 for ; Thu, 16 May 2013 02:46:09 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-e8-5194aadf4a8b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 79.95.01956.FDAA4915; Thu, 16 May 2013 11:46:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 16 May 2013 11:46:07 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOUYjAXhNXNUW5MEGy0yR4eyfehw== Date: Thu, 16 May 2013 09:46:06 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CCED8@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <5193B6D0.7040301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre6DVVMCDXbe57NYseEAq8Xaf+3s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldGy6nnLAV94hVLpz1jbGC8ItTFyMkhIWAi 0TDrPwuELSZx4d56ti5GLg4hgcOMEquPTWCBcJYwSlzt280GUsUmECixdd8CIJuDQ0RAQ2LS VjWQMLOAusSdxefYQWxhgRCJU2e6wWwRgVCJkzsvskLYehIbfz9mArFZBFQlrjxpALN5BXwl Dj39D1YjJPCJVWLxoVQQmxHooO+n1jBBzBeXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSfzY cIkFol5P4sbUKWwQtrbEsoWvmSF2CUqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz 0svNNzECY+Hglt8GOxg33Rc7xCjNwaIkzpvM1RgoJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gdHgXLXXzEVPY7cevjjzff6NGg9xpW+3zgRYvD1WEqhntFDAXv5QXe0Ui0mR0glZXXFflF5x zd221PpB/PIt3IVzzvm6eHpzXwtyEvYLnWUfc4fDODWIcd/6ZHGrefYOamK370TPa+136mk1 lvFPY92fe3WKcFdXUsjzbZ67LgR2RVkHqNauUmIpzkg01GIuKk4EAON/AndTAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:46:14 -0000 On 5/15/13 6:25 PM, Paul Kyzivat wrote:=0A= > On 5/14/13 4:43 AM, Stefan H=E5kansson LK wrote:=0A= >> On 2013-05-13 19:10, Bernard Aboba wrote:=0A= >>> > [MB] I think you meant to say"..but that is NOT moving along=0A= >>> very well." I do not believe we can make any=0A= >>> > statements as to how CLUE identifiers map to MSIDs without doing=0A= >>> that taxonomy.=0A= >>>=0A= >>> [BA] MSID has some aspects similar to CLUE identifiers, but it is also= =0A= >>> trying to do some things that are WebRTC-specific. This leads me to=0A= >>> wonder whether in fact those two aspects couldn't be separated. If an= =0A= >>> onaddstream event is thrown when a new SSRC is received, the event=0A= >>> handler could handle WebRTC-specific aspects. If this were done, it=0A= >>> seems to me that we might be able to utilize the concept of CLUE captur= e=0A= >>> in both CLUE and WebRTC, and might also get some signaling=0A= >>> simplifications in the process.=0A= >>=0A= >> As it looks like now, onaddstream would not be fired as a result of a=0A= >> new SSRC being received, but rather as a result of an SDP (offer or=0A= >> answer) informing the browser of the new SSRC. (Of course there is an=0A= >> escape mechanism that handles this if the offer or answer contains no=0A= >> SSRC info to be able to handle legacy).=0A= >>=0A= >> I think signaling of some kind is needed - how would the browser=0A= >> otherwise know whether the new SSRC represents a new MediaStream, a new= =0A= >> MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for= =0A= >> an already set up track?=0A= >>=0A= >> But, exactly how the signaling is made can be discussed (and I guess=0A= >> that is what we're doing now). And, I am always fond of simplifications!= =0A= >>=0A= >> A perhaps very naive thought: could we separate things up a bit? E.g.=0A= >> something like:=0A= >>=0A= >> * Description and negotiation of codecs, PTs, SSRCs - this would be SDP= =0A= >> * Description of how those SSRCs map to a MediaStream+MediaStreamTrack= =0A= >> structure // Clue captures=0A= >> * Handling of in session changes (pause/resume, resolution changes)=0A= >>=0A= >> Perhaps not all of the above should be done using SDP O/A, and perhaps= =0A= >> we should not push all the functionality into the "core" SDP.=0A= >=0A= > I agree that we need to draw a line *somewhere* about what goes into SDP= =0A= > and what does not.=0A= >=0A= > I was hoping that the taxonomy document could help with this, by showing= =0A= > the relationships between all the *things*. Then we would have a better= =0A= > basis for organizing them all in layers.=0A= =0A= That is probably the right place to start.=0A= =0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From hangzhou.chenxin@huawei.com Thu May 16 04:42:50 2013 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 9D0BB21F8FED; Thu, 16 May 2013 04:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfU6KDte31Br; Thu, 16 May 2013 04:42:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9021F905F; Thu, 16 May 2013 04:42:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASV95737; Thu, 16 May 2013 11:42:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 12:41:55 +0100 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 12:42:28 +0100 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Thu, 16 May 2013 19:42:22 +0800 From: "Chenxin (Xin)" To: Bernard Aboba , "Hutton, Andrew" , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUYdZvexTilrlAE6hVSVk7wP2WJkF96iAgAGyz4A= Date: Thu, 16 May 2013 11:42:21 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DDA82@szxeml538-mbs.china.huawei.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: multipart/alternative; boundary="_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:42:50 -0000 --_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reply inline Best Regards, Xin From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Thursday, May 16, 2013 1:20 AM To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin-behave= -turn-websocket-00.txt Andrew Hutton said: > When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-na= t-firewall-considerations-00 we did not include this option because we did = not see the benefit of additional transport options for TURN given that the= existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. > > So what would be the benefits that justify this addition transport option= for TURN? [BA] In my experience, institutions with very restrictive security policie= s (e.g. those that don't allow UDP in or out) also tend to deploy other mea= sures such as deep packet inspection. So just because some traffic is all= owed in or out on port 80 does not mean that TURN/TCP will be allowed on th= at port - a DPI box may examine the traffic and complain if it doesn't see = HTTP being used. On the other hand, unless the DPI box is upgraded, it wil= l also complain about websockets. So I think draft-chenxin only helps in a= situation where TURN over Websockets would be allowed when TURN/TCP would = not be. That scenario is rare, at least at the moment. [Xin] With the development of websocket, there will be more and more web = servers which support websocket. That means websocket will be treated the s= ame as HTTP in the policy of FW or proxy server. Comparing with transportin= g the TCP packet directly on the Http port, Upgrade the HTTP to websocket a= nd transport the data over it is more friendly to FW and proxy server. The = possibility of the block of the websocket data by the DPI is less than the= TCP data. So I think the benefit of turn over websocket is that it will i= ncrease the success rate when the rtcweb is used in the restrictive network= , such as in airport or some hotel. The argument for TURN over Websocket/TLS is even more difficult to make. Wh= ile DPI boxes may examine traffic destined to port 443 carefully to make su= re that TLS is really being used, assuming that the DPI box does not see a= nything it considers fishy, the TLS exchange will complete and the DPI box = will lose visibility. After TLS is running, the DPI box does not have much= information available to distinguish TURN/TLS from HTTP over TLS, with or = without websockets -- and those things it does have (such as packet size) a= re as likely to result in an objection to websocket transport as TURN/TLS. = So I'm not sure that draft-chenxin will help in that situation either. [Xin] If DPI can't inspect the content of TLS data, there is no difference= . But considering DPI-SSL, which could inspect the TLS session, the turn ov= er websocket will be has the benefit which has been said before. --_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reply inli= ne

 = ;

Best Regards,

     Xi= n

 = ;

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, May 16, 2013 1:20 AM
To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org<= br> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin= -behave-turn-websocket-00.txt

 

Andrew Hut= ton said: 

> When we wrote the draft http://tools= .ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00 we did no= t include this option because we did not see the benefit of additional transport options for TURN given that the existing options (E.g. TURN/TCP = and TURN/TLS) seem to be meet our needs.
>
> So what would be the benefits that justify this addition transport opt= ion for TURN?

[BA] In my experience,  institutions with very restrictive security po= licies (e.g. those that don't allow UDP in or out) also tend to deploy othe= r measures such as deep packet inspection.   So just because some traf= fic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine th= e traffic and complain if it doesn't see HTTP being used.  On the othe= r hand, unless the DPI box is upgraded, it will also complain about websock= ets.  So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP w= ould not be.  That scenario is rare, at least at the moment. 

 

[Xin] = ;  With the development of websocket, there will be more and more web = servers which support websocket. That means websocket will be treated the same as HTTP in the policy of FW or proxy server. Comparing with trans= porting the TCP packet directly on the Http port, Upgrade the HTTP to webso= cket and transport the data over it is more friendly to FW and proxy server= . The possibility of the block of  the websocket data by the DPI is less than the TCP data.  So I = think the benefit of turn over websocket is that it will increase the succe= ss rate when the rtcweb is used in the restrictive network, such as in airp= ort or some hotel.

 = ;

The argument for TURN over Websocket/TLS = is even more difficult to make. While DPI boxes may examine traffic destine= d to port 443 carefully to make sure that TLS is really being used,  assuming that the DPI box does not see anything it considers f= ishy, the TLS exchange will complete and the DPI box will lose visibility. =  After TLS is running, the DPI box does not have much information avai= lable to distinguish TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as = packet size) are as likely to result in an objection to websocket transport= as TURN/TLS.  So I'm not sure that draft-chenxin will help in that si= tuation either. 

[Xin] = ; If DPI can’t inspect the content of TLS data, there is no differenc= e. But considering DPI-SSL, which could inspect the TLS session, the turn over websocket will be has the benefit which has been said before.

 = ;

--_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_-- From hangzhou.chenxin@huawei.com Thu May 16 04:52:26 2013 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 AF13B21F907E; Thu, 16 May 2013 04:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlyTRzUIQw7f; Thu, 16 May 2013 04:52:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED44D21F8E96; Thu, 16 May 2013 04:52:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASV96520; Thu, 16 May 2013 11:52:21 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 12:51:46 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 19:52:20 +0800 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Thu, 16 May 2013 19:52:18 +0800 From: "Chenxin (Xin)" To: "Hutton, Andrew" , Bernard Aboba , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUYdZvexTilrlAE6hVSVk7wP2WJkF96iAgAD9vYCAAL7ywA== Date: Thu, 16 May 2013 11:52:17 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DDA95@szxeml538-mbs.china.huawei.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:52:26 -0000 >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Thursday, May 16, 2013 4:28 PM >To: Bernard Aboba; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org >Subject: RE: [rtcweb] FW: New Version Notification for >draft-chenxin-behave-turn-websocket-00.txt > >I agree with Bernard's comments regarding the impact of DPI but of course = such >DPI devices do what they do and we can't and even don't want to stop them >from doing it. However for the case when policy is such that the firewall = will only >allow traffic to traverse that comes from the HTTP Proxy or a network spec= ific >TURN server and there is no deliberate policy to block WebRTC media we nee= d a >solution and this is what draft-hutton-rtcweb-nat-firewall-considerations-= 00 >addresses. > Yes, we could not stop the use of DPI, but we should consider this scene. I= think that is the purpose of F37. Besides, websocket is friendly to http p= roxy too. I agree that draft-hutton-rtcweb-nat-firewall-considerations-00 s= hould be a baseline to solve the traverse problem of nat and fireward. But = I think the turn over websocket solution should also be considered as a opt= ion to solve some corner use case and requirement. Best Regards, Xin=20 >So far I don't see the benefit that TURN over websockets would have in thi= s >scenario and it needs additional implementation in the browser and the TUR= N >server. > >Regards >Andy > > >> -----Original Message----- >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >> Sent: 15 May 2013 18:20 >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org >> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >> >> Andrew Hutton said: >> > When we wrote the draft http://tools.ietf.org/html/draft-hutton- >> rtcweb-nat-firewall-considerations-00 we did not include this option >> because we did not see the benefit of additional transport options for >> TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) seem >> to be meet our needs. >> > >> > So what would be the benefits that justify this addition transport >> option for TURN? >> >> [BA] In my experience, =A0institutions with very restrictive security >> policies (e.g. those that don't allow UDP in or out) also tend to >> deploy other measures such as deep packet inspection. =A0 So just becaus= e >> some traffic is allowed in or out on port 80 does not mean that >> TURN/TCP will be allowed on that port - a DPI box may examine the >> traffic and complain if it doesn't see HTTP being used. =A0On the other >> hand, unless the DPI box is upgraded, it will also complain about >> websockets. =A0So I think draft-chenxin only helps in a situation where >> TURN over Websockets would be allowed when TURN/TCP would not >be. =A0That >> scenario is rare, at least at the moment. >> >> The argument for TURN over Websocket/TLS is even more difficult to >> make. While DPI boxes may examine traffic destined to port 443 >> carefully to make sure that TLS is really being used, =A0assuming that >> the DPI box does not see anything it considers fishy, the TLS exchange >> will complete and the DPI box will lose visibility. =A0After TLS is >> running, the DPI box does not have much information available to >> distinguish TURN/TLS from HTTP over TLS, with or without websockets -- >> and those things it does have (such as packet size) are as likely to >> result in an objection to websocket transport as TURN/TLS. =A0So I'm not >> sure that draft-chenxin will help in that situation either. > > > From adam@nostrum.com Thu May 16 10:39:58 2013 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 1DF3611E810E for ; Thu, 16 May 2013 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sWKHrJY9Vtt for ; Thu, 16 May 2013 10:39:57 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC3F11E8100 for ; Thu, 16 May 2013 10:39:57 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4GHddN7072509 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 12:39:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <519519DB.6050702@nostrum.com> Date: Thu, 16 May 2013 12:39:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> In-Reply-To: <518F83E5.4060209@alvestrand.no> Content-Type: multipart/alternative; boundary="------------080700050004040507070008" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:39:58 -0000 This is a multi-part message in MIME format. --------------080700050004040507070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/12/13 06:58, Harald Alvestrand wrote: > So you're saying that when using 1-31 streams, we use a single port > pair, but when we use 32 streams, we use 32 port pairs? Harald: Your insistence of using "32" rather than "96" is somewhat reminiscent of the statements made Muhammad Saeed al-Sahhaf (the Iraqi Information Minister at the end of Saddam Hussein's tenure). During the 2003 invasion of Iraq, he made several proclamations that were so factually incorrect, so out of touch with reality, and so easy to disprove, that they became an hilarious Internet meme. His antics earned him the nickname "Comical Ali" in the popular press. I've tried correcting you on this point, even going so far as to cite document, section, and paragraph; it doesn't seem to have made any difference. I would strongly encourage you to stick to documented reality in this discussion rather than stating facts from an alternate universe that would, if true, bolster your position. Otherwise, you risk becoming the same kind of laughingstock that Comical Ali did. /a --------------080700050004040507070008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/12/13 06:58, Harald Alvestrand wrote:
So you're saying that when using 1-31 streams, we use a single port pair, but when we use 32 streams, we use 32 port pairs?

Harald:

Your insistence of using "32" rather than "96" is somewhat reminiscent of the statements made Muhammad Saeed al-Sahhaf (the Iraqi Information Minister at the end of Saddam Hussein's tenure). During the 2003 invasion of Iraq, he made several proclamations that were so factually incorrect, so out of touch with reality, and so easy to disprove, that they became an hilarious Internet meme. His antics earned him the nickname "Comical Ali" in the popular press.

I've tried correcting you on this point, even going so far as to cite document, section, and paragraph; it doesn't seem to have made any difference.

I would strongly encourage you to stick to documented reality in this discussion rather than stating facts from an alternate universe that would, if true, bolster your position. Otherwise, you risk becoming the same kind of laughingstock that Comical Ali did.

/a


--------------080700050004040507070008-- From emcho@sip-communicator.org Thu May 16 10:44:40 2013 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 B550411E8144 for ; Thu, 16 May 2013 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKmrHQ7PKNBX for ; Thu, 16 May 2013 10:44:31 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id B112711E8139 for ; Thu, 16 May 2013 10:44:26 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hv10so3014509vcb.34 for ; Thu, 16 May 2013 10:44:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Ke26gLsM1clxSGRBmJLf6PsL+wmY0m7KLpfJ3XKRR5w=; b=FdGpwkUue8PG3NpzEn+olqWg8m3tkE5rWH2mWm5FNlYYHa8oxvpadqwQ2hU8QubNLR ZOJWDjAh3lShUTMWr5QisMNLxTGgD4lfX2Ptn+XBe0YjotWq3isy94ucBPl7W97y4Pnj GEo7j2F5A6t3GqhkdN4TMg9XwBL9lzXxNQdLKoHrh2fPWK4uuK5L7RGrI7DGP2MXE4ED Kmx8ZE7jmtzAq4jH7Na7bldb9tjbJ/8qHiCW/Ir/uuXAFq7KrtDsnudpQZ6VC2dgXlAq xjrbUP4itCU5SnMtXitUzn18brUnWW5ZLOjKUTW0z6DVmz9gLkgfo2uUo3P7dPQD7y8n XxcA== X-Received: by 10.58.106.77 with SMTP id gs13mr7885576veb.22.1368726259539; Thu, 16 May 2013 10:44:19 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx.google.com with ESMTPSA id u20sm7355712vdt.10.2013.05.16.10.44.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 10:44:19 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hz10so445197vcb.10 for ; Thu, 16 May 2013 10:44:18 -0700 (PDT) X-Received: by 10.220.168.202 with SMTP id v10mr28169402vcy.71.1368726258683; Thu, 16 May 2013 10:44:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.167.197 with HTTP; Thu, 16 May 2013 10:43:58 -0700 (PDT) In-Reply-To: <519519DB.6050702@nostrum.com> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> From: Emil Ivov Date: Thu, 16 May 2013 20:43:58 +0300 Message-ID: To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmORsHU2hDUiji9Aj4MnvZDw5O+XptQJW2B1kJRetAK0ExmUv/12RGK2NZhjhIIaFv7N4Hl Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 17:44:40 -0000 On Thu, May 16, 2013 at 8:39 PM, Adam Roach wrote: > > Your insistence of using "32" rather than "96" is somewhat reminiscent 96? Do you assume no use of rtcp-mux? Emil From emil@sip-communicator.org Thu May 16 11:17:00 2013 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 57AF211E8126 for ; Thu, 16 May 2013 11:17:00 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsoxiUBz5ybW for ; Thu, 16 May 2013 11:16:59 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D689911E8105 for ; Thu, 16 May 2013 11:16:55 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg9so1881630bkc.34 for ; Thu, 16 May 2013 11:16:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=o++S5BrPnG2Eo13BzblkN5HB6gzgWVQzYGlMXre2yl8=; b=MAciKxQtafp53v2jwYDsREguhMhC4kKOjjew5KEOQ++NrQXoUi1WnQ78Lsmgsv1f7K Xc3JhAiy7l3cn8v7RBrPlRyfLragsqFuWQsQSCT0lLoY1KLRlltKvRds5hiD7vzKgDQA iRAqwYqJZFIAO4x/9NrVMkhymZCmX05Gf39H7dZtW1h0bogZRDGrlvagwRs+XJVkwGN/ G29YNf2tqLaM8px43H0RW6qIJFEtj09XaLABKWFyDZ33XyuUJ8id9MiQGS5eSGlvEkIZ tRPlzJi4MndoEzDjiwVHkIporZPG/W/tZjTc690fKrVBc8mlzel1DfL5ShWQiTqWasd4 gbug== X-Received: by 10.204.113.78 with SMTP id z14mr14021465bkp.44.1368728214532; Thu, 16 May 2013 11:16:54 -0700 (PDT) Received: from camionet.local ([79.100.215.70]) by mx.google.com with ESMTPSA id i15sm2352426bkz.12.2013.05.16.11.16.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 11:16:53 -0700 (PDT) Message-ID: <51952294.9080603@jitsi.org> Date: Thu, 16 May 2013 21:16:52 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnmQxM/xJQl3vpJlMI+5vfiUF2BL3JXPdzeHPPPPitraGdSAjMcgULdQ2d94PKrIfb2HVZE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:17:00 -0000 On 16.05.13, 20:43, Emil Ivov wrote: > On Thu, May 16, 2013 at 8:39 PM, Adam Roach wrote: >> >> Your insistence of using "32" rather than "96" is somewhat reminiscent > > 96? Do you assume no use of rtcp-mux? I suppose you must be referring to [5761#4]: Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by be used first. While this works on paper, most media libraries are likely to have many of those statically bound to the formats from 3551. This would bring us down to 61. Even then going below 96 is still likely to be problematic for many such libraries. This actually reminds me how recently (I believe it was in Boston) someone advised that in trickle ICE, even though 3264 allowed it, we shouldn't be using 0.0.0.0 in descriptions with no candidates. This was because (from the notes) "otherwise, you have to add special purpose code to existing SDP libraries". Emil -- https://jitsi.org From harald@alvestrand.no Thu May 16 11:27:00 2013 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 23AF911E814E for ; Thu, 16 May 2013 11:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjj5JXEZ88tE for ; Thu, 16 May 2013 11:26:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9711E8135 for ; Thu, 16 May 2013 11:26:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 263A239E1A6; Thu, 16 May 2013 20:26:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcixxpqMZQPk; Thu, 16 May 2013 20:26:51 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:d594:249c:4a90:3766] (unknown [IPv6:2001:470:de0a:27:d594:249c:4a90:3766]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4534639E170; Thu, 16 May 2013 20:26:51 +0200 (CEST) Message-ID: <519524EA.3000509@alvestrand.no> Date: Thu, 16 May 2013 20:26:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Roach References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> In-Reply-To: <519519DB.6050702@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:27:00 -0000 Adam, this is the first time I've been compared to the Iraqi Information Minister... another achievement unlocked! There are just 2 issues with your correction: 1) I don't believe your comment (or the RFCs you cite) reflect currently deployed reality. I've seen the lines of code - they allocate from 32 dynamic types, not 192. So the solution you propose is going to be incompatible with deployed code bases. 2) If the true limit at which one has to change allocation strategy were to become 96, not 32, it actually strengthens my "falling off a cliff" argument (unless you don't believe in applications with more than 96 streams): This won't be a problem except in rare cases - ensuring even more code will be deployed that works until stressed. I also have a confession to make: On some days, I respond to mail addressed to me without checking that I'm caught up on the mailing list that the conversation is copied to. In this case, I responded to the mail sent directly to me on May 12 (a Sunday) without checking that I had also read your posting to the list on May 8 (Wednesday on the week before). I suppose that's enough of a lapse in courtesy to be deserving of some censure. Harald From adam@nostrum.com Thu May 16 11:41:53 2013 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 3B68B21F8E46 for ; Thu, 16 May 2013 11:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRw7g7+GOWVp for ; Thu, 16 May 2013 11:41:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1CD21F8D92 for ; Thu, 16 May 2013 11:41:52 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4GIfaC8079334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 13:41:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51952860.5030906@nostrum.com> Date: Thu, 16 May 2013 13:41:36 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> In-Reply-To: <519524EA.3000509@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 18:41:53 -0000 On 5/16/13 13:26, Harald Alvestrand wrote: > I don't believe your comment (or the RFCs you cite) reflect currently > deployed reality. I'm not sure how much design we need to do to accommodate out-of-spec implementations. I would be interested in knowing how pervasive this behavior actually is in deployments, since the proper handling of dynamic PTs has been well documented for nearly a decade. > If the true limit at which one has to change allocation strategy were > to become 96, not 32, it actually strengthens my "falling off a cliff" > argument And, to be clear, it's not a cliff. For any given session (without a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you go from using one port to using 97 ports when you add the 97th stream. You go from one port to two, which will handle 192 streams. And that's okay. As you approach 100 streams, I seriously doubt that port utilization is going to be the constraining factor in what your network can support. /a From harald@alvestrand.no Thu May 16 12:15:31 2013 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 0513121F92B2 for ; Thu, 16 May 2013 12:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpURrncm8eg7 for ; Thu, 16 May 2013 12:15:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CF04621F91D8 for ; Thu, 16 May 2013 12:15:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF9E639E1A6; Thu, 16 May 2013 21:15:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58nRTXfEdDgP; Thu, 16 May 2013 21:15:24 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:d594:249c:4a90:3766] (unknown [IPv6:2001:470:de0a:27:d594:249c:4a90:3766]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 14BC039E170; Thu, 16 May 2013 21:15:24 +0200 (CEST) Message-ID: <5195304B.10706@alvestrand.no> Date: Thu, 16 May 2013 21:15:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Roach References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> In-Reply-To: <51952860.5030906@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:15:31 -0000 On 05/16/2013 08:41 PM, Adam Roach wrote: > On 5/16/13 13:26, Harald Alvestrand wrote: > >> I don't believe your comment (or the RFCs you cite) reflect currently >> deployed reality. > > I'm not sure how much design we need to do to accommodate out-of-spec > implementations. I would be interested in knowing how pervasive this > behavior actually is in deployments, since the proper handling of > dynamic PTs has been well documented for nearly a decade. Since an argument that has been made in favour of Plan A is that it is (supposedly) more compatible with deployed code, this interests me greatly. Has dynamic allocation of sub-96 payload numbers ever been tested at a SIPit, for instance? > >> If the true limit at which one has to change allocation strategy were >> to become 96, not 32, it actually strengthens my "falling off a >> cliff" argument > > And, to be clear, it's not a cliff. For any given session (without > a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not > like you go from using one port to using 97 ports when you add the > 97th stream. You go from one port to two, which will handle 192 streams. Going from one port to two ports is a cliff. We may have differing opinions on how tall it is. > > And that's okay. As you approach 100 streams, I seriously doubt that > port utilization is going to be the constraining factor in what your > network can support. > > /a From emil@sip-communicator.org Thu May 16 12:22:49 2013 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 A69B121F8F87 for ; Thu, 16 May 2013 12:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMZOCcIIlVj7 for ; Thu, 16 May 2013 12:22:39 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3905E21F8E84 for ; Thu, 16 May 2013 12:22:37 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji2so1959505bkc.10 for ; Thu, 16 May 2013 12:22:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ktwVXOhbOznufnEgR1znA7SmGquJhXZLJjOqVjv017Q=; b=Jq+bP38QcExgNDR8dh2+ejimY+zFoi2YXPoiQDf0RxvvYDe1F7W3FMKTz80vG06g6K aRB8mb0FIQ6zL29QbktyYChlBlB8rhnJ3IrHAGVVF1kVK/lwp+gqha7Dwl7unmdqbSUO oaBOFxXuaIaPCONCNoIJtYRG2MslPf80gfLpRVFljP/OqnWQoWp/ifor+Z/JRX2FghIc RC7+6ZvkdFgSf1B2/fIPnBbsxFAHIMgRY/EWH2qm6GGPSyVxQrlfvQFBcBmr9vT6xNCc 6rEUqFPw2yjrZs2eKgqnYlpdIpEZgjblKy6L2q7Tnzjkdy0yMJEFmQz7p9ifBKZ7T4m0 BJoQ== X-Received: by 10.204.200.71 with SMTP id ev7mr2988669bkb.27.1368732151195; Thu, 16 May 2013 12:22:31 -0700 (PDT) Received: from camionet.local ([79.100.215.70]) by mx.google.com with ESMTPSA id x5sm2410683bkh.15.2013.05.16.12.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 12:22:30 -0700 (PDT) Message-ID: <519531F6.1010201@jitsi.org> Date: Thu, 16 May 2013 22:22:30 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkz595Lcz7hQoOqwhzyR7S+LUpcDpBZg20kK1G6XiUrY0WPYTMpYJsWqYnssgrTV12wM2V3 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 19:22:50 -0000 On 16.05.13, 12:45, Stefan H=E5kansson LK wrote: > On 5/14/13 9:46 PM, Emil Ivov wrote: >> Hey Stefan, >> >> On 14.05.13, 14:44, Stefan H=E5kansson LK wrote: >>>>> SSRCs - this would be SDP >>>> >>>> Again, including SSRCs in SDP O/A is tricky in conferencing scenario= s. >>> >>> Here seems to be something that I have missed. That there are existin= g >>> implementations that do not signal SSRC is fine, and in most cases th= ere >>> would be only one audio and one video SSRC used anyway. And rtcweb (a= nd >>> Clue?) should be able to interoperate (but perhaps your web app need = to >>> be designed in a specific way). >>> >>> But if we design something forward looking, that can handle many >>> streams, that can handle layered codecs and FEC data, signaling SSRCs= >>> seems like a must to me. >>> >>> But I have missed that this is problematic in conferencing scenarios,= >>> could you tell me why (and I probably should know :) )? >> >> The issue that I am referring to (I describe this in an earlier mail t= o >> Harald here http://goo.gl/M8NbQ ) is that of a conference based on an >> RTP translator. It's basically what we do in Jitsi Videobridge. >> >> Let's say that I am a WebRTC app that can act as a conference focus an= d >> that has access to an RTP translator somewhere. I'd like to organise a= >> conference with 10 people (you and I among them). >> >> I ask the RTP translator to allocate 10 ports for me and then I start >> calling participants. >> >> You are the first one that I am going to join into this new call. >> >> At this point, the only SSRC(s) that I could possibly give you are tho= se >> that I am going to use. I won't be able to tell you anything for the >> eight other participants. For all I know, some or all of these >> participants could turn out to be RTP translators themselves and there= >> could be a number of SSRCs behind each of them too. >> >> The very logical and easy thing that your webapp could do here is not = to >> care and simply render each and every SSRC that you get. Most apps are= >> going to be perfectly happy with that. >> >> If, on the other hand you needed me to re-offer you every time a new >> participant joins in order to work properly, then things would easily >> get quite messy even if everyone is using WebRTC. >> >> Then, note that some of the participants can be simple SIP endpoints >> (that's why we bothered with SDP in the first place right?) so the onl= y >> way I can get their SSRCs is with some extra signalling between me and= >> the RTP translator. This is not a problem per se, but it can only happ= en >> after the SIP participants have joined the call and started streaming >> data, that has reached the translator. And even then they will have no= >> MSIDs. >> >> All in all, we would be enforcing some very laborious signalling when >> it is absolutely unnecessary. >=20 > Thanks, I then understand the use-case you're envisioning. >=20 > I think it could work under certain conditions, but as soon as there ar= e=20 > repair flows, enhancement layers or simulcast involved, there is a need= =20 > anyway to somehow signal what each SSRC represents. I don't think anyone is arguing against this. > Then it is another=20 > question if it happens via SDP or via RTP header extensions or some=20 > other means. >=20 > There was a discussion at the Stockholm rtcweb interim on what=20 > topologies that would be supported, but I fail to remember if this case= =20 > was included or excluded. I couldn't find the discussion (in what WG did it happen?) but topologies based on RTP translators of one sort or another seem to be the default way of handling video conferencing these days so I don't see how we could possibly rule them out. > It also seems to me that people have quite different views in the=20 > discussion. Of course, where would the fun be otherwise? :) > One view seems to be that SDP exchanges should be used even=20 > for things like pause/resume, resolution changes,=20 Right! That's the wrong view ;). We made two important choices in this working group: a) we will not impose a signalling protocol, and b) we will use SDP O/A to make it easier to talk to legacy apps/devices. Let's not try to compensate for the former by hijacking the latter. > another that we should=20 > avoid SDP exchanges even when people join/leave a conference. Even? I'd argue that this is _the_ place where avoiding SDP O/A is most important! Emil --=20 https://jitsi.org From fluffy@iii.ca Thu May 16 13:18:24 2013 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 B841821F8A14 for ; Thu, 16 May 2013 13:18:24 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YySG+l5PtG6i for ; Thu, 16 May 2013 13:18:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 560A421F8935 for ; Thu, 16 May 2013 13:18:20 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A3B81509B5; Thu, 16 May 2013 16:18:18 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Thu, 16 May 2013 14:18:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: [rtcweb] New Doodle for Virtual Interim on SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:18:24 -0000 We are still trying to pick a time to have an Virtual Interim meeting = for the IETF RTCWeb WG on the topic of SDP Security Descriptions (RFC = 4568 aka SDES). The goal is not to make a decision about this but the = goal is to get everyone understanding the pros and cons of all the = options.=20 The proposed length of the meeting is 2.5 hours. Please fill out the doodle at by the end of the day on May 22=20 http://www.doodle.com/22qy6vcpre4vqex6 Thanks, The chairs ... On May 9, 2013, at 9:39 AM, Ted Hardie wrote: > Howdy, >=20 > Given the MMUSIC working group virtual interim is now scheduled for = May 23rd, the RTCWEB chairs plan to push back the SDES-focused virtual = interim we'd previously announced, so that folks can focus on the Plan A = and Plan B discussion to happen there. =20 >=20 > We will put out a new doodle poll early next week with dates in June. = The current plan is that the virtual interim will include discussion of = the base security properties, EKT, and some of the other issues which = have come up in working group discussion. >=20 > regards, >=20 > Ted, Cullen, and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu May 16 13:28:36 2013 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 13C0711E8111 for ; Thu, 16 May 2013 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8y23B9EJTmw for ; Thu, 16 May 2013 13:28:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 102C511E8104 for ; Thu, 16 May 2013 13:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2FF639E1A6 for ; Thu, 16 May 2013 22:28:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXCS30PaRDXL for ; Thu, 16 May 2013 22:28:19 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:d594:249c:4a90:3766] (unknown [IPv6:2001:470:de0a:27:d594:249c:4a90:3766]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E3BD939E170 for ; Thu, 16 May 2013 22:28:18 +0200 (CEST) Message-ID: <51954162.70909@alvestrand.no> Date: Thu, 16 May 2013 22:28:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> In-Reply-To: <519531F6.1010201@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Common ways of handling video conferences? (Re: Why requiring pre-announcement) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:28:36 -0000 On 05/16/2013 09:22 PM, Emil Ivov wrote: >> Then it is another >> >question if it happens via SDP or via RTP header extensions or some >> >other means. >> > >> >There was a discussion at the Stockholm rtcweb interim on what >> >topologies that would be supported, but I fail to remember if this case >> >was included or excluded. > I couldn't find the discussion (in what WG did it happen?) but > topologies based on RTP translators of one sort or another seem to be > the default way of handling video conferencing these days so I don't see > how we could possibly rule them out. > This is an interesting statement. I've also heard the claim that "RTP translators hardly exist outside the lab" - I think that quip was referring to RFC 5117 section 3.3 Topo-Trn-Translators, the story may be different for Topo-Media-Translators - but I thought the most common form was the section 3.4 Topo-Mixer? Do we have numbers or names attached to this? I'm afraid all I can contribute real data on is Google+ hangouts, which is a section 3.6 Topo-RTCP-terminating-MCU. From ekr@rtfm.com Thu May 16 16:29:08 2013 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 1D68421F8F41 for ; Thu, 16 May 2013 16:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VltPjdjKCy3B for ; Thu, 16 May 2013 16:29:02 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3621F8470 for ; Thu, 16 May 2013 16:29:02 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id 1so2316242qec.11 for ; Thu, 16 May 2013 16:29:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=4wZY6t2v+9T1KbUnR0toY3Dza4xLDBBMe2afxB6BLz8=; b=C/WmmCkukLRItZe0cXNkITb5uisF+y7Wm2rpVZALeg7mHNUT5dOgiYQxRRby2x/3rP 2uuS26IWtfm9YVpnFQUK0IcRrnDUKHC/P4uOz+tNgYEL7Ngqyw46fbYmXhiMOrGYKZIf CZHexfGORlEskumx9KGE6mVfjnj4MaCj68zuECri+WYe8hy7mhirIIkQj1TWANksqHWO GRJ+llXK9w5VSh6/ybl3+y7yv79Cf0olz410Nx0QK+wwbRSYqD43Yo9iqHdq+3++pkxF ZvsSBD6KsLrx2yjapDt6wEXgZVxGhZVgDW4PO3JYjGUtW5/rSeyivoYjwXrGNYje+v9x aqIA== X-Received: by 10.49.75.134 with SMTP id c6mr8105902qew.47.1368746941464; Thu, 16 May 2013 16:29:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.85.130 with HTTP; Thu, 16 May 2013 16:28:20 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <5195304B.10706@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> From: Eric Rescorla Date: Thu, 16 May 2013 16:28:20 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bdc8d903bfa2204dcde3bb3 X-Gm-Message-State: ALoCoQmoOqFlDqfX3RAivaHNFTbIxsOQY/FF2bBo/iCNch7Dz30WsdqnCA8Yj6F6bE5ceaItGfVM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 23:29:08 -0000 --047d7bdc8d903bfa2204dcde3bb3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand wrote: > > If the true limit at which one has to change allocation strategy were to >>> become 96, not 32, it actually strengthens my "falling off a cliff" argument >>> >> >> And, to be clear, it's not a cliff. For any given session (without >> a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you >> go from using one port to using 97 ports when you add the 97th stream. You >> go from one port to two, which will handle 192 streams. >> > > Going from one port to two ports is a cliff. > We may have differing opinions on how tall it is. Harald, I am not following how this is a discriminating factor between Plan A and Plan B. In both Plan A and Plan B, any media stream which is intended to be independently processable by a legacy endpoint must appear on its own m-line. That means it must also have its own independent ports, even if you are hoping to eventually be able to mux it via BUNDLE. In both Plan A and Plan B, it is possible to indicate additional media streams that are not processable by a legacy endpoint but that will be processable by a new endpoint: - In Plan A, this is done by marking them bundle-only - In Plan B, this is done by having them be additional SSRCs on one of the extant m-lines. Regardless of Plan A versus Plan B, bundle contemplates having multiple media flows on the same media 5-tuple. Thus, it must be possible to demux the flows somehow. As I read Plan A, it proposes using both PT and SSRC to demux whereas plan B only wants to use SSRC? So, the implication is that a Plan A endpoint must: 1. Demux on both PT and SSRC (this is trivial, I think you will agree) 2. When acting as offerer, either always offer SSRC or conditionally offer SSRC when the # of PTs is excessive. I don't understand why you think that plan A means more ports than plan B. Presumably we can simply specify that bundle requires SSRC muxing, in which case plan A and plan B behave identically. What am I missing? -Ekr --047d7bdc8d903bfa2204dcde3bb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 16, 2013 at 12:15 PM, Harald= Alvestrand <harald@alvestrand.no> wrote:
If the true limit at which one has to change allocation strategy were to be= come 96, not 32, it actually strengthens my "falling off a cliff"= argument

And, to be clear, it's not a cliff. For any given session (without a=3D= ssrc:), you have to allocate ceiling(streams/96) ports. It's not like y= ou go from using one port to using 97 ports when you add the 97th stream. Y= ou go from one port to two, which will handle 192 streams.

Going from one port to two ports is a cliff.
We may have differing opinions on how tall it is.

Harald,

I am not following how this is a di= scriminating factor between Plan A and
Plan B.

In both Plan A and Plan B, any media stream which is intended to= be
independently processable by a legacy endpoint must appear on= its
own m-line. That means it must also have its own independent= ports,
even if you are hoping to eventually be able to mux it via BUNDLE.

In both Plan A and Plan B, it is possible to indicate= additional media
streams that are not processable by a legacy en= dpoint but that
will be processable by a new endpoint:

- In P= lan A, this is done by marking them bundle-only
- In Plan B, this= is done by having them be additional SSRCs on one
=A0 of the ext= ant m-lines.



Regardless of Plan A vers= us Plan B, bundle contemplates having
multiple media flows on the= same media 5-tuple. Thus, it must
be possible to demux the flows= somehow. As I read Plan A,
it proposes using both PT and SSRC to demux whereas plan B
o= nly wants to use SSRC? So, the implication is that a Plan A
endpo= int must:

1. Demux on both PT and SSRC (this is tr= ivial, I think you will agree)
2. When acting as offerer, either always offer SSRC or conditionally
offer SSRC when the # of PTs is excessive.

I don't understand why you think that plan A means more ports than
plan B. Presumably we can simply specify that bundle requires
SSRC muxing, in which case plan A and plan B behave identically.

What am I missing?

-Ekr





=


--047d7bdc8d903bfa2204dcde3bb3-- From harald@alvestrand.no Thu May 16 23:32:12 2013 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 C8D1D21F92EC for ; Thu, 16 May 2013 23:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8vK7Uc0mBm7 for ; Thu, 16 May 2013 23:32:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D605A21F9344 for ; Thu, 16 May 2013 23:32:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C66F439E0D7; Fri, 17 May 2013 08:32:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obe1yLgp5zp5; Fri, 17 May 2013 08:32:00 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:d594:249c:4a90:3766] (unknown [IPv6:2001:470:de0a:27:d594:249c:4a90:3766]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 08F8B39E01E; Fri, 17 May 2013 08:31:59 +0200 (CEST) Message-ID: <5195CEDF.9040109@alvestrand.no> Date: Fri, 17 May 2013 08:31:59 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050009050304080104060200" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 06:32:12 -0000 This is a multi-part message in MIME format. --------------050009050304080104060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/17/2013 01:28 AM, Eric Rescorla wrote: > > > On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand > > wrote: > > If the true limit at which one has to change allocation > strategy were to become 96, not 32, it actually > strengthens my "falling off a cliff" argument > > > And, to be clear, it's not a cliff. For any given session > (without a=ssrc:), you have to allocate ceiling(streams/96) > ports. It's not like you go from using one port to using 97 > ports when you add the 97th stream. You go from one port to > two, which will handle 192 streams. > > > Going from one port to two ports is a cliff. > We may have differing opinions on how tall it is. > > > Harald, > > I am not following how this is a discriminating factor between Plan A and > Plan B. > > In both Plan A and Plan B, any media stream which is intended to be > independently processable by a legacy endpoint must appear on its > own m-line. That means it must also have its own independent ports, > even if you are hoping to eventually be able to mux it via BUNDLE. I agree with this characterization - the two proposals have the same number of ports in the initial offer. I quibble about the characterization "any media stream which is intended to be independently processable by a legacy endpoint must appear on its own m-line." As Bernard has said, the field of deployed applications is diverse enough to make this question confusing - both "independently processable" and "legacy endpoint" may need further qualification in order to make that statement unequivocally true. > > In both Plan A and Plan B, it is possible to indicate additional media > streams that are not processable by a legacy endpoint but that > will be processable by a new endpoint: > > - In Plan A, this is done by marking them bundle-only > - In Plan B, this is done by having them be additional SSRCs on one > of the extant m-lines. > > > > Regardless of Plan A versus Plan B, bundle contemplates having > multiple media flows on the same media 5-tuple. Thus, it must > be possible to demux the flows somehow. As I read Plan A, > it proposes using both PT and SSRC to demux whereas plan B > only wants to use SSRC? So, the implication is that a Plan A > endpoint must: > > 1. Demux on both PT and SSRC (this is trivial, I think you will agree) The demuxing is trivial. In fact, I don't think it's even necessary to describe it as "demux on PT"; you can't allow SSRC collision between two tracks with different PT anyway. > 2. When acting as offerer, either always offer SSRC or conditionally > offer SSRC when the # of PTs is excessive. > > I don't understand why you think that plan A means more ports than > plan B. Presumably we can simply specify that bundle requires > SSRC muxing, in which case plan A and plan B behave identically. > > What am I missing? This particular issue is about what happens when you run out of payload types to multiplex on. In Plan A as I currently understand Adam, any application that needs less than 96 M-lines (Adam's number) can use a single port, and use the payload type to indicate the M-line. If there are 97 M-lines, if I've understood Adam correctly, one could use two ports and two bundles, with some subset of the M-lines being allocated to one bundle and another subset of the M-lines allocated to the other bundle. In Plan B, there is no difference in the mechanism used to multiplex 96 SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter for the multiplexing how many M-lines they are distributed over. --------------050009050304080104060200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/17/2013 01:28 AM, Eric Rescorla wrote:


On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
If the true limit at which one has to change allocation strategy were to become 96, not 32, it actually strengthens my "falling off a cliff" argument

And, to be clear, it's not a cliff. For any given session (without a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you go from using one port to using 97 ports when you add the 97th stream. You go from one port to two, which will handle 192 streams.

Going from one port to two ports is a cliff.
We may have differing opinions on how tall it is.

Harald,

I am not following how this is a discriminating factor between Plan A and
Plan B.

In both Plan A and Plan B, any media stream which is intended to be
independently processable by a legacy endpoint must appear on its
own m-line. That means it must also have its own independent ports,
even if you are hoping to eventually be able to mux it via BUNDLE.

I agree with this characterization - the two proposals have the same number of ports in the initial offer.

I quibble about the characterization "any media stream which is intended to be
independently processable by a legacy endpoint must appear on its
own m-line." As Bernard has said, the field of deployed applications is diverse enough to make this question confusing - both "independently processable" and "legacy endpoint" may need further qualification in order to make that statement unequivocally true.


In both Plan A and Plan B, it is possible to indicate additional media
streams that are not processable by a legacy endpoint but that
will be processable by a new endpoint:

- In Plan A, this is done by marking them bundle-only
- In Plan B, this is done by having them be additional SSRCs on one
  of the extant m-lines.



Regardless of Plan A versus Plan B, bundle contemplates having
multiple media flows on the same media 5-tuple. Thus, it must
be possible to demux the flows somehow. As I read Plan A,
it proposes using both PT and SSRC to demux whereas plan B
only wants to use SSRC? So, the implication is that a Plan A
endpoint must:

1. Demux on both PT and SSRC (this is trivial, I think you will agree)

The demuxing is trivial. In fact, I don't think it's even necessary to describe it as "demux on PT"; you can't allow SSRC collision between two tracks with different PT anyway.

2. When acting as offerer, either always offer SSRC or conditionally
offer SSRC when the # of PTs is excessive.

I don't understand why you think that plan A means more ports than
plan B. Presumably we can simply specify that bundle requires
SSRC muxing, in which case plan A and plan B behave identically.

What am I missing?

This particular issue is about what happens when you run out of payload types to multiplex on.

In Plan A as I currently understand Adam, any application that needs less than 96 M-lines (Adam's number) can use a single port, and use the payload type to indicate the M-line.

If there are 97 M-lines, if I've understood Adam correctly, one could use two ports and two bundles, with some subset of the M-lines being allocated to one bundle and another subset of the M-lines allocated to the other bundle.

In Plan B, there is no difference in the mechanism used to multiplex 96 SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter for the multiplexing how many M-lines they are distributed over.


--------------050009050304080104060200-- From emil@sip-communicator.org Fri May 17 01:30:24 2013 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 7E4CE21F924A for ; Fri, 17 May 2013 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl0c5GXS6FXh for ; Fri, 17 May 2013 01:30:22 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 142B421F9298 for ; Fri, 17 May 2013 01:30:17 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg9so2184281bkc.34 for ; Fri, 17 May 2013 01:30:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=lN/U4yrEqI4qw0aKONfjaG8sFMI1g41Q95+5saD/5dQ=; b=MuX0EMjbWby/DJ/pE+QOfa8RdNwta3YVEYx6Nl2ptlLDZHagxXgiIENyavhyzj27w7 A6Z1oi3jmeAy4DXy7iIzg0PmjP/nuts+npTqOJbI4eHAFnt7/+Hp6MO+MQFHMEpOvlJm 0EKW+bjxAxkylpnaRIer+PaKIWkEeUbY5i4i2OG5C6oOXArRnrqJhXhY1D5OsQBWImoF s682fr9eCzr9kMtC/1le/18OvSi6fwM8tMkOC/dFJXYsSAYHfedJ5a3VYockZqi+A3CD 17foV9acz2YUxvpg9OE+kiQE3geM6mePR2d09zLvbC3P3SbM010zPKx9xdBBYkSd/Kjw UPyg== X-Received: by 10.204.57.142 with SMTP id c14mr14994288bkh.7.1368779416890; Fri, 17 May 2013 01:30:16 -0700 (PDT) Received: from camionet.local ([79.100.215.70]) by mx.google.com with ESMTPSA id i15sm2811944bkz.12.2013.05.17.01.30.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 01:30:15 -0700 (PDT) Message-ID: <5195EA95.3030007@jitsi.org> Date: Fri, 17 May 2013 11:30:13 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Harald Alvestrand References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> <51954162.70909@alvestrand.no> In-Reply-To: <51954162.70909@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmezHN4glrhIsMymYhj/nRUH3HXMiixgW6v07ss057K4U4VIFKkf5CtqjfXUeSjFsH/INSw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Common ways of handling video conferences? (Re: Why requiring pre-announcement) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 08:30:24 -0000 On 16.05.13, 23:28, Harald Alvestrand wrote: > On 05/16/2013 09:22 PM, Emil Ivov wrote: >>> Then it is another >>>> question if it happens via SDP or via RTP header extensions or some >>>> other means. >>>> >>>> There was a discussion at the Stockholm rtcweb interim on what >>>> topologies that would be supported, but I fail to remember if this case >>>> was included or excluded. >> I couldn't find the discussion (in what WG did it happen?) but >> topologies based on RTP translators of one sort or another seem to be >> the default way of handling video conferencing these days so I don't see >> how we could possibly rule them out. >> > > This is an interesting statement. I've also heard the claim that "RTP > translators hardly exist outside the lab" - I think that quip was > referring to RFC 5117 section 3.3 Topo-Trn-Translators, the story may be > different for Topo-Media-Translators - but I thought the most common > form was the section 3.4 Topo-Mixer? Until recently, yes certainly, mixers were prevalent (which is arguably part of the reason why very few people had access to video conferencing). I think we'd all agree that this doesn't seem to be the case any longer and that for various reasons (including cost, quality and flexibility), most of the conferencing solutions today prefer shifting packets rather than mixing content. My statement above was made in that sense and not in the sense of "Topo-Trn-Translators" beat all the other topos described in 5117. > Do we have numbers or names attached to this? > > I'm afraid all I can contribute real data on is Google+ hangouts, which > is a section 3.6 Topo-RTCP-terminating-MCU. I can't know much about Google+ hangouts but I am quite convinced that the problems I described earlier in this thread fully apply there. (They certainly do for 3.6 Topo-RTCP-terminating-MCU) The reason you are not experiencing them has much more to do with the fact that hangouts run in a controlled environment where all clients and use cases are rather well known. The right assumptions can therefore be made about use of repair flows, simulcasting, presence or absence of cascaded translators (or MCUs if you prefer) and so on. Cheers, Emil -- https://jitsi.org From kevindempsey70@gmail.com Fri May 17 03:55:26 2013 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 AB3BB21F930C for ; Fri, 17 May 2013 03:55:26 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhR6ZXrotT05 for ; Fri, 17 May 2013 03:55:25 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5D21F8756 for ; Fri, 17 May 2013 03:55:24 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fg20so1846384lab.1 for ; Fri, 17 May 2013 03:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Rdkzg43IOI8Dn8amCL+e6fIatXYHSXwmvfO4o8fFBrc=; b=1CB0D1+GfZ/OD/DGLNIFovE4iqIWVKdSD87DMDfcUgU/12nMicAMrgXxvxR6St3FhE PoXI5bGuzaQJ6xRkSu0nLwi0zpB2NlLq8Yr603Ue++rnL6cYYhRuqR4W2Le3OwNPGmvp zIdCqngB/+kUsHfIQF4TXDlbRFidOjFo+cD0BRmVC/L+dupKftmnL5p4qfStuWNBxuD5 QUSVRAQixO29HpYv6kaWqtq5nTcs25cq3Pq4BForx1R+ow71WJeo1Eg/xHw/41a5v7s1 GYppuDXqJJ3CIgl+td4JswMpg7WQOSVi/jCDTCfiPpmdUFY9WJDBUaNRsnrwsFR2zjwo vojg== MIME-Version: 1.0 X-Received: by 10.112.235.104 with SMTP id ul8mr1148226lbc.5.1368788123585; Fri, 17 May 2013 03:55:23 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Fri, 17 May 2013 03:55:23 -0700 (PDT) In-Reply-To: <5195CEDF.9040109@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> Date: Fri, 17 May 2013 11:55:23 +0100 Message-ID: From: Kevin Dempsey To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c3c96ee1103204dce7d114 X-Mailman-Approved-At: Fri, 17 May 2013 04:22:52 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 10:55:26 -0000 --001a11c3c96ee1103204dce7d114 Content-Type: text/plain; charset=ISO-8859-1 I think part of the problem is that the receiver doesn't know which media flow a given SSRC belongs to until it is told about it by the sender. The PT, on the other hand, is chosen by the receiver and so if that is unique across all media flows it could be used to determine which media flow a packet belongs to. As others have said, signalling SSRCs is problematic as sometimes the SSRCs are not known or can change. It also may cause clipping in cases where media can arrive before the answer. If RTP packets included an identifier chosen by the receiver (e.g. in a RTP extension header) then we would not need to rely on SSRC signalling. On 17 May 2013 07:31, Harald Alvestrand wrote: > On 05/17/2013 01:28 AM, Eric Rescorla wrote: > > > > On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand wrote: >> >> If the true limit at which one has to change allocation strategy were >>>> to become 96, not 32, it actually strengthens my "falling off a cliff" >>>> argument >>>> >>> >>> And, to be clear, it's not a cliff. For any given session (without >>> a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you >>> go from using one port to using 97 ports when you add the 97th stream. You >>> go from one port to two, which will handle 192 streams. >>> >> >> Going from one port to two ports is a cliff. >> We may have differing opinions on how tall it is. > > > Harald, > > I am not following how this is a discriminating factor between Plan A and > Plan B. > > In both Plan A and Plan B, any media stream which is intended to be > independently processable by a legacy endpoint must appear on its > own m-line. That means it must also have its own independent ports, > even if you are hoping to eventually be able to mux it via BUNDLE. > > > I agree with this characterization - the two proposals have the same > number of ports in the initial offer. > > I quibble about the characterization "any media stream which is intended > to be > independently processable by a legacy endpoint must appear on its > own m-line." As Bernard has said, the field of deployed applications is > diverse enough to make this question confusing - both "independently > processable" and "legacy endpoint" may need further qualification in order > to make that statement unequivocally true. > > > > In both Plan A and Plan B, it is possible to indicate additional media > streams that are not processable by a legacy endpoint but that > will be processable by a new endpoint: > > - In Plan A, this is done by marking them bundle-only > - In Plan B, this is done by having them be additional SSRCs on one > of the extant m-lines. > > > > Regardless of Plan A versus Plan B, bundle contemplates having > multiple media flows on the same media 5-tuple. Thus, it must > be possible to demux the flows somehow. As I read Plan A, > it proposes using both PT and SSRC to demux whereas plan B > only wants to use SSRC? So, the implication is that a Plan A > endpoint must: > > 1. Demux on both PT and SSRC (this is trivial, I think you will agree) > > > The demuxing is trivial. In fact, I don't think it's even necessary to > describe it as "demux on PT"; you can't allow SSRC collision between two > tracks with different PT anyway. > > > 2. When acting as offerer, either always offer SSRC or conditionally > offer SSRC when the # of PTs is excessive. > > I don't understand why you think that plan A means more ports than > plan B. Presumably we can simply specify that bundle requires > SSRC muxing, in which case plan A and plan B behave identically. > > What am I missing? > > > This particular issue is about what happens when you run out of payload > types to multiplex on. > > In Plan A as I currently understand Adam, any application that needs less > than 96 M-lines (Adam's number) can use a single port, and use the payload > type to indicate the M-line. > > If there are 97 M-lines, if I've understood Adam correctly, one could use > two ports and two bundles, with some subset of the M-lines being allocated > to one bundle and another subset of the M-lines allocated to the other > bundle. > > In Plan B, there is no difference in the mechanism used to multiplex 96 > SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter > for the multiplexing how many M-lines they are distributed over. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3c96ee1103204dce7d114 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think part of the problem is that the receiver doesn'= ;t know which media flow a given SSRC belongs to until it is told about it = by the sender. The PT, on the other hand, is chosen by the receiver and so = if that is unique across all media flows it could be used to determine whic= h media flow a packet belongs to.

As others have said, signalling SSRCs is problematic a= s sometimes the SSRCs are not known or can change. It also may cause clippi= ng in cases where media can arrive before the answer.

If RTP packets included an identifier chosen by the receiv= er (e.g. in a RTP extension header) then we would not need to rely on SSRC = signalling.


On 17 May 2013 07:31, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 05/17/2013 01:28 AM, Eric Rescorla wrote:


On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
If the true limit at which one has to change allocation strategy were to become 96, not 32, it actually strengthens my "falling off a cliff" argument

And, to be clear, it's not a cliff. For any given session (without a=3Dssrc:), you have to allocate ceiling(streams/96) ports. It's not like you go from usin= g one port to using 97 ports when you add the 97th stream. You go from one port to two, which will handle 192 streams.

Going from one port to two ports is a cliff.
We may have differing opinions on how tall it is.

Harald,

I am not following how this is a discriminating factor between Plan A and
Plan B.

In both Plan A and Plan B, any media stream which is intended to be
independently processable by a legacy endpoint must appear on its
own m-line. That means it must also have its own independent ports,
even if you are hoping to eventually be able to mux it via BUNDLE.

I agree with this characterization - the two proposals have the same number of ports in the initial offer.

I quibble about the characterization "any media stream which is intended to be
independently processable by a legacy endpoint m= ust appear on its
own m-line." As Bernard has said, the field of deployed applicatio= ns is diverse enough to make this question confusing - both "independently processable" and "legacy endpoint" m= ay need further qualification in order to make that statement unequivocally true.



In both Plan A and Plan B, it is possible to indicate additional media
streams that are not processable by a legacy endpoint but that
will be processable by a new endpoint:

- In Plan A, this is done by marking them bundle-only
- In Plan B, this is done by having them be additional SSRCs on one
=A0 of the extant m-lines.



Regardless of Plan A versus Plan B, bundle contemplates having
multiple media flows on the same media 5-tuple. Thus, it must
be possible to demux the flows somehow. As I read Plan A,
it proposes using both PT and SSRC to demux whereas plan B
only wants to use SSRC? So, the implication is that a Plan A
endpoint must:

1. Demux on both PT and SSRC (this is trivial, I think you will agree)

The demuxing is trivial. In fact, I don't think it's even neces= sary to describe it as "demux on PT"; you can't allow SSRC col= lision between two tracks with different PT anyway.


2. When acting as offerer, either always offer SSRC or conditionally
offer SSRC when the # of PTs is excessive.

I don't understand why you think that plan A means more ports than
plan B. Presumably we can simply specify that bundle requires
SSRC muxing, in which case plan A and plan B behave identically.

What am I missing?

This particular issue is about what happens when you run out of payload types to multiplex on.

In Plan A as I currently understand Adam, any application that needs less than 96 M-lines (Adam's number) can use a single port, and use the payload type to indicate the M-line.

If there are 97 M-lines, if I've understood Adam correctly, one could use two ports and two bundles, with some subset of the M-lines being allocated to one bundle and another subset of the M-lines allocated to the other bundle.

In Plan B, there is no difference in the mechanism used to multiplex 96 SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter for the multiplexing how many M-lines they are distributed over.



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


--001a11c3c96ee1103204dce7d114-- From ekr@rtfm.com Fri May 17 06:07:46 2013 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 7783D21F9412 for ; Fri, 17 May 2013 06:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.701 X-Spam-Level: X-Spam-Status: No, score=-101.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+6ef4bmP7ZL for ; Fri, 17 May 2013 06:07:42 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 37B8521F9416 for ; Fri, 17 May 2013 06:07:42 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n1so264220qcw.27 for ; Fri, 17 May 2013 06:07:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=HB+Z4sCjeXm0oN3neRYhjXmso6Y/2H/8h0fukeE9Zc8=; b=oDTD9y3e9C1MLoRcAHAtDA5SJS3zmU/FmTW26mwD6c/2nqf9Zlf1vVICd6NZAwQ7FT lzseH+ftmWxfpkSbCQRuDu8vtRt3Tvzx1r1EtIqolioVKnIdniKDA/l6JdmnOz8mfMr/ oxXGo3Ft9M7BmVzAdsRQem1julL8xrIk+jbaBSXviZNhJ3rxvdfwhyCYiYZ5oh4RE0kC uxgp161HzLQBWPuf6+u6/ySiABrUSHJWEjp0zunyvdvmk1aMZ1EEkbCOkdpPpWZIecIz vPXwVkZLQtCwhR6sX+g5FDufdIrEvyomJ0K8Pz/3Inzp1pzkrTLdMZc7K3fpkvFwq2oC s2NQ== X-Received: by 10.224.40.10 with SMTP id i10mr36805800qae.96.1368796061588; Fri, 17 May 2013 06:07:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.85.130 with HTTP; Fri, 17 May 2013 06:07:00 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <5195CEDF.9040109@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> From: Eric Rescorla Date: Fri, 17 May 2013 06:07:00 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf3071d15605956b04dce9abba X-Gm-Message-State: ALoCoQlZxL//PCb8bQraM/8L2BgGHedofoAqrr18P6upcsOjiRIbXeraLM32vEEh2iFpj6kA7afJ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 13:07:46 -0000 --20cf3071d15605956b04dce9abba Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 11:31 PM, Harald Alvestrand wrote: > On 05/17/2013 01:28 AM, Eric Rescorla wrote: > > > > On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand wrote: >> >> If the true limit at which one has to change allocation strategy were >>>> to become 96, not 32, it actually strengthens my "falling off a cliff" >>>> argument >>>> >>> >>> And, to be clear, it's not a cliff. For any given session (without >>> a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you >>> go from using one port to using 97 ports when you add the 97th stream. You >>> go from one port to two, which will handle 192 streams. >>> >> >> Going from one port to two ports is a cliff. >> We may have differing opinions on how tall it is. > > > Harald, > > I am not following how this is a discriminating factor between Plan A and > Plan B. > > In both Plan A and Plan B, any media stream which is intended to be > independently processable by a legacy endpoint must appear on its > own m-line. That means it must also have its own independent ports, > even if you are hoping to eventually be able to mux it via BUNDLE. > > > I agree with this characterization - the two proposals have the same > number of ports in the initial offer. > > I quibble about the characterization "any media stream which is intended > to be > independently processable by a legacy endpoint must appear on its > own m-line." As Bernard has said, the field of deployed applications is > diverse enough to make this question confusing - both "independently > processable" and "legacy endpoint" may need further qualification in order > to make that statement unequivocally true. > Well, to the extent to which there are many legacy endpoints which assume that each renderable entity must be on its own m-line, then presumably you need to follow this rule to ensure interop, no? In both Plan A and Plan B, it is possible to indicate additional media > streams that are not processable by a legacy endpoint but that > will be processable by a new endpoint: > > - In Plan A, this is done by marking them bundle-only > - In Plan B, this is done by having them be additional SSRCs on one > of the extant m-lines. > > > > Regardless of Plan A versus Plan B, bundle contemplates having > multiple media flows on the same media 5-tuple. Thus, it must > be possible to demux the flows somehow. As I read Plan A, > it proposes using both PT and SSRC to demux whereas plan B > only wants to use SSRC? So, the implication is that a Plan A > endpoint must: > > 1. Demux on both PT and SSRC (this is trivial, I think you will agree) > > > The demuxing is trivial. In fact, I don't think it's even necessary to > describe it as "demux on PT"; you can't allow SSRC collision between two > tracks with different PT anyway. > This seems to me to be true only in the trivial sense. I.e., demuxing is not just a matter of separation but also of assignment. So, as Cullen has observed, if the two m-lines use distinct PTs, the offerer can properly demux and display the streams even before receiving the answer. > 2. When acting as offerer, either always offer SSRC or conditionally > offer SSRC when the # of PTs is excessive. > > I don't understand why you think that plan A means more ports than > plan B. Presumably we can simply specify that bundle requires > SSRC muxing, in which case plan A and plan B behave identically. > > What am I missing? > > > This particular issue is about what happens when you run out of payload > types to multiplex on. > > In Plan A as I currently understand Adam, any application that needs less > than 96 M-lines (Adam's number) can use a single port, and use the payload > type to indicate the M-line. > > If there are 97 M-lines, if I've understood Adam correctly, one could use > two ports and two bundles, with some subset of the M-lines being allocated > to one bundle and another subset of the M-lines allocated to the other > bundle. > Yes, one could. But one could also use one port, one bundle, and demux on SSRC. In Plan B, there is no difference in the mechanism used to multiplex 96 > SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter > for the multiplexing how many M-lines they are distributed over. > I would say rather that plan B *only* allows SSRC multiplexing whereas plan A allows you to use other forms of multiplexing beside SSRC, but only under limited circumstances. However, I'm not sure why this is a big issue. The requirement for distinct PTs isn't new to plan A. In fact, it's in Section 7.2 of BUNDLE: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03#section-7.2 This seems to me to be a question the working group needs to resolve for BUNDLE and then it can just be inherited by either Plan A or Plan B. -Ekr --20cf3071d15605956b04dce9abba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 16, 2013 at 11:31 PM, Harald= Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 05/17/2013 01:28 AM, Eric Rescorla wrote:


On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
If the true limit at which one has to change allocation strategy were to become 96, not 32, it actually strengthens my "falling off a cliff" argument

And, to be clear, it's not a cliff. For any given session (without a=3Dssrc:), you have to allocate ceiling(streams/96) ports. It's not like you go from usin= g one port to using 97 ports when you add the 97th stream. You go from one port to two, which will handle 192 streams.

Going from one port to two ports is a cliff.
We may have differing opinions on how tall it is.

Harald,

I am not following how this is a discriminating factor between Plan A and
Plan B.

In both Plan A and Plan B, any media stream which is intended to be
independently processable by a legacy endpoint must appear on its
own m-line. That means it must also have its own independent ports,
even if you are hoping to eventually be able to mux it via BUNDLE.

I agree with this characterization - the two proposals have the same number of ports in the initial offer.

I quibble about the characterization "any media stream which is intended to be
independently processable by a legacy endpoint m= ust appear on its
own m-line." As Bernard has said, the field of deployed applicatio= ns is diverse enough to make this question confusing - both "independently processable" and "legacy endpoint" m= ay need further qualification in order to make that statement unequivocally true.
=

Well, to the extent to which there are man= y legacy endpoints which assume that
each renderable entity must = be on its own m-line, then presumably you
need to follow this rule to ensure interop, no?

In both Plan A and Plan B, it is possible to indicate additional media
streams that are not processable by a legacy endpoint but that
will be processable by a new endpoint:

- In Plan A, this is done by marking them bundle-only
- In Plan B, this is done by having them be additional SSRCs on one
=A0 of the extant m-lines.



Regardless of Plan A versus Plan B, bundle contemplates having
multiple media flows on the same media 5-tuple. Thus, it must
be possible to demux the flows somehow. As I read Plan A,
it proposes using both PT and SSRC to demux whereas plan B
only wants to use SSRC? So, the implication is that a Plan A
endpoint must:

1. Demux on both PT and SSRC (this is trivial, I think you will agree)

The demuxing is trivial. In fact, I don't think it's even neces= sary to describe it as "demux on PT"; you can't allow SSRC col= lision between two tracks with different PT anyway.
This seems to me to be true only in the trivial sense. =A0I.e.,= demuxing is not
just a matter of separation but also of assignme= nt. So, as Cullen has
observed, if the two m-lines use distinct PTs, the offerer can properl= y
demux and display the streams even before receiving the answer.=


2. When acting as offerer, either always offer SSRC or conditionally
offer SSRC when the # of PTs is excessive.

I don't understand why you think that plan A means more ports than
plan B. Presumably we can simply specify that bundle requires
SSRC muxing, in which case plan A and plan B behave identically.

What am I missing?

This particular issue is about what happens when you run out of payload types to multiplex on.

In Plan A as I currently understand Adam, any application that needs less than 96 M-lines (Adam's number) can use a single port, and use the payload type to indicate the M-line.

If there are 97 M-lines, if I've understood Adam correctly, one could use two ports and two bundles, with some subset of the M-lines being allocated to one bundle and another subset of the M-lines allocated to the other bundle.

Yes, one could. But one could also use one port, one bundle, and demux on= SSRC.


In Plan B, there is no difference in the mechanism used to multiplex 96 SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter for the multiplexing how many M-lines they are distributed over.

I would say= rather that plan B *only* allows SSRC multiplexing whereas plan
= A allows you to use other forms of multiplexing beside SSRC, but only under=
limited circumstances.

However, I'm not s= ure why this is a big issue. The requirement for distinct
PTs isn= 't new to plan A. In fact, it's in Section 7.2 of BUNDLE:
This seems to me to be a que= stion the working group needs to resolve
for BUNDLE and then it can just be inherited by either Plan A or Plan = B.

-Ekr

--20cf3071d15605956b04dce9abba-- From bernard_aboba@hotmail.com Fri May 17 06:12:20 2013 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 C034A21F946C for ; Fri, 17 May 2013 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaAKUpysfoeh for ; Fri, 17 May 2013 06:12:16 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by ietfa.amsl.com (Postfix) with ESMTP id 16C7321F942B for ; Fri, 17 May 2013 06:12:16 -0700 (PDT) Received: from BLU403-EAS90 ([65.55.111.72]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 06:12:15 -0700 X-EIP: [zOQtr2Qde1CdtxfEN8nh/YHSFp9qKgV6] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <519524EA.3000509@alvestrand.no> Date: Fri, 17 May 2013 06:12:15 -0700 To: Harald Alvestrand X-OriginalArrivalTime: 17 May 2013 13:12:15.0624 (UTC) FILETIME=[26CA9880:01CE5300] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 13:12:20 -0000 The Iraqi Information minister did not correctly communicate "facts on the g= round", whereas I do think Harald correctly characterizes how some existing i= mplementations behave.=20 Given the discussion on this topic I would suggest that it would be useful t= o include a recommendation for WebRTC implementations (in the RTP usage docu= ment?). On May 16, 2013, at 11:27, "Harald Alvestrand" wrote:= > Adam, this is the first time I've been compared to the Iraqi Information M= inister... another achievement unlocked! >=20 > There are just 2 issues with your correction: >=20 > 1) I don't believe your comment (or the RFCs you cite) reflect currently d= eployed reality. > I've seen the lines of code - they allocate from 32 dynamic types, not 192= . > So the solution you propose is going to be incompatible with deployed code= bases. >=20 > 2) If the true limit at which one has to change allocation strategy were t= o become 96, not 32, it actually strengthens my "falling off a cliff" argume= nt (unless you don't believe in applications with more than 96 streams): Thi= s won't be a problem except in rare cases - ensuring even more code will be d= eployed that works until stressed. >=20 > I also have a confession to make: On some days, I respond to mail addresse= d to me without checking that I'm caught up on the mailing list that the con= versation is copied to. >=20 > In this case, I responded to the mail sent directly to me on May 12 (a Sun= day) without checking that I had also read your posting to the list on May 8= (Wednesday on the week before). >=20 > I suppose that's enough of a lapse in courtesy to be deserving of some cen= sure. >=20 > Harald > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Fri May 17 08:00:37 2013 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 34D2621F95EE for ; Fri, 17 May 2013 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0pP53p9cwFI for ; Fri, 17 May 2013 08:00:35 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E365021F95F4 for ; Fri, 17 May 2013 08:00:34 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so2429311bkc.18 for ; Fri, 17 May 2013 08:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=FFARHMDrPtwypOScCJ54nHVrRLPqE/E/BR4lb20tM+c=; b=Exbl+kNfZ+jzv+a2Smsk/trNX0zkuUUvQySxVXxuJx7gCKtxmJGXrS6MHy7uVj945w mbqXOhaB0Jre3ud3o4/6QvXmxQNDF0UShVeWx6Hfu7vTxgnRqXfDB2VPSYIxbi4U6cQw tIRcdAybnCvV3qPJYertT116UQJ5ADtTbd1b0Odsv+eaBeiFcn3Z3ulZ56Nha/bf/A3c 0nArXYvzBFI4317mjq0c4ZYDEjK0im63DLGASo1a+7UyoDrJk1luGpXOHD3MgaFWuHEa PPBXNi+7O5oSKe8+yU+e3rjgRqlAVf2n9PZ3pfY8AhFnGbbj4X/Kn64fGI+77565Yf17 jngA== X-Received: by 10.205.9.193 with SMTP id ox1mr5994222bkb.35.1368802833499; Fri, 17 May 2013 08:00:33 -0700 (PDT) Received: from camionet.local ([83.228.78.84]) by mx.google.com with ESMTPSA id tc9sm3210472bkb.18.2013.05.17.08.00.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 08:00:32 -0700 (PDT) Message-ID: <5196460B.9000808@jitsi.org> Date: Fri, 17 May 2013 18:00:27 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eric Rescorla References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkgMjvvbOR+DAKS91V2Hiij2Ir53PlH7DZNqN2m8yZFt2Cse/8QKf58FFvwHU7PQIxva+6q Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 15:00:37 -0000 On 17.05.13, 16:07, Eric Rescorla wrote: > > On Thu, May 16, 2013 at 11:31 PM, Harald Alvestrand > > wrote: > I quibble about the characterization "any media stream which is > intended to be > independently processable by a legacy endpoint must appear on its > own m-line." As Bernard has said, the field of deployed applications > is diverse enough to make this question confusing - both > "independently processable" and "legacy endpoint" may need further > qualification in order to make that statement unequivocally true. > > > Well, to the extent to which there are many legacy endpoints which > assume that > each renderable entity must be on its own m-line, There are tons of legacy endpoints that know what to do with one audio m= line. There are some legacy endpoints that which know what to do with one audio and one video m=line. There might be endpoints that are capable of handling multiple audio video endpoints but I am not sure how they could possibly be quantified as many. > then presumably you need to follow this rule to ensure interop, no? Therefore, the interop part with the "many" endpoints seems to be covered already. One still needs to find ways of handling and potentially gatewaying ICE and SRTP for many of them but that's a different matter. O/A-wise we seem to have consensus on how to do the case with the two m= lines that each carry one track. It seems to me that we have now moved beyond that. Emil -- https://jitsi.org From ekr@rtfm.com Fri May 17 08:08:59 2013 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 EF14121F965F for ; Fri, 17 May 2013 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5FZNgCDo-Va for ; Fri, 17 May 2013 08:08:54 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0F16521F9660 for ; Fri, 17 May 2013 08:08:53 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id 1so2706486qec.25 for ; Fri, 17 May 2013 08:08:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=FNkBJWCl/FMdhTqC93qioNtAVhmEoCh7UQ5pP/nZJVM=; b=Fc49qtG9LM/xTBDcU/fmW/b3FI21XYB8XXTjAwcCE0QZaTwAL/VDAd8j8dlV16CCAk elmSkZ9aZcEDDL01OuYWRd/es9wEXQg/+TPPRdtsheOI7CDIBvfSI6E3uiNPfzd8VNK6 y6XZn1u1tpOV3QGs7JFktWEvaWLU/VOKtOQI5H0hwAC8jBOq2csVOnF8xqPIlwlW+ldf sR3DPD3oqukv5m0qr23Kl6fAa006p8yfzoW/Jcb3WoFbkcmoZ5XGd7oLVIAjIEXCghEq 6kmVqNgt7br+EZumnpdCa5DbhOGqMT2eWzNFryZFhwKODQFhDSUCOR+hPPzSddJzYYAe YcGA== X-Received: by 10.224.40.10 with SMTP id i10mr37310145qae.96.1368803333537; Fri, 17 May 2013 08:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.85.130 with HTTP; Fri, 17 May 2013 08:08:12 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <5196460B.9000808@jitsi.org> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5196460B.9000808@jitsi.org> From: Eric Rescorla Date: Fri, 17 May 2013 08:08:12 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=20cf3071d15676c6a804dceb5c21 X-Gm-Message-State: ALoCoQlxoxLMGQSz87QEOREJux+L26r27B9DW9RallZbY1pE9ajeAEGbkt7GNBvOVoga+/kpkPlM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 15:09:00 -0000 --20cf3071d15676c6a804dceb5c21 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 17, 2013 at 8:00 AM, Emil Ivov wrote: > > On 17.05.13, 16:07, Eric Rescorla wrote:=line. > > then presumably you need to follow this rule to ensure interop, no? > > Therefore, the interop part with the "many" endpoints seems to be > covered already. One still needs to find ways of handling and > potentially gatewaying ICE and SRTP for many of them but that's a > different matter. O/A-wise we seem to have consensus on how to do the > case with the two m= lines that each carry one track. > > It seems to me that we have now moved beyond that. > The question is how an endpoint which wishes fo offer more than one audio and one video does so in a way that doesn't cause older endpoints to choke. -Ekr --20cf3071d15676c6a804dceb5c21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 17, 2013 at 8:00 AM, Emil Ivov <emcho@jitsi.org> w= rote:

On 17.05.13, 16:07, Eric Rescorla wrote:=3Dline.
> then presumably you need to follow this rule to ensure interop, no?
Therefore, the interop part with the "many" endpoints seems= to be
covered already. One still needs to find ways of handling and
potentially gatewaying ICE and SRTP for many of them but that's a
different matter. O/A-wise we seem to have consensus on how to do the
case with the two m=3D lines that each carry one track.

It seems to me that we have now moved beyond that.
The question is how an endpoint which wishes fo offer more than= one
audio and one video does so in a way that doesn't cause = older
endpoints to choke.

-Ekr
=A0
<= /div> --20cf3071d15676c6a804dceb5c21-- From fluffy@cisco.com Fri May 17 08:48:17 2013 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 9D8E521F96E4 for ; Fri, 17 May 2013 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCtKJCKL8SGR for ; Fri, 17 May 2013 08:48:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11BB021F96E1 for ; Fri, 17 May 2013 08:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1983; q=dns/txt; s=iport; t=1368805693; x=1370015293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4n+B3cEfG/4dOs3NxV5mkPUNjGd3EZSy+/2cHLn59Ao=; b=jy+7nhXHM2B3Rm4onDnY08JpucckPeB2GvarSdZ/qN84dCs00DQSpIn3 h/nt/iYwajHVAbJvTj3YvjjgmzZBeLa/sYZJEB1R38TpJYiyznTlaVZ3z beeBB+93uZ2xkV7kk5sBFqvIa6GXvgBM9uZejUNei/vF3gndBSeXLceqS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFANBQllGtJXG//2dsb2JhbABagwgwwVB9FnSCHwEBAQMBAQEBNzQLEAIBCA4KChQQIQYLJQIEDgUIh3IDCQYMtEQNiGCMSoIkAjEHgnNhA5VSjgOFI4MPgiY X-IronPort-AV: E=Sophos;i="4.87,693,1363132800"; d="scan'208";a="211623485" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 17 May 2013 15:48:12 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4HFmC9R020695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 15:48:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 17 May 2013 10:48:12 -0500 From: "Cullen Jennings (fluffy)" To: Cullen Jennings Thread-Topic: [rtcweb] New Doodle for Virtual Interim on SDES Thread-Index: AQHOUxXvGVpUS6Ubtke1TVIeILAjAw== Date: Fri, 17 May 2013 15:48:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Doodle for Virtual Interim on SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 15:48:17 -0000 I apologize but I have messed up the time zone when I entered this poll - D= oodle seem weird about the different between PDT and PST. The times were m= eant to starting at 5:30 am PDT on monday and 6:00 am PDT on tuesday and We= dnesday and be 2.5 hours long. I have updated the poll which lost all the = entries of anyone that had already filled it out so you need to redo it.=20 On May 16, 2013, at 2:18 PM, Cullen Jennings wrote: >=20 > We are still trying to pick a time to have an Virtual Interim meeting for= the IETF RTCWeb WG on the topic of SDP Security Descriptions (RFC 4568 aka= SDES). The goal is not to make a decision about this but the goal is to ge= t everyone understanding the pros and cons of all the options.=20 >=20 > The proposed length of the meeting is 2.5 hours. >=20 > Please fill out the doodle at by the end of the day on May 22=20 >=20 > http://www.doodle.com/22qy6vcpre4vqex6 >=20 > Thanks, The chairs ... >=20 >=20 > On May 9, 2013, at 9:39 AM, Ted Hardie wrote: >=20 >> Howdy, >>=20 >> Given the MMUSIC working group virtual interim is now scheduled for May = 23rd, the RTCWEB chairs plan to push back the SDES-focused virtual interim = we'd previously announced, so that folks can focus on the Plan A and Plan B= discussion to happen there. =20 >>=20 >> We will put out a new doodle poll early next week with dates in June. T= he current plan is that the virtual interim will include discussion of the = base security properties, EKT, and some of the other issues which have come= up in working group discussion. >>=20 >> regards, >>=20 >> Ted, Cullen, and Magnus >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Fri May 17 08:51:35 2013 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 AFD8221F96FF for ; Fri, 17 May 2013 08:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaF84tel1QlI for ; Fri, 17 May 2013 08:51:31 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6C76321F9702 for ; Fri, 17 May 2013 08:51:21 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id cykk1l0030vyq2s553rKMd; Fri, 17 May 2013 15:51:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id d3rK1l0133ZTu2S3R3rKRU; Fri, 17 May 2013 15:51:19 +0000 Message-ID: <519651F6.60305@alum.mit.edu> Date: Fri, 17 May 2013 11:51:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> In-Reply-To: <5195CEDF.9040109@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368805879; bh=CvecQFWVIbFo+RuWP88kTlLj33Pm4vjuArhYlX4rI8c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ncuA2+5Sm4B2SRk9IlRIPBE7jV9V12SRObkatDs0UFl7q3TON6CMSOwYsPF1vf6qF N/mJNAcYp2TymkncoI7islV9aAN7u5GIUsVFohVeofn+VYPVNGxE7PLtfD7x9Z9wR1 xxnzYqyqEvGCBukRGS3BlNJP6WLyraUZHIriu2GTWSJchtMw6kmIfcTd8b7IILaEXd D8GVIlGGPpWKBXI4fOI8Chwztvv9wCQpj0GuXzLzQ4NSWHIHMrd+Fu1rCRdM4iGk0B k5+mubYbTy+SS/JycnTN019EZ8cxag/Xyq06jHS3ibE6XLoia6C52fs0d5IvNKRVM/ 8Nnx2U/1kALvw== Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 15:51:35 -0000 ISTM we may be mixing up two things when discussing demuxing: * getting packets to the correct instance of the correct decoder. Any of these proposals can handle the first. The only constraint is that a particular PT must be consistently mapped to the same codec and parameters in each bundled m-line where it appears. Its not necessary to restrict a PT to a particular m-line to achieve this. * associating those packets with a particular m-line in the bundle. There must be some combination of fields within each RTP packet that are unique to a particular bundled media section (m-line and friends) in the bundle to achieve this. That could be: - SSRC - PT - the value of some RTP header extension that matches some new SDP attribute - some combination of the above This is important because it then binds that instance of the decoder to all the properties of the SDP media section. I don't think it is necessary to make a single choice from the above list. In some cases it may be possible to infer this, by analyzing the SDP and identifying what combination of properties uniquely identifies each m-line. But in some cases it may be ambiguous. If so, then I think we should signal what should be used. For instance, demux by SSRC and demux by clue capture id may yield conflicting results. (A single SSRC may move from one capture to another.) So, rather than argue about which is the right way, can't we just discuss how to signal which one to use? Thanks, Paul On 5/17/13 2:31 AM, Harald Alvestrand wrote: > On 05/17/2013 01:28 AM, Eric Rescorla wrote: >> >> >> On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand >> > wrote: >> >> If the true limit at which one has to change allocation >> strategy were to become 96, not 32, it actually >> strengthens my "falling off a cliff" argument >> >> >> And, to be clear, it's not a cliff. For any given session >> (without a=ssrc:), you have to allocate ceiling(streams/96) >> ports. It's not like you go from using one port to using 97 >> ports when you add the 97th stream. You go from one port to >> two, which will handle 192 streams. >> >> >> Going from one port to two ports is a cliff. >> We may have differing opinions on how tall it is. >> >> >> Harald, >> >> I am not following how this is a discriminating factor between Plan A and >> Plan B. >> >> In both Plan A and Plan B, any media stream which is intended to be >> independently processable by a legacy endpoint must appear on its >> own m-line. That means it must also have its own independent ports, >> even if you are hoping to eventually be able to mux it via BUNDLE. > > I agree with this characterization - the two proposals have the same > number of ports in the initial offer. > > I quibble about the characterization "any media stream which is intended > to be > independently processable by a legacy endpoint must appear on its > own m-line." As Bernard has said, the field of deployed applications is > diverse enough to make this question confusing - both "independently > processable" and "legacy endpoint" may need further qualification in > order to make that statement unequivocally true. > >> >> In both Plan A and Plan B, it is possible to indicate additional media >> streams that are not processable by a legacy endpoint but that >> will be processable by a new endpoint: >> >> - In Plan A, this is done by marking them bundle-only >> - In Plan B, this is done by having them be additional SSRCs on one >> of the extant m-lines. >> >> >> >> Regardless of Plan A versus Plan B, bundle contemplates having >> multiple media flows on the same media 5-tuple. Thus, it must >> be possible to demux the flows somehow. As I read Plan A, >> it proposes using both PT and SSRC to demux whereas plan B >> only wants to use SSRC? So, the implication is that a Plan A >> endpoint must: >> >> 1. Demux on both PT and SSRC (this is trivial, I think you will agree) > > The demuxing is trivial. In fact, I don't think it's even necessary to > describe it as "demux on PT"; you can't allow SSRC collision between two > tracks with different PT anyway. > >> 2. When acting as offerer, either always offer SSRC or conditionally >> offer SSRC when the # of PTs is excessive. >> >> I don't understand why you think that plan A means more ports than >> plan B. Presumably we can simply specify that bundle requires >> SSRC muxing, in which case plan A and plan B behave identically. >> >> What am I missing? > > This particular issue is about what happens when you run out of payload > types to multiplex on. > > In Plan A as I currently understand Adam, any application that needs > less than 96 M-lines (Adam's number) can use a single port, and use the > payload type to indicate the M-line. > > If there are 97 M-lines, if I've understood Adam correctly, one could > use two ports and two bundles, with some subset of the M-lines being > allocated to one bundle and another subset of the M-lines allocated to > the other bundle. > > In Plan B, there is no difference in the mechanism used to multiplex 96 > SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not > matter for the multiplexing how many M-lines they are distributed over. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From emil@sip-communicator.org Fri May 17 09:02:53 2013 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 6C66E21F974B for ; Fri, 17 May 2013 09:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpadwDe0YK+N for ; Fri, 17 May 2013 09:02:52 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7347B21F9749 for ; Fri, 17 May 2013 09:02:52 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jk14so832530bkc.31 for ; Fri, 17 May 2013 09:02:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=fCNBRa89OcE60svkfVsogEuACSxTGFrLJ2vyTY0Y8Os=; b=G+IxMfmcS6LGFUsvEJyn7xTEO93jvVnkHcP3zhz1Ml3YTaHmSV/GtwZYxCTD2QLLBw GNqpDUgIQfa+OHRuoeDHromXDWMj/DzLfb8QixSy+y4FAsSI5Ex6QcohCpUgpquUz5Sb hydXGzTd9Z4cIZOBqT+jqRegcBTkYCYegnEPTGKJHs1Z+KbZgOV4w56C9MuTrlZex/io ZqIZaZJE6zS3XpYNetHmd54M44Ls/azD5p8/dLACv1vMWO2LvYmUcMLxASpxwyCkFm/U jRZqJd8XFcf/3Fq6psJGQNGSzofhd2BtU/998JIm5za0JoHI0PLQniOG2x+ZVQG6t/Hi uv1g== X-Received: by 10.205.21.10 with SMTP id qq10mr16081438bkb.133.1368806571278; Fri, 17 May 2013 09:02:51 -0700 (PDT) Received: from camionet.local ([83.228.78.84]) by mx.google.com with ESMTPSA id i15sm3272888bkz.12.2013.05.17.09.02.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 09:02:50 -0700 (PDT) Message-ID: <519654A5.1050406@jitsi.org> Date: Fri, 17 May 2013 19:02:45 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eric Rescorla References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5196460B.9000808@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkRq4RijsE8zrfQyC21ue1f1E/fJOL71F/hLnGlzq/ryIASsWxya0DyMn62ol5IrzRWjmtl Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 16:02:53 -0000 On 17.05.13, 18:08, Eric Rescorla wrote: > On Fri, May 17, 2013 at 8:00 AM, Emil Ivov > wrote: > > > On 17.05.13, 16:07, Eric Rescorla wrote:=line. > > > > then presumably you need to follow this rule to ensure interop, no? > > Therefore, the interop part with the "many" endpoints seems to be > covered already. One still needs to find ways of handling and > potentially gatewaying ICE and SRTP for many of them but that's a > different matter. O/A-wise we seem to have consensus on how to do the > case with the two m= lines that each carry one track. > > It seems to me that we have now moved beyond that. > > > The question is how an endpoint which wishes fo offer more than one > audio and one video does so in a way that doesn't cause older > endpoints to choke. I might be misunderstanding or missing something, but isn't it clear that, if you are trying not to choke anyone, the first thing to do would be to stick to a single m= line for audio and a single m= line for video? Emil -- https://jitsi.org From emil@sip-communicator.org Fri May 17 09:04:30 2013 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 6EF4521F9718 for ; Fri, 17 May 2013 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbdQAq0bB2u4 for ; Fri, 17 May 2013 09:04:29 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F021F967F for ; Fri, 17 May 2013 09:04:28 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf3so2492121bkc.35 for ; Fri, 17 May 2013 09:04:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding :x-gm-message-state; bh=DbWHKfQ0GYykkDAmxOqGn2as2nve8XD0ADRmArbFgwo=; b=mwx0QVKYpA+PdxWW0ijI+CVepoZZTeDG412N2qFVO5IA4PbJt/1w2RPmBTK4iGysyV qi5c1loEdBAPwaHyIwp4ZZV3Wgja7oGqleOxjQ0Y8e8DQb+WZugM15E7bbGlaJ6QJ3G7 AFWWHY96uO4c1w1yOvdBIhGFt/GOoN9xVe/A9yFgrE70QD/0oeHrofV0SKeDOJVksrQ0 CdV4zEKJxbRpIn2S6+zHk2uFfalVx6tYcmdd+cnqB5GqTyyyngaxD7laV6e31H9QsiUL 6PN9LF+WUdQxMr4XP/Qdn+epJ60MrNcQhGqonVGt+h6fZDYXjUk9WPfSdSwSaiR0/KkI Za7w== X-Received: by 10.204.71.12 with SMTP id f12mr15980490bkj.32.1368806667968; Fri, 17 May 2013 09:04:27 -0700 (PDT) Received: from camionet.local ([83.228.78.84]) by mx.google.com with ESMTPSA id j8sm3271146bky.17.2013.05.17.09.04.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 09:04:27 -0700 (PDT) Message-ID: <51965506.7050008@jitsi.org> Date: Fri, 17 May 2013 19:04:22 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlzPGRXdfgkBby9Tj0kR3C2sdhW5jNxPw3UTXe+ArFKPNWJtm6kTi4BMCzHW7Tr1aV/HAuZ Subject: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 16:04:30 -0000 I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately. Both plan A and B currently describe semantics that would require O/A exchanges every time a source is added or removed from a session. Whether it is about adding a second webcam, or a conference participant that leaves or joins, both schemes suggest that the remote party should be notified with an updated SDP. Plan A deals with this by manipulating m= lines, while plan B does it with msid-s. We are nowhere near consensus and I think that this fact alone is a strong argument in favour of the following: This is not a problem for rtcweb to solve. We all have our own preferences for a solution and those come from the different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on the Web paradigm we would provide building blocks which can then be assembled into specific solutions (rather than providing the solutions themselves). In other words: it is not our job to try and implant a signalling protocol into O/A. Signalling is the job of the application. Applications alone know the meaning of the stream that came from your second web cam, or that of the tenth conference participant. They know which conferencing topology they most care about. They have best knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be displayed to describe the streams they are currently getting. Most importantly however: they are best placed to know how they'd like to communicate that information to their peers or IF they need to communicate it at all. Currently neither Plan A nor Plan B would let the application do its job. However I do believe Plan B is closer. If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and the only remaining problem is its insistence on the pre-announcement of SSRCs. If we get rid of that requirement then all we need would be for the W3C to make sure that the APIs have everything they need to allow apps to retrieve SSRC information, send it remotely then pass it down to the browser again when they receive it. I acknowledge that the simulcasting and FEC cases might be a bit different, which is normal because they are about the resolution of transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth investigating the options of doing this through RTP/RTCP. Does any of this make any sense? Emil -- https://jitsi.org From martin.thomson@gmail.com Fri May 17 09:10:06 2013 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 7C64221F9307 for ; Fri, 17 May 2013 09:10:06 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF62lqumMeB1 for ; Fri, 17 May 2013 09:10:06 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A453F21F90EE for ; Fri, 17 May 2013 09:10:05 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ed20so4471224lab.9 for ; Fri, 17 May 2013 09:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ALXTSGFOvjUsm+jHLtzh6neWrss/ZFteB/dAO6UN5Es=; b=ttbWcdBv0XTkcivRaoeE1SPYJ/6fl6InTVdY6Cflj/Bktk0RvwpN6UrwTnQxV7WFlz GSGNlehTiXdc9Vq8C91SQ8vqaqnk1juCaXDlZz7EjsrEIRap4bqF3sK5l+67kVkikIIF T4qhFXhpVPfD7P69bsSqzUhqaWjLOKhvqAEWULsSDN+vXd87xxcunQLSTMU1vO+c3d+w y1bGpF9Ugx4rpkp/cHYaNf8V1bsA+w/fZVZtS49X9kWz5+WLlc+lQ6ttrx86IFtWfn9h SqXlozIGKOUAEdUtUQjzCSp60enabdrVJI/5yzsfbVuFSNGRcKFok7mlijEiANSC+TlN cuEw== MIME-Version: 1.0 X-Received: by 10.112.157.231 with SMTP id wp7mr15125194lbb.91.1368807004327; Fri, 17 May 2013 09:10:04 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Fri, 17 May 2013 09:10:04 -0700 (PDT) In-Reply-To: <5195CEDF.9040109@alvestrand.no> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> Date: Fri, 17 May 2013 09:10:04 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 16:10:06 -0000 On 16 May 2013 23:31, Harald Alvestrand wrote: > The demuxing is trivial. In fact, I don't think it's even necessary to > describe it as "demux on PT"; you can't allow SSRC collision between two > tracks with different PT anyway. Let's be very, very precise about this. Demultiplexing is *always* performed based on SSRC. It's just that correlation with signaling components (the m-line in this case) might use of PT in the absence of prior knowledge of SSRC. We didn't get this quite right in Plan A. From mzanaty@cisco.com Fri May 17 10:43:57 2013 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 B90EE11E8103 for ; Fri, 17 May 2013 10:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5lD02VH6hVA for ; Fri, 17 May 2013 10:43:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 139F721F9661 for ; Fri, 17 May 2013 10:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3067; q=dns/txt; s=iport; t=1368812633; x=1370022233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n+1NL6XJNCcCIozusXdqwQHgjBR3ukr8gPoGsgup7TE=; b=Md/uPJ9oaW3P8POEbaXcKyYQBQrqf8M1K5wN179a8btq2LU2/LDiQsnn 9d/luFpczJppQwl+LTkzr2s4IkBvFvB4vDY+zMRayev6AGo5TGkxYm7VE WN3zt7SroNWGDY48Ebbr9ZFHmF87Q2YS92JbSOGQsUHkDQZpbXKXKhNXx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANFqllGtJV2Z/2dsb2JhbABagwgwwU5+FnSCHwEBAQMBAQEBNzQLDAQCAQgRBAEBAQoUCQchBgsUCQgCBAENBQiHcgMJBgy0Tw2IYoxKgiYxBwaCbWEDlVKOA4Ujgw+CJg X-IronPort-AV: E=Sophos;i="4.87,694,1363132800"; d="scan'208";a="211832412" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 17 May 2013 17:43:52 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4HHhqhe026402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 17:43:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 17 May 2013 12:43:52 -0500 From: "Mo Zanaty (mzanaty)" To: "Cullen Jennings (fluffy)" , Cullen Jennings Thread-Topic: [rtcweb] New Doodle for Virtual Interim on SDES Thread-Index: AQHOUxXvGVpUS6Ubtke1TVIeILAjA5kJoC8w Date: Fri, 17 May 2013 17:43:51 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D479607@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.239.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Doodle for Virtual Interim on SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 17:43:58 -0000 Doodle has a timezone bug when displaying/selecting your timezone. It alway= s shows standard times even though you are on summer/daylight time. But if = you just select your standard timezone, the times in the table are actually= correct for summer/daylight time. So the timezone label is wrong, but the = actual table times are right. CLUE and RMCAT polls hit this recently. It was especially confusing for RMC= AT since the date was when some folks (US) already switched to summer/dayli= ght time while others (EU) were still on standard time. We had to use absol= ute UTC to clear up the confusion for that week when the world was out of s= ync. Mo -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: Friday, May 17, 2013 11:48 AM To: Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Doodle for Virtual Interim on SDES I apologize but I have messed up the time zone when I entered this poll - D= oodle seem weird about the different between PDT and PST. The times were m= eant to starting at 5:30 am PDT on monday and 6:00 am PDT on tuesday and We= dnesday and be 2.5 hours long. I have updated the poll which lost all the = entries of anyone that had already filled it out so you need to redo it.=20 On May 16, 2013, at 2:18 PM, Cullen Jennings wrote: >=20 > We are still trying to pick a time to have an Virtual Interim meeting for= the IETF RTCWeb WG on the topic of SDP Security Descriptions (RFC 4568 aka= SDES). The goal is not to make a decision about this but the goal is to ge= t everyone understanding the pros and cons of all the options.=20 >=20 > The proposed length of the meeting is 2.5 hours. >=20 > Please fill out the doodle at by the end of the day on May 22=20 >=20 > http://www.doodle.com/22qy6vcpre4vqex6 >=20 > Thanks, The chairs ... >=20 >=20 > On May 9, 2013, at 9:39 AM, Ted Hardie wrote: >=20 >> Howdy, >>=20 >> Given the MMUSIC working group virtual interim is now scheduled for May = 23rd, the RTCWEB chairs plan to push back the SDES-focused virtual interim = we'd previously announced, so that folks can focus on the Plan A and Plan B= discussion to happen there. =20 >>=20 >> We will put out a new doodle poll early next week with dates in June. T= he current plan is that the virtual interim will include discussion of the = base security properties, EKT, and some of the other issues which have come= up in working group discussion. >>=20 >> regards, >>=20 >> Ted, Cullen, and Magnus >> _______________________________________________ >> 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From worley@shell01.TheWorld.com Fri May 17 13:19:15 2013 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 E146621F95E9 for ; Fri, 17 May 2013 13:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDbZlWjXp6-f for ; Fri, 17 May 2013 13:19:10 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 09DF121F95DB for ; Fri, 17 May 2013 13:19:09 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4HKIwPA015415; Fri, 17 May 2013 16:19:01 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4HKIwnu4969298; Fri, 17 May 2013 16:18:58 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4HKIwPN4974003; Fri, 17 May 2013 16:18:58 -0400 (EDT) Date: Fri, 17 May 2013 16:18:58 -0400 (EDT) Message-Id: <201305172018.r4HKIwPN4974003@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Emil Ivov In-reply-to: <51965506.7050008@jitsi.org> (emcho@jitsi.org) References: <51965506.7050008@jitsi.org> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 20:19:16 -0000 > From: Emil Ivov > > Both plan A and B currently describe semantics that would require O/A > exchanges every time a source is added or removed from a session. > [...] > Does any of this make any sense? My understanding (and I'm not tracking everything carefully) is that this is a bad situation. I've been accumulating desiderata, and one that has been on the list for a long time is: DES F11 It must be possible to add and remove one way video flows within the bundle without requiring an additional offer/answer cycle. Do people think that this is not important? Dale From bernard_aboba@hotmail.com Fri May 17 13:21:56 2013 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 68B5321F95E9 for ; Fri, 17 May 2013 13:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azq4yycIvXdE for ; Fri, 17 May 2013 13:21:51 -0700 (PDT) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF121F9488 for ; Fri, 17 May 2013 13:21:51 -0700 (PDT) Received: from BLU403-EAS403 ([65.55.116.74]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 13:21:50 -0700 X-EIP: [5WDRjKeICn4Q7hIcoq/FEI/SIRRv7anu] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Fri, 17 May 2013 13:21:47 -0700 From: Bernard Aboba To: "Dale R. Worley" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 17 May 2013 20:21:50.0941 (UTC) FILETIME=[2A13D8D0:01CE533C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 20:21:56 -0000 It is important. In fact=2C I would argue it is critical for congestion con= trol (e.g. removal of simulcast or layered streams by the sender should not= require an O/A exchange). "Dale R. Worley" wrote: > From: Emil Ivov > > Both plan A and B currently describe semantics that would require O/A > exchanges every time a source is added or removed from a session. > [...] > Does any of this make any sense? My understanding (and I'm not tracking everything carefully) is that this is a bad situation. I've been accumulating desiderata=2C and one that has been on the list for a long time is: DES F11 It must be possible to add and remove one way video flows within the bundle without requiring an additional offer/answer cycle. Do people think that this is not important? Dale _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri May 17 13:50:22 2013 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 D7A0421F898B for ; Fri, 17 May 2013 13:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.156 X-Spam-Level: X-Spam-Status: No, score=-4.156 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0r09mcdbANM for ; Fri, 17 May 2013 13:50:16 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76F21F968E for ; Fri, 17 May 2013 13:50:11 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so4862377lbd.34 for ; Fri, 17 May 2013 13:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aK4SJFi6hWHpCOsMZlqxQgfhgYXhw5rkTBbYcpg7iwo=; b=0+WuhWWH1ako3dZTxKD3PDN3eXSzQiwCdO+N88E1Iycqb70OldeNkcdQ4nqfYkI7dS UgNH8K7wNZ1n0CGJauKDmVPwt9D4EytdKjR/F78lVi1XWv2kXdV/NtYsR/Ln2Ya+jhAo 4AA1fus5zMOJBrkLzIuiGlUUGJjtQGFgZr6VGr8zgWEHudYyAvh5aDFVJDLbZnRe2Li8 LZ+aHr7uBEyPlo5B/O+iZb9WUqTyJEk9hj8Wo7ofcutIuAzYNpxyLHoq/dERc5uDBlkL z34UWRz/sW8s+Wbc0Ge6McD6aYqXunKXqpanq5PEDiKvv+UakMiHGJYMOR1ZRILXTROn 936A== MIME-Version: 1.0 X-Received: by 10.152.26.166 with SMTP id m6mr23747330lag.50.1368823810582; Fri, 17 May 2013 13:50:10 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Fri, 17 May 2013 13:50:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 May 2013 13:50:10 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 20:50:22 -0000 > "Dale R. Worley" wrote: > DES F11 It must be possible to add and remove one way video flows > within the bundle without requiring an additional offer/answer > cycle. I'm not sure why this speaks specifically about video... On 17 May 2013 13:21, Bernard Aboba wrote: > It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange). This is different I think. Responding to congestion only requires that it be possible to stop sending a given stream. (Or maybe crank down resolution or frame rate.) This item talks about addition. That's an entirely different proposition. As long as we assume constraints (you don't need to re-ICE a new transport for the stream, you don't use new packet types and codec profiles), this could be possible. But to get WebRTC to support this requires API changes. From ron.even.tlv@gmail.com Fri May 17 15:34:18 2013 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 A155B21F9661 for ; Fri, 17 May 2013 15:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz3+9f6BmZNO for ; Fri, 17 May 2013 15:34:14 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3421F92EB for ; Fri, 17 May 2013 15:34:13 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id e51so2814727eek.38 for ; Fri, 17 May 2013 15:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=L3J4Wh+jn3qzBStuuMtqqehTw5xGUC9TXQ2/MYmn+dA=; b=RQyanQOdFr2+qz2P9JUpcwzRBPTFAS79AnXbhq2lVanhZ9+B2W0v/X1CCSYcHg5PSh 3mgyW7YC7oH/sq4zHwxXVjU8S5KAXLYeKpIPoinO0bDMGQv5+17WIQpZltb2ALGBvsU+ Jubkd37FySrLnwOShQxsdOUDLFgF4NGJ1f6t6HrvVS2/8AoJirr5bKHtaTyMylAB2k9/ quoa/kvtfqZI4ybD6VG3IG6jJwrFBpsDCXXFtNP7jEoG4c4X9mG+4CYJsM5qWktgG4r8 l4stzhMnA0I0CzA1tATdhNTN37f9jkhTI86yJVI2pcb35FvwhtvWdKZ8LQPJG1A9Bc8k Zt2Q== X-Received: by 10.15.23.69 with SMTP id g45mr134430405eeu.25.1368830052770; Fri, 17 May 2013 15:34:12 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id n7sm22161876eeo.0.2013.05.17.15.34.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 May 2013 15:34:11 -0700 (PDT) From: "Roni Even" To: "'Bernard Aboba'" , "'Dale R. Worley'" References: In-Reply-To: Date: Sat, 18 May 2013 01:33:12 +0300 Message-ID: <000001ce534e$86180a40$92481ec0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDc7dRjg5sEw9AeSWqkQr4B3rwpDprswDxA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 22:34:18 -0000 I agree that it is important and I that it is a reason to look at http://tools.ietf.org/html/draft-westerlund-mmusic-max-ssrc-01 for adding RTP steams without having to signal the SSRC in the SDP while using RTCP or RTP headers for mapping the new streams. Roni -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 17 May, 2013 11:22 PM To: Dale R. Worley Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange). "Dale R. Worley" wrote: > From: Emil Ivov > > Both plan A and B currently describe semantics that would require O/A > exchanges every time a source is added or removed from a session. > [...] > Does any of this make any sense? My understanding (and I'm not tracking everything carefully) is that this is a bad situation. I've been accumulating desiderata, and one that has been on the list for a long time is: DES F11 It must be possible to add and remove one way video flows within the bundle without requiring an additional offer/answer cycle. Do people think that this is not important? Dale _______________________________________________ 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 stefan.lk.hakansson@ericsson.com Sun May 19 04:28:58 2013 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 5108121F8749 for ; Sun, 19 May 2013 04:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.455 X-Spam-Level: X-Spam-Status: No, score=-5.455 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aucASaPdXCKt for ; Sun, 19 May 2013 04:28:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6321F855A for ; Sun, 19 May 2013 04:28:50 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-2e-5198b771ad7a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D9.DE.31782.177B8915; Sun, 19 May 2013 13:28:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 19 May 2013 13:28:49 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUxg7vVOdWtOdCUWaMjkjMpyI8A== Date: Sun, 19 May 2013 11:28:48 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEAC@ESESSMB209.ericsson.se> References: <51965506.7050008@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrW7h9hmBBjf2GFqs2TmBxWLtv3Z2 ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlbFnxSvWgn2yFbN737I2MN4Q72Lk5JAQMJHY eP0WK4QtJnHh3nq2LkYuDiGBw4wSr38eZgdJCAksYZRYvNYcxGYTCJTYum8BG4gtIiAv0d22 iAnEZhZQl7iz+BxYvbCAocTT+/9ZIWqMJK6t388CYetJtJ25D1bDIqAq8WzPfGYQm1fAV+LF 0x+MELs0JA68+Q7Wywh00PdTa6Dmi0vcejKfCeJQAYkle84zQ9iiEi8f/4N6QEnix4ZLLBD1 ehI3pk5hg7C1JZYtfA21S1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15utIkR GAkHt/xW3cF455zIIUZpDhYlcd5e7amBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgtLULa Gh8IdodfvaZe265Wu+fzbcfJO520dT3eZ/2t1Zih9eK19ZXnMnvPfBfrF7/65kP2kXSW+q49 cYy8Z3+6nGhRmcyf8XzJqrB5LwSa/vLld63ir4pdYsoyN7Gw/fy54PgD3QHOWYv+CfA4hL04 /TRL+0utpVrGzfJpwlN7HO+u2T+lqkmJpTgj0VCLuag4EQBkBYkgUgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2013 11:28:58 -0000 On 5/17/13 6:04 PM, Emil Ivov wrote:=0A= > I've mentioned this in a couple of other threads but I think it's=0A= > important so I am also posting it separately.=0A= >=0A= > Both plan A and B currently describe semantics that would require O/A=0A= > exchanges every time a source is added or removed from a session.=0A= >=0A= > Whether it is about adding a second webcam, or a conference participant= =0A= > that leaves or joins, both schemes suggest that the remote party should= =0A= > be notified with an updated SDP.=0A= >=0A= > Plan A deals with this by manipulating m=3D lines, while plan B does it= =0A= > with msid-s.=0A= >=0A= > We are nowhere near consensus and I think that this fact alone is a=0A= > strong argument in favour of the following:=0A= >=0A= > This is not a problem for rtcweb to solve.=0A= >=0A= > We all have our own preferences for a solution and those come from the=0A= > different use cases we are planning on addressing and the different apps= =0A= > we are planning to build. The promise of WebRTC is that, by building on= =0A= > the Web paradigm we would provide building blocks which can then be=0A= > assembled into specific solutions (rather than providing the solutions=0A= > themselves).=0A= >=0A= > In other words: it is not our job to try and implant a signalling=0A= > protocol into O/A. Signalling is the job of the application.=0A= >=0A= > Applications alone know the meaning of the stream that came from your=0A= > second web cam, or that of the tenth conference participant. They know=0A= > which conferencing topology they most care about. They have best=0A= > knowledge about what streams they are currently rendering and which ones= =0A= > they don't need. They know that the names Adam and Justin should be=0A= > displayed to describe the streams they are currently getting.=0A= >=0A= > Most importantly however: they are best placed to know how they'd like=0A= > to communicate that information to their peers or IF they need to=0A= > communicate it at all.=0A= >=0A= > Currently neither Plan A nor Plan B would let the application do its=0A= > job. However I do believe Plan B is closer.=0A= >=0A= > If we agree that browsers would give applications the latitude that's=0A= > necessary to address these issues with app specific signalling, then the= =0A= > SDP shouldn't change when they are doing it. Plan B is almost there and= =0A= > the only remaining problem is its insistence on the pre-announcement of= =0A= > SSRCs.=0A= >=0A= > If we get rid of that requirement then all we need would be for the W3C= =0A= > to make sure that the APIs have everything they need to allow apps to=0A= > retrieve SSRC information, send it remotely then pass it down to the=0A= > browser again when they receive it.=0A= >=0A= > I acknowledge that the simulcasting and FEC cases might be a bit=0A= > different, which is normal because they are about the resolution of=0A= > transport problems. I still think they could be solved with app-specific= =0A= > signalling and the proper APIs but in this case it would also be worth=0A= > investigating the options of doing this through RTP/RTCP.=0A= >=0A= > Does any of this make any sense?=0A= =0A= There is a lot of sense AFAICU, but there are two things to point out:=0A= * There should be a standardized way for the receiver to say it can't =0A= handle (parts of) the media the senders wants to send. Someone proposed =0A= the max-ssrc draft=0A= * There have been discussions about that there should be a standardized =0A= way for the receiving app to reject - via an api - parts of what the =0A= sending app wants to send=0A= =0A= offer+answer helps with the above.=0A= =0A= >=0A= > Emil=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Sun May 19 04:35:54 2013 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 8E72821F8D7A for ; Sun, 19 May 2013 04:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.692 X-Spam-Level: X-Spam-Status: No, score=-4.692 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcKR31IadEup for ; Sun, 19 May 2013 04:35:49 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BABF921F8D31 for ; Sun, 19 May 2013 04:35:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-df-5198b913e5c7 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 73.3D.28930.319B8915; Sun, 19 May 2013 13:35:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 19 May 2013 13:35:47 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Emil Ivov Thread-Topic: Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) Thread-Index: AQHOUNuv7sx/DKV64Ei4hdgR8OpAYQ== Date: Sun, 19 May 2013 11:35:46 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEE8@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra7wzhmBBttPKVqs2TmBxWLtv3Z2 ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlXH57A2mgj/aFVumqzUwzlHuYuTkkBAwkbg2 eQcThC0mceHeerYuRi4OIYHDjBLnXy5lhnCWMEp8WX6VFaSKTSBQYuu+BWwgtoiAvER32yKw bmYBdYk7i8+xgzQIC8xhlPi1dxUjiCMiMJdRYt+St1AdehJTtq5gBrFZBFQlep6dZQGxeQV8 JbZ8nsEIsa6fXaJxZQNYghHoqO+n1kCtEJe49WQ+1LECEkv2nGeGsEUlXj7+xwphK0k0LnnC ClGvJ3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl hpsYgfFwcMtv3R2Mp86JHGKU5mBREuft1Z4aKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR cfk/xUNnS/JiTNS5vp4VMP/BOb18VoTmTLk0Pd8lZ//Yf3b63qMQus2V+8jVw+IWK43eJwrd /qYTO+P6aoktNlfEFz1IS9k2TfF52hlfbaWerQVRS1LbXIuq7k0uOHnS4ID+uuO8266VLZP7 nD3z+j6jaxcWTj3A+3nBs502uzas7r13mGGlkxJLcUaioRZzUXEiAFmjlntVAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2013 11:35:54 -0000 On 5/16/13 9:22 PM, Emil Ivov wrote:=0A= >=0A= >=0A= > On 16.05.13, 12:45, Stefan H=E5kansson LK wrote:=0A= >> On 5/14/13 9:46 PM, Emil Ivov wrote:=0A= >>> Hey Stefan,=0A= >>>=0A= >>> On 14.05.13, 14:44, Stefan H=E5kansson LK wrote:=0A= >>>>>> SSRCs - this would be SDP=0A= >>>>>=0A= >>>>> Again, including SSRCs in SDP O/A is tricky in conferencing scenarios= .=0A= >>>>=0A= >>>> Here seems to be something that I have missed. That there are existing= =0A= >>>> implementations that do not signal SSRC is fine, and in most cases the= re=0A= >>>> would be only one audio and one video SSRC used anyway. And rtcweb (an= d=0A= >>>> Clue?) should be able to interoperate (but perhaps your web app need t= o=0A= >>>> be designed in a specific way).=0A= >>>>=0A= >>>> But if we design something forward looking, that can handle many=0A= >>>> streams, that can handle layered codecs and FEC data, signaling SSRCs= =0A= >>>> seems like a must to me.=0A= >>>>=0A= >>>> But I have missed that this is problematic in conferencing scenarios,= =0A= >>>> could you tell me why (and I probably should know :) )?=0A= >>>=0A= >>> The issue that I am referring to (I describe this in an earlier mail to= =0A= >>> Harald here http://goo.gl/M8NbQ ) is that of a conference based on an= =0A= >>> RTP translator. It's basically what we do in Jitsi Videobridge.=0A= >>>=0A= >>> Let's say that I am a WebRTC app that can act as a conference focus and= =0A= >>> that has access to an RTP translator somewhere. I'd like to organise a= =0A= >>> conference with 10 people (you and I among them).=0A= >>>=0A= >>> I ask the RTP translator to allocate 10 ports for me and then I start= =0A= >>> calling participants.=0A= >>>=0A= >>> You are the first one that I am going to join into this new call.=0A= >>>=0A= >>> At this point, the only SSRC(s) that I could possibly give you are thos= e=0A= >>> that I am going to use. I won't be able to tell you anything for the=0A= >>> eight other participants. For all I know, some or all of these=0A= >>> participants could turn out to be RTP translators themselves and there= =0A= >>> could be a number of SSRCs behind each of them too.=0A= >>>=0A= >>> The very logical and easy thing that your webapp could do here is not t= o=0A= >>> care and simply render each and every SSRC that you get. Most apps are= =0A= >>> going to be perfectly happy with that.=0A= >>>=0A= >>> If, on the other hand you needed me to re-offer you every time a new=0A= >>> participant joins in order to work properly, then things would easily= =0A= >>> get quite messy even if everyone is using WebRTC.=0A= >>>=0A= >>> Then, note that some of the participants can be simple SIP endpoints=0A= >>> (that's why we bothered with SDP in the first place right?) so the only= =0A= >>> way I can get their SSRCs is with some extra signalling between me and= =0A= >>> the RTP translator. This is not a problem per se, but it can only happe= n=0A= >>> after the SIP participants have joined the call and started streaming= =0A= >>> data, that has reached the translator. And even then they will have no= =0A= >>> MSIDs.=0A= >>>=0A= >>> All in all, we would be enforcing some very laborious signalling when= =0A= >>> it is absolutely unnecessary.=0A= >>=0A= >> Thanks, I then understand the use-case you're envisioning.=0A= >>=0A= >> I think it could work under certain conditions, but as soon as there are= =0A= >> repair flows, enhancement layers or simulcast involved, there is a need= =0A= >> anyway to somehow signal what each SSRC represents.=0A= >=0A= > I don't think anyone is arguing against this.=0A= >=0A= >> Then it is another=0A= >> question if it happens via SDP or via RTP header extensions or some=0A= >> other means.=0A= >>=0A= >> There was a discussion at the Stockholm rtcweb interim on what=0A= >> topologies that would be supported, but I fail to remember if this case= =0A= >> was included or excluded.=0A= >=0A= > I couldn't find the discussion (in what WG did it happen?) but=0A= > topologies based on RTP translators of one sort or another seem to be=0A= > the default way of handling video conferencing these days so I don't see= =0A= > how we could possibly rule them out.=0A= =0A= It was at the rtcweb interim in Stockholm last June (but I don't =0A= remember the details of the outcome of the discussion).=0A= =0A= I'm no expert, but how do you handle things like congestion management =0A= with translators? IIUC the RMCAT group has decided to handle the simple =0A= point-point case only. (I'm not trying to remove translators from the =0A= topologies we cover - I just want to bring all the pieces to the table).=0A= =0A= >=0A= >> It also seems to me that people have quite different views in the=0A= >> discussion.=0A= >=0A= > Of course, where would the fun be otherwise? :)=0A= >=0A= >> One view seems to be that SDP exchanges should be used even=0A= >> for things like pause/resume, resolution changes,=0A= >=0A= > Right! That's the wrong view ;). We made two important choices in this=0A= > working group:=0A= >=0A= > a) we will not impose a signalling protocol, and=0A= > b) we will use SDP O/A to make it easier to talk to legacy apps/devices.= =0A= >=0A= > Let's not try to compensate for the former by hijacking the latter.=0A= >=0A= >> another that we should=0A= >> avoid SDP exchanges even when people join/leave a conference.=0A= >=0A= > Even? I'd argue that this is _the_ place where avoiding SDP O/A is most= =0A= > important!=0A= >=0A= > Emil=0A= >=0A= =0A= From ggb@tokbox.com Sun May 19 23:20:55 2013 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 32B7621F8FFC for ; Sun, 19 May 2013 23:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhnYQqfW+-uX for ; Sun, 19 May 2013 23:20:49 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 8700921F8FE5 for ; Sun, 19 May 2013 23:20:49 -0700 (PDT) Received: from mail-pd0-f175.google.com ([209.85.192.175]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUZnAv+/bemdl/XlGHSuuKBkQ3vdeKctT@postini.com; Sun, 19 May 2013 23:20:49 PDT Received: by mail-pd0-f175.google.com with SMTP id y14so5094707pdi.20 for ; Sun, 19 May 2013 23:20:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=MEEnF9UQJaddOPR545NYv3a4ivMh/sm93NYqgTI5ADI=; b=YRzKX8ezf4esPL4Ag9pRKONof7tdPatDnNaxwM1oeaGYoVb68/xTe0wvX4qfbaywn1 TPzU+zpA190Zi32f3XQqzppIYmA1QvoI6baA0LcQMK9XevBvSAb9xjEqO//C7Do+ds9D TDLTifwVNzUDuX7ijpDQbmIeAyzGfhBeTdR9SElJDpJEaiUzm19FHKLbZiQTpC2QG5J4 Kn5cldY/BAmOfCFwomRKQeZKik1rcX+4wjozvC4KZ92+lp2z8xvj4GxDwEv8OU6yyM/g RvbOi9cvoYz0bdEaZ9uWMGBtqTadog1eqfxW3RCPozoHvhrh3WG3I23zqK4Q0yIFGeTf 4TsA== X-Received: by 10.68.204.35 with SMTP id kv3mr59429622pbc.87.1369030847004; Sun, 19 May 2013 23:20:47 -0700 (PDT) X-Received: by 10.68.204.35 with SMTP id kv3mr59429616pbc.87.1369030846920; Sun, 19 May 2013 23:20:46 -0700 (PDT) Received: from [192.168.10.222] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id wi6sm22724942pbc.22.2013.05.19.23.20.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 23:20:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> Date: Sun, 19 May 2013 23:20:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlM97rCKCb1Fmwb7KgyT+foQrQREQkgMCTf98Gv4e6rIhdxM4CY8J6y1UaERCAA6GmXvL8UtHjTrbrjxl92RbA5i+BmS+auVtdQhmZwVXAvH2O9a2DzQgWCmxR2jDrTgp0R2ACRCR1EGM1hXMmb2HuDN0s2IQ== Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 06:20:55 -0000 I agree that TURN over websockets doesn't solve much more scenarios than = TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over = HTTP that aside of philosophical discussions would be the solution with = better success rate? Otherwise we will have to continue answering for = another 10 years "why is this app not working if skype does". Something like this draft sent some months ago but perhaps for TURN = instead of direct connections: http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt On 16/05/2013, at 01:28, Hutton, Andrew wrote: > I agree with Bernard's comments regarding the impact of DPI but of = course such DPI devices do what they do and we can't and even don't want = to stop them from doing it. However for the case when policy is such = that the firewall will only allow traffic to traverse that comes from = the HTTP Proxy or a network specific TURN server and there is no = deliberate policy to block WebRTC media we need a solution and this is = what draft-hutton-rtcweb-nat-firewall-considerations-00 addresses. >=20 > So far I don't see the benefit that TURN over websockets would have in = this scenario and it needs additional implementation in the browser and = the TURN server. >=20 > Regards > Andy >=20 >=20 >> -----Original Message----- >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >> Sent: 15 May 2013 18:20 >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org >> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >>=20 >> Andrew Hutton said: >>> When we wrote the draft http://tools.ietf.org/html/draft-hutton- >> rtcweb-nat-firewall-considerations-00 we did not include this option >> because we did not see the benefit of additional transport options = for >> TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) = seem >> to be meet our needs. >>>=20 >>> So what would be the benefits that justify this addition transport >> option for TURN? >>=20 >> [BA] In my experience, institutions with very restrictive security >> policies (e.g. those that don't allow UDP in or out) also tend to >> deploy other measures such as deep packet inspection. So just = because >> some traffic is allowed in or out on port 80 does not mean that >> TURN/TCP will be allowed on that port - a DPI box may examine the >> traffic and complain if it doesn't see HTTP being used. On the other >> hand, unless the DPI box is upgraded, it will also complain about >> websockets. So I think draft-chenxin only helps in a situation where >> TURN over Websockets would be allowed when TURN/TCP would not be. = That >> scenario is rare, at least at the moment. >>=20 >> The argument for TURN over Websocket/TLS is even more difficult to >> make. While DPI boxes may examine traffic destined to port 443 >> carefully to make sure that TLS is really being used, assuming that >> the DPI box does not see anything it considers fishy, the TLS = exchange >> will complete and the DPI box will lose visibility. After TLS is >> running, the DPI box does not have much information available to >> distinguish TURN/TLS from HTTP over TLS, with or without websockets = -- >> and those things it does have (such as packet size) are as likely to >> result in an objection to websocket transport as TURN/TLS. So I'm = not >> sure that draft-chenxin will help in that situation either. >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sun May 19 23:48:36 2013 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 50CD021F85F4 for ; Sun, 19 May 2013 23:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4w2LjkpKoop for ; Sun, 19 May 2013 23:48:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A363721F9057 for ; Sun, 19 May 2013 23:48:12 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-a3-5199c72a3997 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FA.ED.31782.A27C9915; Mon, 20 May 2013 08:48:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Mon, 20 May 2013 08:48:10 +0200 From: Christer Holmberg To: Martin Thomson , Bernard Aboba Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkJuD4AgAPsAUA= Date: Mon, 20 May 2013 06:48:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C373EF0@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvra728ZmBBj+ucljsX3KZ2eLamX+M Fmv/tbM7MHvsnHWX3eNxzxk2jyVLfjIFMEdx2aSk5mSWpRbp2yVwZSxsXsVYcJKn4v+2r8wN jBO4uhg5OCQETCTW7mTsYuQEMsUkLtxbzwZiCwkcZpSYuiuvi5ELyF7CKHHz4kJWkHo2AQuJ 7n/aIDUiAlESpye2soPYzALqEncWnwOzhQUMJX5fOMUMUWMkcW39fhYI20riy4dJTCA2i4Cq xNRfD1lBbF4BX4nuD59YIHY1M0rcmH4a7CBOgUCJ7advgdmMQMd9P7WGCWKZuMStJ/OZII4W kFiy5zwzhC0q8fLxP1aIvxQllvfLQZTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOos JC2zkLTMQtKygJFlFSN7bmJmTnq50SZGYMwc3PJbdQfjnXMihxilOViUxHl7tacGCgmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamCUXSDYnbXA0qxjZbrB4pwupljTP2rv3mdEes87Er69dPrz /Hmy3w7x18akOMUmHm+8G7nqXBRDjeekhIc9P4+oVH6xLeO5UjY7yWhereWDN2ur+nwflIXX KDJ/2zb34lxHf4lb232NUrRjDi66dcrSNfGb9HkdpRlK7LWSNxw2pNff0/i2QV6JpTgj0VCL uag4EQBCoaSfZwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 06:48:37 -0000 Hi, I don't think it's a BUNDLE issue whether adding/removing of streams requir= e an O/A exchange or not. It's an SDP, and SDP O/A, issue. BUNDLE is about sharing a 5-tuple. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Martin Thomson Sent: 17. toukokuuta 2013 23:50 To: Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B > "Dale R. Worley" wrote: > DES F11 It must be possible to add and remove one way video flows > within the bundle without requiring an additional offer/answer > cycle. I'm not sure why this speaks specifically about video... On 17 May 2013 13:21, Bernard Aboba wrote: > It is important. In fact, I would argue it is critical for congestion con= trol (e.g. removal of simulcast or layered streams by the sender should not= require an O/A exchange). This is different I think. Responding to congestion only requires that it = be possible to stop sending a given stream. (Or maybe crank down resolutio= n or frame rate.) This item talks about addition. That's an entirely different proposition. = As long as we assume constraints (you don't need to re-ICE a new transport= for the stream, you don't use new packet types and codec profiles), this c= ould be possible. But to get WebRTC to support this requires API changes. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sun May 19 23:51:18 2013 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 A63D621F905B for ; Sun, 19 May 2013 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnnh1nLiXWG5 for ; Sun, 19 May 2013 23:51:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDAA11E80A5 for ; Sun, 19 May 2013 23:50:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-03-5199c7c112d7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EF.8C.28930.1C7C9915; Mon, 20 May 2013 08:50:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Mon, 20 May 2013 08:50:41 +0200 From: Christer Holmberg To: Emil Ivov , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUxg7Crd1S7QwyEqM9DOrRHv1xJkNpi/Q Date: Mon, 20 May 2013 06:50:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C373F07@ESESSMB209.ericsson.se> References: <51965506.7050008@jitsi.org> In-Reply-To: <51965506.7050008@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre6h4zMDDSa8Z7NYs3MCi8Xaf+3s DkweS5b8ZPL4/yYwgCmKyyYlNSezLLVI3y6BK2Pd16dMBZOkKz6uuMfcwHhXtIuRk0NCwESi YfpEJghbTOLCvfVsXYxcHEIChxklprVvZYdwljBKbH42hbmLkYODTcBCovufNkiDiICLxPn1 P9hBbGEBQ4nfF04xQ8SNJK6t388CY58+eheshkVAVeL6h9dgNq+Ar8SaVU2MILaQgIbEgTff WUFsTgFNiceTb7KB2IxAB30/tQbsOGYBcYlbT+ZDHSogsWTPeWYIW1Ti5eN/rCCnSQgoSizv l4Mo15FYsPsTG4StLbFs4WtmiLWCEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEjyypG9tzEzJz0 csNNjMA4OLjlt+4OxlPnRA4xSnOwKInz9mpPDRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA mGpTf/fXQ3mdK+0rM6urW7Tu3Vlh3znlr6aqea/mrPelh0xmTGuf9Wvy3D6viX/m8ZZn5n5Y M8WRQy4s6uju+m0HZDgmCIgJTQln+KaU3+XJOuXeFZEXFx1zuiTmpO84NH9r21nN/FbNw5wR lxlY9utsz3t9ejdDy3TtOlN+55l5ARcuTH5Ro8RSnJFoqMVcVJwIANbs5yVRAgAA Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 06:51:20 -0000 Hi Emil, I agree that the signaling protocol is outside the scope of this group. However, as SDP O/A is also used within the API, it becomes an issue for th= is group :) Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Emil Ivov Sent: 17. toukokuuta 2013 19:04 To: rtcweb@ietf.org Subject: [rtcweb] A problem with both A and B I've mentioned this in a couple of other threads but I think it's important= so I am also posting it separately. Both plan A and B currently describe semantics that would require O/A excha= nges every time a source is added or removed from a session. Whether it is about adding a second webcam, or a conference participant tha= t leaves or joins, both schemes suggest that the remote party should be not= ified with an updated SDP. Plan A deals with this by manipulating m=3D lines, while plan B does it wit= h msid-s. We are nowhere near consensus and I think that this fact alone is a strong = argument in favour of the following: This is not a problem for rtcweb to solve. We all have our own preferences for a solution and those come from the diff= erent use cases we are planning on addressing and the different apps we are= planning to build. The promise of WebRTC is that, by building on the Web p= aradigm we would provide building blocks which can then be assembled into s= pecific solutions (rather than providing the solutions themselves). In other words: it is not our job to try and implant a signalling protocol = into O/A. Signalling is the job of the application. Applications alone know the meaning of the stream that came from your secon= d web cam, or that of the tenth conference participant. They know which con= ferencing topology they most care about. They have best knowledge about wha= t streams they are currently rendering and which ones they don't need. They= know that the names Adam and Justin should be displayed to describe the st= reams they are currently getting. Most importantly however: they are best placed to know how they'd like to c= ommunicate that information to their peers or IF they need to communicate i= t at all. Currently neither Plan A nor Plan B would let the application do its job. H= owever I do believe Plan B is closer. If we agree that browsers would give applications the latitude that's neces= sary to address these issues with app specific signalling, then the SDP sho= uldn't change when they are doing it. Plan B is almost there and the only r= emaining problem is its insistence on the pre-announcement of SSRCs. If we get rid of that requirement then all we need would be for the W3C to = make sure that the APIs have everything they need to allow apps to retrieve= SSRC information, send it remotely then pass it down to the browser again = when they receive it. I acknowledge that the simulcasting and FEC cases might be a bit different,= which is normal because they are about the resolution of transport problem= s. I still think they could be solved with app-specific signalling and the = proper APIs but in this case it would also be worth investigating the optio= ns of doing this through RTP/RTCP. Does any of this make any sense? Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Mon May 20 02:00:06 2013 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 5E96921F843F for ; Mon, 20 May 2013 02:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5mYNwuNmYKt for ; Mon, 20 May 2013 02:00:05 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC721F8443 for ; Mon, 20 May 2013 01:29:54 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg1so1117493bkc.20 for ; Mon, 20 May 2013 01:29:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=o4PK9VFbcOxkcZMXmYapS/nSHHyBHZAZ9aVwNvuOHsE=; b=CSFJi5YW2Lv3FFp24C5TLW2NCW+uPaTGm9FF2KCRSrE+oSA9HKC/HOoskUNBMS95dh VOfbiU4NUORGBW0cwnbesg79PKNG8AlInFmuhL5ySGV9dxrgWv018HGd8136cxN15brT iFulvZeEOm0lRJA1PVeij8c2HSUv8B0ivlbX+KW531Vzk0jhq1QF7tsdVROn45+n51uu rXSvAxbUZJA3ZVJLqsXA7I1CP1k8+MTnYbxNVxPJqaUiwwtft6igxBcQ+o3Mz1WfAQZN DCRjmhrJyq9rfudTqm6N9I/UhofHyG5w39TwaOkZ5ntUgP8SRatzKnKlUNyha+siEbdk JzzQ== X-Received: by 10.204.228.79 with SMTP id jd15mr18591621bkb.42.1369038562436; Mon, 20 May 2013 01:29:22 -0700 (PDT) Received: from camionet.local (77-85-165-231.btc-net.bg. [77.85.165.231]) by mx.google.com with ESMTPSA id f14sm5446168bky.16.2013.05.20.01.29.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 01:29:21 -0700 (PDT) Message-ID: <5199DEDE.2090207@jitsi.org> Date: Mon, 20 May 2013 11:29:18 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51965506.7050008@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEAC@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEAC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn/5Pl9dnN6mwsMWMVTpvXIoyKnRoRYrflKJchMd/lk4omDYvpG+h3QDvuyPBATX3QPqDo3 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:00:06 -0000 On 19.05.13, 14:28, Stefan H=E5kansson LK wrote: > On 5/17/13 6:04 PM, Emil Ivov wrote: >> I've mentioned this in a couple of other threads but I think it's >> important so I am also posting it separately. >> >> Both plan A and B currently describe semantics that would require O/A >> exchanges every time a source is added or removed from a session. >> >> Whether it is about adding a second webcam, or a conference participan= t >> that leaves or joins, both schemes suggest that the remote party shoul= d >> be notified with an updated SDP. >> >> Plan A deals with this by manipulating m=3D lines, while plan B does i= t >> with msid-s. >> >> We are nowhere near consensus and I think that this fact alone is a >> strong argument in favour of the following: >> >> This is not a problem for rtcweb to solve. >> >> We all have our own preferences for a solution and those come from the= >> different use cases we are planning on addressing and the different ap= ps >> we are planning to build. The promise of WebRTC is that, by building o= n >> the Web paradigm we would provide building blocks which can then be >> assembled into specific solutions (rather than providing the solutions= >> themselves). >> >> In other words: it is not our job to try and implant a signalling >> protocol into O/A. Signalling is the job of the application. >> >> Applications alone know the meaning of the stream that came from your >> second web cam, or that of the tenth conference participant. They know= >> which conferencing topology they most care about. They have best >> knowledge about what streams they are currently rendering and which on= es >> they don't need. They know that the names Adam and Justin should be >> displayed to describe the streams they are currently getting. >> >> Most importantly however: they are best placed to know how they'd like= >> to communicate that information to their peers or IF they need to >> communicate it at all. >> >> Currently neither Plan A nor Plan B would let the application do its >> job. However I do believe Plan B is closer. >> >> If we agree that browsers would give applications the latitude that's >> necessary to address these issues with app specific signalling, then t= he >> SDP shouldn't change when they are doing it. Plan B is almost there an= d >> the only remaining problem is its insistence on the pre-announcement o= f >> SSRCs. >> >> If we get rid of that requirement then all we need would be for the W3= C >> to make sure that the APIs have everything they need to allow apps to >> retrieve SSRC information, send it remotely then pass it down to the >> browser again when they receive it. >> >> I acknowledge that the simulcasting and FEC cases might be a bit >> different, which is normal because they are about the resolution of >> transport problems. I still think they could be solved with app-specif= ic >> signalling and the proper APIs but in this case it would also be worth= >> investigating the options of doing this through RTP/RTCP. >> >> Does any of this make any sense? >=20 > There is a lot of sense AFAICU, but there are two things to point out: > * There should be a standardized way for the receiver to say it can't=20 > handle (parts of) the media the senders wants to send. Someone proposed= =20 > the max-ssrc draft Certainly. I am not arguing against use of max-ssrc. Quite on the contrar= y. > * There have been discussions about that there should be a standardized= =20 > way for the receiving app to reject - via an api - parts of what the=20 > sending app wants to send Well, perhaps we need to have these discussions again. If the browser can't handle H.264 it makes perfect sense to refuse that in SDP. Indicating a maximum supported resolution of 720p also seems fine. However, if the receiving application wants to tell the sending application that it would like to reject certain streams, that's up to the applications to signal. > offer+answer helps with the above. I think one look at the discussions that are taking place on this list is enough to see that this is exactly where Offer/Answer isn't helping. Emil --=20 https://jitsi.org From emil@sip-communicator.org Mon May 20 02:00:09 2013 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 A5CA321F901B for ; Mon, 20 May 2013 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2pEe4F7Xx+l for ; Mon, 20 May 2013 02:00:07 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4421F8437 for ; Mon, 20 May 2013 01:31:00 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it19so2719351bkc.41 for ; Mon, 20 May 2013 01:30:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Jk+UyE8QvK7CWkT3IHBhHCxpWKh5KwLaFo3bszQ8ExM=; b=jixsySDcFu+6vRRpejAPqDRFEehgg8W9sWRmLXJXHCG+A37bAR5UAGPSOeP30HM3+q dJ44QuFzRMa23r//VweyYfEIp3UbIewwZrEfhYur0UPEhsZ5VIFcVVqgNBa7gqza5GMP m1nSI7X0MpZMb2crhW7mjLjK/owgEzfLXQs7rK80S3abDV2Ux5MEyvMaZokrlzV/ROCs bFPyJOwZvcutnvAKbI/WrFCtLuBJIQcBN2p05r3ZErLaOeXNmEXCwgJdDLdJhaedkOkg 2Ujx1rsHLWTd09iGGDUV2gyKvnH75RCxSEyT2E8m84RGpzV1QjoZ9HvotdLJeCGEU+ty +TSA== X-Received: by 10.205.46.131 with SMTP id uo3mr18581095bkb.43.1369038603388; Mon, 20 May 2013 01:30:03 -0700 (PDT) Received: from camionet.local (77-85-165-231.btc-net.bg. [77.85.165.231]) by mx.google.com with ESMTPSA id so13sm1357820bkb.15.2013.05.20.01.30.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 01:30:02 -0700 (PDT) Message-ID: <5199DF08.8030002@jitsi.org> Date: Mon, 20 May 2013 11:30:00 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <51965506.7050008@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C373F07@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C373F07@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnqk/wHTP7PObwmmUPsqc3VLTAXojqBAHHIb9Loit2o0V9itvtEMOpkvOBK7aPyw1G/ftKJ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:00:09 -0000 Hey Christer, On 20.05.13, 09:50, Christer Holmberg wrote: > Hi Emil, > > I agree that the signaling protocol is outside the scope of this group. > > However, as SDP O/A is also used within the API, it becomes an issue for this group :) My point was that such semantics do not belong to SDP O/A in the first place. They are a matter for application specific signalling. Emil > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: 17. toukokuuta 2013 19:04 > To: rtcweb@ietf.org > Subject: [rtcweb] A problem with both A and B > > I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately. > > Both plan A and B currently describe semantics that would require O/A exchanges every time a source is added or removed from a session. > > Whether it is about adding a second webcam, or a conference participant that leaves or joins, both schemes suggest that the remote party should be notified with an updated SDP. > > Plan A deals with this by manipulating m= lines, while plan B does it with msid-s. > > We are nowhere near consensus and I think that this fact alone is a strong argument in favour of the following: > > This is not a problem for rtcweb to solve. > > We all have our own preferences for a solution and those come from the different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on the Web paradigm we would provide building blocks which can then be assembled into specific solutions (rather than providing the solutions themselves). > > In other words: it is not our job to try and implant a signalling protocol into O/A. Signalling is the job of the application. > > Applications alone know the meaning of the stream that came from your second web cam, or that of the tenth conference participant. They know which conferencing topology they most care about. They have best knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be displayed to describe the streams they are currently getting. > > Most importantly however: they are best placed to know how they'd like to communicate that information to their peers or IF they need to communicate it at all. > > Currently neither Plan A nor Plan B would let the application do its job. However I do believe Plan B is closer. > > If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and the only remaining problem is its insistence on the pre-announcement of SSRCs. > > If we get rid of that requirement then all we need would be for the W3C to make sure that the APIs have everything they need to allow apps to retrieve SSRC information, send it remotely then pass it down to the browser again when they receive it. > > I acknowledge that the simulcasting and FEC cases might be a bit different, which is normal because they are about the resolution of transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth investigating the options of doing this through RTP/RTCP. > > Does any of this make any sense? > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org From kevindempsey70@gmail.com Mon May 20 02:04:14 2013 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 D336921F89A5 for ; Mon, 20 May 2013 02:04:13 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa+DL8iLuhmS for ; Mon, 20 May 2013 02:04:12 -0700 (PDT) Received: from mail-la0-x242.google.com (mail-la0-x242.google.com [IPv6:2a00:1450:4010:c03::242]) by ietfa.amsl.com (Postfix) with ESMTP id 5380E21F93F9 for ; Mon, 20 May 2013 01:53:48 -0700 (PDT) Received: by mail-la0-f66.google.com with SMTP id fo13so937931lab.5 for ; Mon, 20 May 2013 01:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=N8hQbm424a1Vx3VFFxvU32kmclMzhEFFViErE561RYM=; b=AyVsvMHJ+TWBTkyHxlqZP1cpJ+hCjaXgrRncF6j2hrR9oWFfyNaldSgvdKQnubK8JI SxdyeYgFsWnoT+qmInBEevaOmzJ5nhCRn2+FpUop5LjLReheCjZK8ft+A5CTe6RKFvA8 O4b+Q+2GhK2+RP/PB4t9HhGjuo8VFvJoUxuG7+yaaaPvRku/p9UMGqVwehogF6jdmTc8 vqD3JLOMAwt/gI102p9NS1CgKlTiHQb96Eaczj/mY6AblhUjiMB41m/4lbHwSuDtjuS6 uZIfcr58PhzO+suPRwbAYf91Z2fvmx6JBFTMcnZrf61HGZQUO+aVYuyqvMISNkWlV4Jp PwUg== MIME-Version: 1.0 X-Received: by 10.112.63.7 with SMTP id c7mr509988lbs.5.1369040024719; Mon, 20 May 2013 01:53:44 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Mon, 20 May 2013 01:53:44 -0700 (PDT) In-Reply-To: <51965506.7050008@jitsi.org> References: <51965506.7050008@jitsi.org> Date: Mon, 20 May 2013 09:53:44 +0100 Message-ID: From: Kevin Dempsey To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c3f03e5b56b504dd2278e0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:04:14 -0000 --001a11c3f03e5b56b504dd2278e0 Content-Type: text/plain; charset=ISO-8859-1 I would say that at present only the sending application knows what a stream is for. The receiving side needs to determine the purpose by matching the RTP packets to the signalling the applications have done. In unbundled situations this is easy as the port it arrives on makes it obvious. In bundled cases, you would have to ensure the receiver knows some unique property of the RTP *before* it arrives. The best thing would be for the receiver to pick an identifier which, having been signalled in the offer to the sender, is included in every RTP packet (in a RTP extension header). Relying on SSRC signalling would mean that RTP sent before the SSRC identity arrives would not be handled consistently with RTP arriving after the SSRC identity. On 17 May 2013 17:04, Emil Ivov wrote: > I've mentioned this in a couple of other threads but I think it's > important so I am also posting it separately. > > Both plan A and B currently describe semantics that would require O/A > exchanges every time a source is added or removed from a session. > > Whether it is about adding a second webcam, or a conference participant > that leaves or joins, both schemes suggest that the remote party should > be notified with an updated SDP. > > Plan A deals with this by manipulating m= lines, while plan B does it > with msid-s. > > We are nowhere near consensus and I think that this fact alone is a > strong argument in favour of the following: > > This is not a problem for rtcweb to solve. > > We all have our own preferences for a solution and those come from the > different use cases we are planning on addressing and the different apps > we are planning to build. The promise of WebRTC is that, by building on > the Web paradigm we would provide building blocks which can then be > assembled into specific solutions (rather than providing the solutions > themselves). > > In other words: it is not our job to try and implant a signalling > protocol into O/A. Signalling is the job of the application. > > Applications alone know the meaning of the stream that came from your > second web cam, or that of the tenth conference participant. They know > which conferencing topology they most care about. They have best > knowledge about what streams they are currently rendering and which ones > they don't need. They know that the names Adam and Justin should be > displayed to describe the streams they are currently getting. > > Most importantly however: they are best placed to know how they'd like > to communicate that information to their peers or IF they need to > communicate it at all. > > Currently neither Plan A nor Plan B would let the application do its > job. However I do believe Plan B is closer. > > If we agree that browsers would give applications the latitude that's > necessary to address these issues with app specific signalling, then the > SDP shouldn't change when they are doing it. Plan B is almost there and > the only remaining problem is its insistence on the pre-announcement of > SSRCs. > > If we get rid of that requirement then all we need would be for the W3C > to make sure that the APIs have everything they need to allow apps to > retrieve SSRC information, send it remotely then pass it down to the > browser again when they receive it. > > I acknowledge that the simulcasting and FEC cases might be a bit > different, which is normal because they are about the resolution of > transport problems. I still think they could be solved with app-specific > signalling and the proper APIs but in this case it would also be worth > investigating the options of doing this through RTP/RTCP. > > Does any of this make any sense? > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c3f03e5b56b504dd2278e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would say that at present only the sending application k= nows what a stream is for. The receiving side needs to determine the purpos= e by matching the RTP packets to the signalling the applications have done.=

In unbundled situations this is easy as the port it ar= rives on makes it obvious. In bundled cases, you would have to ensure the r= eceiver knows some unique property of the RTP *before* it arrives. The best= thing would be for the receiver to pick an identifier which, having been s= ignalled in the offer to the sender, is included in every RTP packet (in a = RTP extension header).

Relying on SSRC signalling would mean that = RTP sent before the SSRC identity arrives would not be handled consistently= with RTP arriving after the SSRC identity.


On 17 May 2013 17:04, Emil Ivov <emcho@ji= tsi.org> wrote:
I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately.

Both plan A and B currently describe semantics that would require O/A
exchanges every time a source is added or removed from a session.

Whether it is about adding a second webcam, or a conference participant
that leaves or joins, both schemes suggest that the remote party should
be notified with an updated SDP.

Plan A deals with this by manipulating m=3D lines, while plan B does it
with msid-s.

We are nowhere near consensus and I think that this fact alone is a
strong argument in favour of the following:

This is not a problem for rtcweb to solve.

We all have our own preferences for a solution and those come from the
different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on
the Web paradigm we would provide building blocks which can then be
assembled into specific solutions (rather than providing the solutions
themselves).

In other words: it is not our job to try and implant a signalling
protocol into O/A. Signalling is the job of the application.

Applications alone know the meaning of the stream that came from your
second web cam, or that of the tenth conference participant. They know
which conferencing topology they most care about. They have best
knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be
displayed to describe the streams they are currently getting.

Most importantly however: they are best placed to know how they'd like<= br> to communicate that information to their peers or IF they need to
communicate it at all.

Currently neither Plan A nor Plan B would let the application do its
job. However I do believe Plan B is closer.

If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and=
the only remaining problem is its insistence on the pre-announcement of
SSRCs.

If we get rid of that requirement then all we need would be for the W3C
to make sure that the APIs have everything they need to allow apps to
retrieve SSRC information, send it remotely then pass it down to the
browser again when they receive it.

I acknowledge that the simulcasting and FEC cases might be a bit
different, which is normal because they are about the resolution of
transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth
investigating the options of doing this through RTP/RTCP.

Does any of this make any sense?

Emil

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

--001a11c3f03e5b56b504dd2278e0-- From lorenzo@meetecho.com Mon May 20 02:15:56 2013 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 4D23021F8415 for ; Mon, 20 May 2013 02:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v6SYR2IZn0m for ; Mon, 20 May 2013 02:15:50 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D94021F8556 for ; Mon, 20 May 2013 02:15:31 -0700 (PDT) Received: from localhost.localdomain ([143.225.229.163]) by smtpcmd05.ad.aruba.it with bizsmtp id e9FV1l00E3YAKuv019FVsx; Mon, 20 May 2013 11:15:29 +0200 Date: Mon, 20 May 2013 11:15:22 +0200 From: Lorenzo Miniero To: Gustavo =?UTF-8?B?R2FyY8OtYQ==?= Message-ID: <20130520111522.1b7e2eb1@meetecho.com> In-Reply-To: <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:15:56 -0000 Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=C3=ADa ha scritto: > I agree that TURN over websockets doesn't solve much more scenarios > than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing > it over HTTP that aside of philosophical discussions would be the > solution with better success rate? Otherwise we will have to > continue answering for another 10 years "why is this app not working > if skype does". >=20 > Something like this draft sent some months ago but perhaps for TURN > instead of direct connections: > http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >=20 When I submitted that draft this summer, I had that exact purpose in mind, that is taking care of corner edge cases like restrictive proxies and the like. Of course it was not meant to be a solution, just a way to foster discussion in that direction. In that discussion I also mentioned some work we did about this in the past, which in part apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations: http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html At the time most people in the ML thought it was either too useless, too complex or even harmful, considering it could be considered as a "sneaky" way to circumvent rules added by a network administrator, and so unacceptable. Anyway, as I said back then, a solution like this doesn't have to be sneaky, and it could very well be conceived in order to be admin-friendly rather than have a parrot and a wooden leg. Whether we actually need something like this or TURN-over-443 is enough I don't know: I still think it may be useful to tackle scenarios where everything else fails (the "skype works here" effect), so I'd be glad to be of help in that direction if needed. Lorenzo > On 16/05/2013, at 01:28, Hutton, Andrew wrote: >=20 > > I agree with Bernard's comments regarding the impact of DPI but of > > course such DPI devices do what they do and we can't and even don't > > want to stop them from doing it. However for the case when policy > > is such that the firewall will only allow traffic to traverse that > > comes from the HTTP Proxy or a network specific TURN server and > > there is no deliberate policy to block WebRTC media we need a > > solution and this is what > > draft-hutton-rtcweb-nat-firewall-considerations-00 addresses. > >=20 > > So far I don't see the benefit that TURN over websockets would have > > in this scenario and it needs additional implementation in the > > browser and the TURN server. > >=20 > > Regards > > Andy > >=20 > >=20 > >> -----Original Message----- > >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > >> Sent: 15 May 2013 18:20 > >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org > >> Subject: RE: [rtcweb] FW: New Version Notification for > >> draft-chenxin- behave-turn-websocket-00.txt > >>=20 > >> Andrew Hutton said: > >>> When we wrote the draft http://tools.ietf.org/html/draft-hutton- > >> rtcweb-nat-firewall-considerations-00 we did not include this > >> option because we did not see the benefit of additional transport > >> options for TURN given that the existing options (E.g. TURN/TCP > >> and TURN/TLS) seem to be meet our needs. > >>>=20 > >>> So what would be the benefits that justify this addition transport > >> option for TURN? > >>=20 > >> [BA] In my experience, institutions with very restrictive security > >> policies (e.g. those that don't allow UDP in or out) also tend to > >> deploy other measures such as deep packet inspection. So just > >> because some traffic is allowed in or out on port 80 does not mean > >> that TURN/TCP will be allowed on that port - a DPI box may examine > >> the traffic and complain if it doesn't see HTTP being used. On > >> the other hand, unless the DPI box is upgraded, it will also > >> complain about websockets. So I think draft-chenxin only helps in > >> a situation where TURN over Websockets would be allowed when > >> TURN/TCP would not be. That scenario is rare, at least at the > >> moment. > >>=20 > >> The argument for TURN over Websocket/TLS is even more difficult to > >> make. While DPI boxes may examine traffic destined to port 443 > >> carefully to make sure that TLS is really being used, assuming > >> that the DPI box does not see anything it considers fishy, the TLS > >> exchange will complete and the DPI box will lose visibility. > >> After TLS is running, the DPI box does not have much information > >> available to distinguish TURN/TLS from HTTP over TLS, with or > >> without websockets -- and those things it does have (such as > >> packet size) are as likely to result in an objection to websocket > >> transport as TURN/TLS. So I'm not sure that draft-chenxin will > >> help in that situation either. > >=20 > >=20 > >=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 From emil@sip-communicator.org Mon May 20 02:34:24 2013 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 6DEC221F92B2 for ; Mon, 20 May 2013 02:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ8sgdUGcXkk for ; Mon, 20 May 2013 02:34:22 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6AA21F9239 for ; Mon, 20 May 2013 02:34:08 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je2so156123bkc.18 for ; Mon, 20 May 2013 02:34:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=CUvDirgaHsY0HSgE/sxGbnbV6869WZiRsHakf5ULnYY=; b=lNhLM+a75b5Lytutz8hdGjhCqj3OP9Gvbwvq4HJCOzxtAgcWDfzPR/rf5cOAOj0Nb8 HoCOfnVXLORkG1jFtaSH+pqApNfy21cEyW5467xLrlI75xJ9sROC+/VDD2G3VCbaiXCt Rmm76w3eXQbNqTXHc2meWXZep/02TgoIVvbJ7Ef0FLOnlU8EbXlLdUBt6F2H2J02KBbA C5LjkYqzpvxG3JZmq1FySb4SVgNJNofCYmu037V0idBP66bbMB+Mz50iOyfdrkSpmuRn 9UQXtxs3wQrTwXvIS69leBZZUzsbjEeslta8G0eoBdftvmqqYCK41AZa6j9REoza80nq 9Osg== X-Received: by 10.205.9.193 with SMTP id ox1mr8803231bkb.35.1369042447249; Mon, 20 May 2013 02:34:07 -0700 (PDT) Received: from camionet.local (77-85-165-231.btc-net.bg. [77.85.165.231]) by mx.google.com with ESMTPSA id fz10sm5522660bkc.9.2013.05.20.02.34.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 02:34:06 -0700 (PDT) Message-ID: <5199EE06.30705@jitsi.org> Date: Mon, 20 May 2013 12:33:58 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kevin Dempsey References: <51965506.7050008@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmsg/ElPllAGikaFe4K1/z3QQ60owZupx7LnoIUTNYpZZzzHe+SZNvZ+4Y1c4z8+/3MG/Cq Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:34:24 -0000 On 20.05.13, 11:53, Kevin Dempsey wrote: > Relying on SSRC signalling would mean that RTP sent before the SSRC > identity arrives would not be handled consistently with RTP arriving > after the SSRC identity. If the application is doing the SSRC signalling and if the WebRTC API provides a way of retrieving it, an app would be able to signal an SSRC before, together with, or after the SDP from O/A. It will all be up to exactly what the app needs. Emil -- https://jitsi.org From sergio.garcia.murillo@gmail.com Mon May 20 02:36:19 2013 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 E3B7D21F9298 for ; Mon, 20 May 2013 02:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDtEfgtuEQXW for ; Mon, 20 May 2013 02:36:19 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4814C21F925B for ; Mon, 20 May 2013 02:36:19 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id my1so3428288bkb.33 for ; Mon, 20 May 2013 02:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=x18nxmX/nbyPljVMdykVATxfACajfldetn/vFLQw9No=; b=MFNBngjznXhLpHzsq5qYbIpGecYQHVsDb8A33UfRPqnt6YHmzjN9aYKxHQX4xfa1Yi alaeJEtsLKcrVDDJbHBi3I5gs8eVLKJIXUEiNIUErPOFec0BSkhjTe/zKjsqU6m9GU3/ HE5UtyiChfUHuCHQa0/kARgTwZpkEhXdEtWlJRAEMzTQfFtLRehWzLISb/dk/bz2pEcl RN+awpnRLhmcU2U4amWSet9lKvIyOXixW3EO5eOwpNY9dBb4g6AU0TY7ENwRIKyT39cz Qas4V7namIhxmAcm8XRaOU0pbDosfNPhHl13Bp/ANFC4aDP94QyZihRreGKuuHWOSTLA JA6Q== X-Received: by 10.205.33.6 with SMTP id sm6mr1743511bkb.25.1369042578374; Mon, 20 May 2013 02:36:18 -0700 (PDT) Received: from [192.168.1.50] (2.Red-83-53-69.dynamicIP.rima-tde.net. [83.53.69.2]) by mx.google.com with ESMTPSA id i15sm5520515bkz.12.2013.05.20.02.36.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 02:36:17 -0700 (PDT) Message-ID: <519B400A.405@gmail.com> Date: Tue, 21 May 2013 11:36:10 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51965506.7050008@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C373F07@ESESSMB209.ericsson.se> <5199DF08.8030002@jitsi.org> In-Reply-To: <5199DF08.8030002@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:36:20 -0000 El 20/05/2013 10:30, Emil Ivov escribió: > Hey Christer, > > On 20.05.13, 09:50, Christer Holmberg wrote: >> Hi Emil, >> >> I agree that the signaling protocol is outside the scope of this group. >> >> However, as SDP O/A is also used within the API, it becomes an issue for this group :) > My point was that such semantics do not belong to SDP O/A in the first > place. They are a matter for application specific signalling. > > Emil +1 BR Sergio From emil@sip-communicator.org Mon May 20 02:36:28 2013 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 D41AF21F9307 for ; Mon, 20 May 2013 02:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvdc4BZXtXL5 for ; Mon, 20 May 2013 02:36:27 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A463A21F9298 for ; Mon, 20 May 2013 02:36:26 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jk14so1767927bkc.31 for ; Mon, 20 May 2013 02:36:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=NH8yjaDoejvEetkWUptyhZjYlxYB/xUL/yUbU0HS7lI=; b=DIHq89zd7uDBDS7DOWZvel1Gih1jdvo52O8iDqQiWY6jLGJL2NYatX0mQMnaMrUgd8 B992jCTIQPVtxWvKnycUU/9YjhF6pionZTik0R7Toe40iRWrZGkEVMgVigHp1x/mZxjd JrG69E6fmx+xRNzGcXgtZwxW8QjFeIVT7KnTgt5yJ593p5Dys36k5nhHTFT2we56uN1x wMN780IUUoP+rSmy6yjCRdDB1D/q1dKKoBdGuI+CCNoddYb3I8X7PwFz3xoALMIjZWzy WDs5LYHVzcIpxXdYqltx74bAGDu4dUiWQtDpJ9+0rLYP1gGMekcjvOZdpiPn8jXGLlK0 mHqA== X-Received: by 10.205.115.196 with SMTP id ff4mr19129980bkc.111.1369042585142; Mon, 20 May 2013 02:36:25 -0700 (PDT) Received: from camionet.local (77-85-165-231.btc-net.bg. [77.85.165.231]) by mx.google.com with ESMTPSA id v6sm5530440bko.3.2013.05.20.02.36.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 02:36:24 -0700 (PDT) Message-ID: <5199EE93.9000904@jitsi.org> Date: Mon, 20 May 2013 12:36:19 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEE8@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEE8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmBstseO+YuN8lbWOw8o3Pw/w/ZVE62RLaa+d/+ue/FfUWh+T/jKuxn0LPOMEG0ldAvYtfo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:36:28 -0000 Hey Stefan, On 19.05.13, 14:35, Stefan H=E5kansson LK wrote: > I'm no expert, but how do you handle things like congestion management = > with translators? IIUC the RMCAT group has decided to handle the simple= =20 > point-point case only. (I'm not trying to remove translators from the=20 > topologies we cover - I just want to bring all the pieces to the table)= =2E I believe 3551 recommends use of RTCP and monitoring packet loss. Additional means can also be implemented over out-of-band signalling between the translator and a controlling entity. I already mentioned this in my response to Harald: note that my use of the term RTP translator did not apply solely to the "Topo-Trn-Translators" described in 5117. The problems (i.e. heavy signalling constraints) apply to pretty much any entity that is not mixing content and behaving like a complete single-stream B2BUA. Emil --=20 https://jitsi.org From adam@nostrum.com Mon May 20 02:43:42 2013 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 4572B21F90EB for ; Mon, 20 May 2013 02:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsH4jurOAeEh for ; Mon, 20 May 2013 02:43:40 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9F21F90EA for ; Mon, 20 May 2013 02:43:40 -0700 (PDT) Received: from Orochi.local (118-163-10-190.HINET-IP.hinet.net [118.163.10.190]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4K9hJsY064039 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 May 2013 04:43:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5199F032.9040101@nostrum.com> Date: Mon, 20 May 2013 17:43:14 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Harald Alvestrand References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> In-Reply-To: <5195304B.10706@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 118.163.10.190 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:43:42 -0000 On 5/17/13 03:15, Harald Alvestrand wrote: > Since an argument that has been made in favour of Plan A is that it is > (supposedly) more compatible with deployed code, this interests me > greatly. The other, probably more important factor when we're talking about legacy interop is that it will be hard (impossible?) to find *legacy* implementations that use more than 32 streams -- making this pretty much a non-issue from a legacy perspective. However, I think we do need to be explicit that RTCWEB implementations need to actually implement the AVT profile as specified, including the ability to use 96 PTs. /a From adam@nostrum.com Mon May 20 02:45:38 2013 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 4898221F926E for ; Mon, 20 May 2013 02:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yZri4FKyaW6 for ; Mon, 20 May 2013 02:45:35 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F77921F92BB for ; Mon, 20 May 2013 02:45:32 -0700 (PDT) Received: from Orochi.local (118-163-10-190.HINET-IP.hinet.net [118.163.10.190]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4K9jAmg064389 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 May 2013 04:45:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5199F0A0.8020406@nostrum.com> Date: Mon, 20 May 2013 17:45:04 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 118.163.10.190 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:45:38 -0000 On 5/18/13 00:10, Martin Thomson wrote: > On 16 May 2013 23:31, Harald Alvestrand wrote: >> The demuxing is trivial. In fact, I don't think it's even necessary to >> describe it as "demux on PT"; you can't allow SSRC collision between two >> tracks with different PT anyway. > Let's be very, very precise about this. > > Demultiplexing is *always* performed based on SSRC. It's just that > correlation with signaling components (the m-line in this case) might > use of PT in the absence of prior knowledge of SSRC. > > We didn't get this quite right in Plan A. Yeah, that's a valid point. It's not really being proposed as a demux point as much as a correlation token. Thanks for clearing that up -- we should definitely clear that up in the next version of the document. /a From adam@nostrum.com Mon May 20 02:47:02 2013 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 DC88D21F9344 for ; Mon, 20 May 2013 02:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mikAU9lY8iAF for ; Mon, 20 May 2013 02:47:01 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F221F926E for ; Mon, 20 May 2013 02:47:00 -0700 (PDT) Received: from Orochi.local (118-163-10-190.HINET-IP.hinet.net [118.163.10.190]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4K9kuQg068428 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 May 2013 04:46:58 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5199F10B.5030102@nostrum.com> Date: Mon, 20 May 2013 17:46:51 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5196460B.9000808@jitsi.org> <519654A5.1050406@jitsi.org> In-Reply-To: <519654A5.1050406@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 118.163.10.190 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 09:47:02 -0000 On 5/18/13 00:02, Emil Ivov wrote: > > On 17.05.13, 18:08, Eric Rescorla wrote: >> On Fri, May 17, 2013 at 8:00 AM, Emil Ivov > > wrote: >> >> >> On 17.05.13, 16:07, Eric Rescorla wrote:=line. >> >> >> > then presumably you need to follow this rule to ensure interop, no? >> >> Therefore, the interop part with the "many" endpoints seems to be >> covered already. One still needs to find ways of handling and >> potentially gatewaying ICE and SRTP for many of them but that's a >> different matter. O/A-wise we seem to have consensus on how to do the >> case with the two m= lines that each carry one track. >> >> It seems to me that we have now moved beyond that. >> >> >> The question is how an endpoint which wishes fo offer more than one >> audio and one video does so in a way that doesn't cause older >> endpoints to choke. > I might be misunderstanding or missing something, but isn't it clear > that, if you are trying not to choke anyone, the first thing to do would > be to stick to a single m= line for audio and a single m= line for video? > Not if you're talking to a device that expects three media streams -- such things have historically used three m=video sections (one for each stream). Which is kind of the reason we're specifying Plan A the way we are. /a From emil@sip-communicator.org Mon May 20 03:08:24 2013 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 859A521F9123 for ; Mon, 20 May 2013 03:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj5ZdChc-enq for ; Mon, 20 May 2013 03:08:23 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAA121F9051 for ; Mon, 20 May 2013 03:08:23 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id mx1so1023431bkb.26 for ; Mon, 20 May 2013 03:08:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=IykFnucPeOdDhs9cEjo5lxb3KhGqyfvDDqa9TJ41YbE=; b=hXhv1NKfiyf3PSD4P3t/Lvm13kMawCVRO9Mq3cURCyVdeqH9kJptDuEcO1usvQR8jf 9ws/zq+5Id/U1HozTxwW/XpT4f1DA8AhSuQ41jbwygjgAyg/+FmnGb/7KZ6snU9al1+l EcuoIAjJPmBfaT+APcVov63pCfTiuus1kWwhk8/XAPbZzXpRyY5vPTGPHuGrdIGVGdBw xN8WCtFHAs/aryJXyrwlR8u1BIxGTpY5eKvEJXWw/Llrz+AU4Myi037Nm7f6xBLWeIgm aTDtt2TQTlZmiYHqULYi02aqPhMnjlxjs/15jUZ8po3+IXFsGfoXYPAq57h7re6LKli6 /DBQ== X-Received: by 10.204.109.8 with SMTP id h8mr19376456bkp.88.1369044502483; Mon, 20 May 2013 03:08:22 -0700 (PDT) Received: from camionet.local (77-85-165-231.btc-net.bg. [77.85.165.231]) by mx.google.com with ESMTPSA id cl14sm5566000bkb.6.2013.05.20.03.08.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 03:08:21 -0700 (PDT) Message-ID: <5199F614.2040403@jitsi.org> Date: Mon, 20 May 2013 13:08:20 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Roach References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5196460B.9000808@jitsi.org> <519654A5.1050406@jitsi.org> <5199F10B.5030102@nostrum.com> In-Reply-To: <5199F10B.5030102@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkN4B7vBwo1qD7Wu6FC7GEhEQrvm+Rs+CNEe8nTohOyH6dCk48M/wPeJakj2BCzQyOUaTF1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 10:08:24 -0000 On 20.05.13, 12:46, Adam Roach wrote: > On 5/18/13 00:02, Emil Ivov wrote: >> >> On 17.05.13, 18:08, Eric Rescorla wrote: >>> On Fri, May 17, 2013 at 8:00 AM, Emil Ivov >> > wrote: >>> >>> >>> On 17.05.13, 16:07, Eric Rescorla wrote:=line. >>> >>> >>> > then presumably you need to follow this rule to ensure interop, no? >>> >>> Therefore, the interop part with the "many" endpoints seems to be >>> covered already. One still needs to find ways of handling and >>> potentially gatewaying ICE and SRTP for many of them but that's a >>> different matter. O/A-wise we seem to have consensus on how to do the >>> case with the two m= lines that each carry one track. >>> >>> It seems to me that we have now moved beyond that. >>> >>> >>> The question is how an endpoint which wishes fo offer more than one >>> audio and one video does so in a way that doesn't cause older >>> endpoints to choke. >> I might be misunderstanding or missing something, but isn't it clear >> that, if you are trying not to choke anyone, the first thing to do would >> be to stick to a single m= line for audio and a single m= line for video? >> > > Not if you're talking to a device that expects three media streams -- This gets back to my original point: I don't see how such a device would qualify as one of the "many legacy endpoints that have already been deployed". > such things have historically used three m=video sections (one for each > stream). Which is kind of the reason we're specifying Plan A the way we are. I get that, but I don't believe it is an effort to guarantee interop with legacy. It's an effort to talk to specific applications that use such signalling. Note that if you really need to interoperate with such applications you would still be able to do this if WebRTC gave you the necessary API. You would then have the choice of modifying the browser's SDP in the javascript or handling it all in a signalling gateway. Emil -- https://jitsi.org From christer.holmberg@ericsson.com Mon May 20 03:25:06 2013 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 89CD821F8E9A for ; Mon, 20 May 2013 03:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMbh5RX80ueu for ; Mon, 20 May 2013 03:24:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 56DAA21F869A for ; Mon, 20 May 2013 03:24:52 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-a1-5199f9f3f3c3 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B7.D3.31782.3F9F9915; Mon, 20 May 2013 12:24:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 20 May 2013 12:24:51 +0200 From: Christer Holmberg To: Kevin Dempsey , Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUxg7Crd1S7QwyEqM9DOrRHv1xJkNp1kAgAA50HA= Date: Mon, 20 May 2013 10:24:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C374282@ESESSMB209.ericsson.se> References: <51965506.7050008@jitsi.org> 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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C374282ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvre7nnzMDDTpmalus2TmBxeLm/Lcs Fmv/tbM7MHvsnHWX3WPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlvDpdW3CrsOLeurWsDYwn E7oYOTkkBEwk1uzrYIawxSQu3FvP1sXIxSEkcJhR4vfudSwQzhJGiYWf/gBlODjYBCwkuv9p g5giAp4SZ65kg/QyC6hL3Fl8jh3EFhYwlPh94RTYTBEBI4lr6/ezQJRbSVxpTAMJswioSiw5 eokNxOYV8JW49n0XI4gtJJAvceDOB7A4p0CgxO47U8FsRqDTvp9awwSxSlzi1pP5TBAnC0gs 2XMe6nxRiZeP/7GCrJIQUJRY3i8HUZ4v8bZnDzvEKkGJkzOfsExgFJ2FZNIsJGWzkJRBxHUk Fuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZOenlRpsYgdF1cMtv1R2Md86JHGKU5mBR Euft1Z4aKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRbNMPvSWFH5a9m/Br57EnR17c4eM+ oR22IP7xUtNFpYV79b+dmyIQ4VKjeFho4e7nlikxU09dNuXlzeuKXVHINOPGzqs9q5mLLnzc f/Pd6fp+k/PRTEpvVHgL0rYcv+imEXOXR8k0u7TV+Odeu0q1uS2fmc+vmTNb5wx76J7D3hs3 tfhZ6EeJKbEUZyQaajEXFScCAPlLCrN8AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 10:25:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C374282ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Whatever mechanism we choose for demuxing RTP packets, I think it is ok tha= t one has to wait for the SDP answer in order to figure out all information= needed (e.g. the SSRC value used by the remote sender), and to possibly dr= op media that is received before the SDP answer is received. In theory this could cause clipping problem, but at least my experience is = that it's not a problem in reality, the reason being that the SDP answer if= often sent (e.g. in a SIP 18x response) well before the remote media. Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Kevin Dempsey Sent: 20. toukokuuta 2013 11:54 To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B I would say that at present only the sending application knows what a strea= m is for. The receiving side needs to determine the purpose by matching the= RTP packets to the signalling the applications have done. In unbundled situations this is easy as the port it arrives on makes it obv= ious. In bundled cases, you would have to ensure the receiver knows some un= ique property of the RTP *before* it arrives. The best thing would be for t= he receiver to pick an identifier which, having been signalled in the offer= to the sender, is included in every RTP packet (in a RTP extension header)= . Relying on SSRC signalling would mean that RTP sent before the SSRC identit= y arrives would not be handled consistently with RTP arriving after the SSR= C identity. On 17 May 2013 17:04, Emil Ivov > w= rote: I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately. Both plan A and B currently describe semantics that would require O/A exchanges every time a source is added or removed from a session. Whether it is about adding a second webcam, or a conference participant that leaves or joins, both schemes suggest that the remote party should be notified with an updated SDP. Plan A deals with this by manipulating m=3D lines, while plan B does it with msid-s. We are nowhere near consensus and I think that this fact alone is a strong argument in favour of the following: This is not a problem for rtcweb to solve. We all have our own preferences for a solution and those come from the different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on the Web paradigm we would provide building blocks which can then be assembled into specific solutions (rather than providing the solutions themselves). In other words: it is not our job to try and implant a signalling protocol into O/A. Signalling is the job of the application. Applications alone know the meaning of the stream that came from your second web cam, or that of the tenth conference participant. They know which conferencing topology they most care about. They have best knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be displayed to describe the streams they are currently getting. Most importantly however: they are best placed to know how they'd like to communicate that information to their peers or IF they need to communicate it at all. Currently neither Plan A nor Plan B would let the application do its job. However I do believe Plan B is closer. If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and the only remaining problem is its insistence on the pre-announcement of SSRCs. If we get rid of that requirement then all we need would be for the W3C to make sure that the APIs have everything they need to allow apps to retrieve SSRC information, send it remotely then pass it down to the browser again when they receive it. I acknowledge that the simulcasting and FEC cases might be a bit different, which is normal because they are about the resolution of transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth investigating the options of doing this through RTP/RTCP. Does any of this make any sense? Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C374282ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Whatever mechanism we cho= ose for demuxing RTP packets, I think it is ok that one has to wait for the= SDP answer in order to figure out all information needed (e.g. the SSRC value used by the remote sender), and to possibly drop medi= a that is received before the SDP answer is received.

 <= /p>

In theory this could caus= e clipping problem, but at least my experience is that it’s not a pro= blem in reality, the reason being that the SDP answer if often sent (e.g. in a SIP 18x response) well before the remote media.=

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Kevin Dempsey
Sent: 20. toukokuuta 2013 11:54
To: Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] A problem with both A and B<= /p>

 

I would say that at present only the sending applica= tion knows what a stream is for. The receiving side needs to determine the = purpose by matching the RTP packets to the signalling the applications have= done.

 

In unbundled situations this is easy as the port it = arrives on makes it obvious. In bundled cases, you would have to ensure the= receiver knows some unique property of the RTP *before* it arrives. The be= st thing would be for the receiver to pick an identifier which, having been signalled in the offer to the sen= der, is included in every RTP packet (in a RTP extension header).

 

Relying on SSRC signalling would mean that RTP sent = before the SSRC identity arrives would not be handled consistently with RTP= arriving after the SSRC identity.

 

On 17 May 2013 17:04, Emil Ivov <emcho@jitsi.org> wrote:

I've mentioned this in a couple of other threads but= I think it's
important so I am also posting it separately.

Both plan A and B currently describe semantics that would require O/A
exchanges every time a source is added or removed from a session.

Whether it is about adding a second webcam, or a conference participant
that leaves or joins, both schemes suggest that the remote party should
be notified with an updated SDP.

Plan A deals with this by manipulating m=3D lines, while plan B does it
with msid-s.

We are nowhere near consensus and I think that this fact alone is a
strong argument in favour of the following:

This is not a problem for rtcweb to solve.

We all have our own preferences for a solution and those come from the
different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on
the Web paradigm we would provide building blocks which can then be
assembled into specific solutions (rather than providing the solutions
themselves).

In other words: it is not our job to try and implant a signalling
protocol into O/A. Signalling is the job of the application.

Applications alone know the meaning of the stream that came from your
second web cam, or that of the tenth conference participant. They know
which conferencing topology they most care about. They have best
knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be
displayed to describe the streams they are currently getting.

Most importantly however: they are best placed to know how they'd like
to communicate that information to their peers or IF they need to
communicate it at all.

Currently neither Plan A nor Plan B would let the application do its
job. However I do believe Plan B is closer.

If we agree that browsers would give applications the latitude that's
necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and
the only remaining problem is its insistence on the pre-announcement of
SSRCs.

If we get rid of that requirement then all we need would be for the W3C
to make sure that the APIs have everything they need to allow apps to
retrieve SSRC information, send it remotely then pass it down to the
browser again when they receive it.

I acknowledge that the simulcasting and FEC cases might be a bit
different, which is normal because they are about the resolution of
transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth
investigating the options of doing this through RTP/RTCP.

Does any of this make any sense?

Emil

--
http= s://jitsi.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

--_000_7594FB04B1934943A5C02806D1A2204B1C374282ESESSMB209erics_-- From andrew.hutton@siemens-enterprise.com Mon May 20 04:06:48 2013 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 4BA6421F912C; Mon, 20 May 2013 04:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io7+nY8zucjz; Mon, 20 May 2013 04:06:38 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F313221F8A14; Mon, 20 May 2013 04:06:37 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id BC18C1EB84EE; Mon, 20 May 2013 13:06:36 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Mon, 20 May 2013 13:06:36 +0200 From: "Hutton, Andrew" To: Lorenzo Miniero , =?utf-8?B?R3VzdGF2byBHYXJjw61h?= Thread-Topic: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVTqUu83hGBO03EOmioPLICQbqpkN5f0A Date: Mon, 20 May 2013 11:06:35 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> In-Reply-To: <20130520111522.1b7e2eb1@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 11:06:48 -0000 UmVnYXJkaW5nIHRoZSBIVFRQIGZhbGxiYWNrIGFuZCB3aGV0aGVyIHRoaXMgY291bGQgYmUgYWRh cHRlZCB0byBiZSBhIFRVUk4gb3ZlciBIVFRQIGJhc2VkIHNvbHV0aW9uIHRoZW4gSSB0aGluayB0 aGUgc2FtZSBjb21tZW50cyB0aGF0IHdlcmUgbWFkZSBvbiB0aGUgVFVSTiBvdmVyIHdlYnNvY2tl dHMgYXBwbHkuIFdoYXQgYXJlIHRoZSBiZW5lZml0cyBvZiBjcmVhdGluZyBhIG5ldyB0cmFuc3Bv cnQgZm9yIFRVUk4gb3ZlciB3aGF0IHdlIGNhbiBkbyB1c2luZyBIVFRQIENvbm5lY3QgYXMgZGVz Y3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1ydGN3ZWIt bmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zLTAwLg0KDQpIYXZpbmcgc2FpZCB0aGF0IEkgYW0g cmVhbGx5IGhhcHB5IHdlIGFyZSBoYXZpbmcgdGhpcyBkZWJhdGUgYXMgd2UgcmVhbGx5IG5lZWQg dG8gZmluZCBhIHNvbHV0aW9uIGhlcmUgdGhhdCB0aGUgYnJvd3NlciB2ZW5kb3JzIHdpbGwgaW1w bGVtZW50IHNvIEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyB3aGljaCBvcHRpb25zIHRoZXkg cHJlZmVyLg0KDQpJIHJlYWxseSBob3BlIHdlIGNhbiBnZXQgZHJhZnQtaHV0dG9uLXJ0Y3dlYi1u YXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMgYWRvcHRlZCBhbmQgdXNlIGl0IHRvIGRvY3VtZW50 IHdoYXRldmVyIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlcyBvbiBiZWluZyB0aGUgcmlnaHQgc29s dXRpb24uDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IExvcmVuem8gTWluaWVybyBbbWFpbHRvOmxvcmVuem9AbWVldGVjaG8uY29tXQ0K PiBTZW50OiAyMCBNYXkgMjAxMyAxMDoxNQ0KPiBUbzogR3VzdGF2byBHYXJjw61hDQo+IENjOiBI dXR0b24sIEFuZHJldzsgcnRjd2ViQGlldGYub3JnOyBiZWhhdmVAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtydGN3ZWJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hlbnhp bi0NCj4gYmVoYXZlLXR1cm4td2Vic29ja2V0LTAwLnR4dA0KPiANCj4gSWwgZ2lvcm5vIFN1biwg MTkgTWF5IDIwMTMgMjM6MjA6NDEgLTA3MDANCj4gR3VzdGF2byBHYXJjw61hIDxnZ2JAdG9rYm94 LmNvbT4gaGEgc2NyaXR0bzoNCj4gDQo+ID4gSSBhZ3JlZSB0aGF0IFRVUk4gb3ZlciB3ZWJzb2Nr ZXRzIGRvZXNuJ3Qgc29sdmUgbXVjaCBtb3JlIHNjZW5hcmlvcw0KPiA+IHRoYW4gVFVSTi9UTFMu ICAgSWYgdHJ5aW5nIHRvIGZpeCBIVFRQIFByb3h5IHRyYXZlcnNhbCB3aHkgbm90IGRvaW5nDQo+ ID4gaXQgb3ZlciBIVFRQIHRoYXQgYXNpZGUgb2YgcGhpbG9zb3BoaWNhbCBkaXNjdXNzaW9ucyB3 b3VsZCBiZSB0aGUNCj4gPiBzb2x1dGlvbiB3aXRoIGJldHRlciBzdWNjZXNzIHJhdGU/ICBPdGhl cndpc2Ugd2Ugd2lsbCBoYXZlIHRvDQo+ID4gY29udGludWUgYW5zd2VyaW5nIGZvciBhbm90aGVy IDEwIHllYXJzICJ3aHkgaXMgdGhpcyBhcHAgbm90IHdvcmtpbmcNCj4gPiBpZiBza3lwZSBkb2Vz Ii4NCj4gPg0KPiA+IFNvbWV0aGluZyBsaWtlIHRoaXMgZHJhZnQgc2VudCBzb21lIG1vbnRocyBh Z28gYnV0IHBlcmhhcHMgZm9yIFRVUk4NCj4gPiBpbnN0ZWFkIG9mIGRpcmVjdCBjb25uZWN0aW9u czoNCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbWluaWVyby1ydGN3ZWItaHR0 cC1mYWxsYmFjay0wMC50eHQNCj4gPg0KPiANCj4gDQo+IFdoZW4gSSBzdWJtaXR0ZWQgdGhhdCBk cmFmdCB0aGlzIHN1bW1lciwgSSBoYWQgdGhhdCBleGFjdCBwdXJwb3NlIGluDQo+IG1pbmQsIHRo YXQgaXMgdGFraW5nIGNhcmUgb2YgY29ybmVyIGVkZ2UgY2FzZXMgbGlrZSByZXN0cmljdGl2ZSBw cm94aWVzDQo+IGFuZCB0aGUgbGlrZS4gT2YgY291cnNlIGl0IHdhcyBub3QgbWVhbnQgdG8gYmUg YSBzb2x1dGlvbiwganVzdCBhIHdheQ0KPiB0byBmb3N0ZXIgZGlzY3Vzc2lvbiBpbiB0aGF0IGRp cmVjdGlvbi4gSW4gdGhhdCBkaXNjdXNzaW9uIEkgYWxzbw0KPiBtZW50aW9uZWQgc29tZSB3b3Jr IHdlIGRpZCBhYm91dCB0aGlzIGluIHRoZSBwYXN0LCB3aGljaCBpbiBwYXJ0DQo+IGFwcGFyZW50 bHkgZW5kZWQgdXAgaW4gZHJhZnQtaHV0dG9uLXJ0Y3dlYi1uYXQtZmlyZXdhbGwtY29uc2lkZXJh dGlvbnM6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2Vi L2N1cnJlbnQvbXNnMDUwNDEuaHRtbA0KPiANCj4gQXQgdGhlIHRpbWUgbW9zdCBwZW9wbGUgaW4g dGhlIE1MIHRob3VnaHQgaXQgd2FzIGVpdGhlciB0b28gdXNlbGVzcywNCj4gdG9vIGNvbXBsZXgg b3IgZXZlbiBoYXJtZnVsLCBjb25zaWRlcmluZyBpdCBjb3VsZCBiZSBjb25zaWRlcmVkIGFzIGEN Cj4gInNuZWFreSIgd2F5IHRvIGNpcmN1bXZlbnQgcnVsZXMgYWRkZWQgYnkgYSBuZXR3b3JrIGFk bWluaXN0cmF0b3IsIGFuZA0KPiBzbyB1bmFjY2VwdGFibGUuIEFueXdheSwgYXMgSSBzYWlkIGJh Y2sgdGhlbiwgYSBzb2x1dGlvbiBsaWtlIHRoaXMNCj4gZG9lc24ndCBoYXZlIHRvIGJlIHNuZWFr eSwgYW5kIGl0IGNvdWxkIHZlcnkgd2VsbCBiZSBjb25jZWl2ZWQgaW4gb3JkZXINCj4gdG8gYmUg YWRtaW4tZnJpZW5kbHkgcmF0aGVyIHRoYW4gaGF2ZSBhIHBhcnJvdCBhbmQgYSB3b29kZW4gbGVn Lg0KPiANCj4gV2hldGhlciB3ZSBhY3R1YWxseSBuZWVkIHNvbWV0aGluZyBsaWtlIHRoaXMgb3Ig VFVSTi1vdmVyLTQ0MyBpcyBlbm91Z2gNCj4gSSBkb24ndCBrbm93OiBJIHN0aWxsIHRoaW5rIGl0 IG1heSBiZSB1c2VmdWwgdG8gdGFja2xlIHNjZW5hcmlvcyB3aGVyZQ0KPiBldmVyeXRoaW5nIGVs c2UgZmFpbHMgKHRoZSAic2t5cGUgd29ya3MgaGVyZSIgZWZmZWN0KSwgc28gSSdkIGJlIGdsYWQN Cj4gdG8gYmUgb2YgaGVscCBpbiB0aGF0IGRpcmVjdGlvbiBpZiBuZWVkZWQuDQo+IA0KPiBMb3Jl bnpvDQo+IA0KPiANCj4gDQo+ID4gT24gMTYvMDUvMjAxMywgYXQgMDE6MjgsIEh1dHRvbiwgQW5k cmV3IHdyb3RlOg0KPiA+DQo+ID4gPiBJIGFncmVlIHdpdGggQmVybmFyZCdzIGNvbW1lbnRzIHJl Z2FyZGluZyB0aGUgaW1wYWN0IG9mIERQSSBidXQgb2YNCj4gPiA+IGNvdXJzZSBzdWNoIERQSSBk ZXZpY2VzIGRvIHdoYXQgdGhleSBkbyBhbmQgd2UgY2FuJ3QgYW5kIGV2ZW4gZG9uJ3QNCj4gPiA+ IHdhbnQgdG8gc3RvcCB0aGVtIGZyb20gZG9pbmcgaXQuIEhvd2V2ZXIgZm9yIHRoZSBjYXNlIHdo ZW4gcG9saWN5DQo+ID4gPiBpcyBzdWNoIHRoYXQgdGhlIGZpcmV3YWxsIHdpbGwgb25seSBhbGxv dyB0cmFmZmljIHRvIHRyYXZlcnNlIHRoYXQNCj4gPiA+IGNvbWVzIGZyb20gdGhlIEhUVFAgUHJv eHkgb3IgYSBuZXR3b3JrIHNwZWNpZmljIFRVUk4gc2VydmVyIGFuZA0KPiA+ID4gdGhlcmUgaXMg bm8gZGVsaWJlcmF0ZSBwb2xpY3kgdG8gYmxvY2sgV2ViUlRDIG1lZGlhIHdlIG5lZWQgYQ0KPiA+ ID4gc29sdXRpb24gYW5kIHRoaXMgaXMgd2hhdA0KPiA+ID4gZHJhZnQtaHV0dG9uLXJ0Y3dlYi1u YXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMtMDAgYWRkcmVzc2VzLg0KPiA+ID4NCj4gPiA+IFNv IGZhciBJIGRvbid0IHNlZSB0aGUgYmVuZWZpdCB0aGF0IFRVUk4gb3ZlciB3ZWJzb2NrZXRzIHdv dWxkIGhhdmUNCj4gPiA+IGluIHRoaXMgc2NlbmFyaW8gYW5kIGl0IG5lZWRzIGFkZGl0aW9uYWwg aW1wbGVtZW50YXRpb24gaW4gdGhlDQo+ID4gPiBicm93c2VyIGFuZCB0aGUgVFVSTiBzZXJ2ZXIu DQo+ID4gPg0KPiA+ID4gUmVnYXJkcw0KPiA+ID4gQW5keQ0KPiA+ID4NCj4gPiA+DQo+ID4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBCZXJuYXJkIEFib2JhIFtt YWlsdG86YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbV0NCj4gPiA+PiBTZW50OiAxNSBNYXkgMjAx MyAxODoyMA0KPiA+ID4+IFRvOiBIdXR0b24sIEFuZHJldzsgQ2hlbnhpbiAoWGluKTsgYmVoYXZl QGlldGYub3JnOw0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gPiA+PiBTdWJqZWN0OiBSRTogW3J0Y3dl Yl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiA+PiBkcmFmdC1jaGVueGlu LSBiZWhhdmUtdHVybi13ZWJzb2NrZXQtMDAudHh0DQo+ID4gPj4NCj4gPiA+PiBBbmRyZXcgSHV0 dG9uIHNhaWQ6DQo+ID4gPj4+IFdoZW4gd2Ugd3JvdGUgdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi0NCj4gPiA+PiBydGN3ZWItbmF0LWZpcmV3YWxsLWNv bnNpZGVyYXRpb25zLTAwIHdlIGRpZCBub3QgaW5jbHVkZSB0aGlzDQo+ID4gPj4gb3B0aW9uIGJl Y2F1c2Ugd2UgZGlkIG5vdCBzZWUgdGhlIGJlbmVmaXQgb2YgYWRkaXRpb25hbCB0cmFuc3BvcnQN Cj4gPiA+PiBvcHRpb25zIGZvciBUVVJOIGdpdmVuIHRoYXQgdGhlIGV4aXN0aW5nIG9wdGlvbnMg KEUuZy4gVFVSTi9UQ1ANCj4gPiA+PiBhbmQgVFVSTi9UTFMpIHNlZW0gdG8gYmUgbWVldCBvdXIg bmVlZHMuDQo+ID4gPj4+DQo+ID4gPj4+IFNvIHdoYXQgd291bGQgYmUgdGhlIGJlbmVmaXRzIHRo YXQganVzdGlmeSB0aGlzIGFkZGl0aW9uDQo+IHRyYW5zcG9ydA0KPiA+ID4+IG9wdGlvbiBmb3Ig VFVSTj8NCj4gPiA+Pg0KPiA+ID4+IFtCQV0gSW4gbXkgZXhwZXJpZW5jZSwgIGluc3RpdHV0aW9u cyB3aXRoIHZlcnkgcmVzdHJpY3RpdmUNCj4gc2VjdXJpdHkNCj4gPiA+PiBwb2xpY2llcyAoZS5n LiB0aG9zZSB0aGF0IGRvbid0IGFsbG93IFVEUCBpbiBvciBvdXQpIGFsc28gdGVuZCB0bw0KPiA+ ID4+IGRlcGxveSBvdGhlciBtZWFzdXJlcyBzdWNoIGFzIGRlZXAgcGFja2V0IGluc3BlY3Rpb24u ICAgU28ganVzdA0KPiA+ID4+IGJlY2F1c2Ugc29tZSB0cmFmZmljIGlzIGFsbG93ZWQgaW4gb3Ig b3V0IG9uIHBvcnQgODAgZG9lcyBub3QgbWVhbg0KPiA+ID4+IHRoYXQgVFVSTi9UQ1Agd2lsbCBi ZSBhbGxvd2VkIG9uIHRoYXQgcG9ydCAtIGEgRFBJIGJveCBtYXkgZXhhbWluZQ0KPiA+ID4+IHRo ZSB0cmFmZmljIGFuZCBjb21wbGFpbiBpZiBpdCBkb2Vzbid0IHNlZSBIVFRQIGJlaW5nIHVzZWQu ICBPbg0KPiA+ID4+IHRoZSBvdGhlciBoYW5kLCB1bmxlc3MgdGhlIERQSSBib3ggaXMgdXBncmFk ZWQsIGl0IHdpbGwgYWxzbw0KPiA+ID4+IGNvbXBsYWluIGFib3V0IHdlYnNvY2tldHMuICBTbyBJ IHRoaW5rIGRyYWZ0LWNoZW54aW4gb25seSBoZWxwcyBpbg0KPiA+ID4+IGEgc2l0dWF0aW9uIHdo ZXJlIFRVUk4gb3ZlciBXZWJzb2NrZXRzIHdvdWxkIGJlIGFsbG93ZWQgd2hlbg0KPiA+ID4+IFRV Uk4vVENQIHdvdWxkIG5vdCBiZS4gIFRoYXQgc2NlbmFyaW8gaXMgcmFyZSwgYXQgbGVhc3QgYXQg dGhlDQo+ID4gPj4gbW9tZW50Lg0KPiA+ID4+DQo+ID4gPj4gVGhlIGFyZ3VtZW50IGZvciBUVVJO IG92ZXIgV2Vic29ja2V0L1RMUyBpcyBldmVuIG1vcmUgZGlmZmljdWx0IHRvDQo+ID4gPj4gbWFr ZS4gV2hpbGUgRFBJIGJveGVzIG1heSBleGFtaW5lIHRyYWZmaWMgZGVzdGluZWQgdG8gcG9ydCA0 NDMNCj4gPiA+PiBjYXJlZnVsbHkgdG8gbWFrZSBzdXJlIHRoYXQgVExTIGlzIHJlYWxseSBiZWlu ZyB1c2VkLCAgYXNzdW1pbmcNCj4gPiA+PiB0aGF0IHRoZSBEUEkgYm94IGRvZXMgbm90IHNlZSBh bnl0aGluZyBpdCBjb25zaWRlcnMgZmlzaHksIHRoZSBUTFMNCj4gPiA+PiBleGNoYW5nZSB3aWxs IGNvbXBsZXRlIGFuZCB0aGUgRFBJIGJveCB3aWxsIGxvc2UgdmlzaWJpbGl0eS4NCj4gPiA+PiBB ZnRlciBUTFMgaXMgcnVubmluZywgdGhlIERQSSBib3ggZG9lcyBub3QgaGF2ZSBtdWNoIGluZm9y bWF0aW9uDQo+ID4gPj4gYXZhaWxhYmxlIHRvIGRpc3Rpbmd1aXNoIFRVUk4vVExTIGZyb20gSFRU UCBvdmVyIFRMUywgd2l0aCBvcg0KPiA+ID4+IHdpdGhvdXQgd2Vic29ja2V0cyAtLSBhbmQgdGhv c2UgdGhpbmdzIGl0IGRvZXMgaGF2ZSAoc3VjaCBhcw0KPiA+ID4+IHBhY2tldCBzaXplKSBhcmUg YXMgbGlrZWx5IHRvIHJlc3VsdCBpbiBhbiBvYmplY3Rpb24gdG8gd2Vic29ja2V0DQo+ID4gPj4g dHJhbnNwb3J0IGFzIFRVUk4vVExTLiAgU28gSSdtIG5vdCBzdXJlIHRoYXQgZHJhZnQtY2hlbnhp biB3aWxsDQo+ID4gPj4gaGVscCBpbiB0aGF0IHNpdHVhdGlvbiBlaXRoZXIuDQo+ID4gPg0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gPiA+IHJ0Y3dlYkBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWINCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiA+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From kevindempsey70@gmail.com Mon May 20 04:12:49 2013 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 E772A21F90BB for ; Mon, 20 May 2013 04:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7Sg1AjcI76M for ; Mon, 20 May 2013 04:12:44 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC121F854E for ; Mon, 20 May 2013 04:12:43 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so6402736lbf.14 for ; Mon, 20 May 2013 04:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GTgTFoDZkRClC1M8T4sWv3Jf1ftinrofhxRqbjYJXgg=; b=AS80EEcz99Dy/r0Yaws3XIhTHbGxW9kU9ZltGmrxxV0+YEaVDGDXM2YCv8Qymmi/ey JqVWWaLo+nE22i0rFQcGPXrR7qSpeahQMvzEMo7GWXdnVFmsTiKeVNHhndftJyTGuSjY cbjfkoSl+5AarxQRt1zRaWxWPGsTjL22Sqv25KbpyOWEpTwyiBj+B0Cojcd8un8nhqbD VqJWi+aabucHQ0A9aa4VUw+A9oZZZZ4FDsOpiRWnAOym8iJp1FSipsq38k+j8CmPCbZb mMLINhmLk/eOTG8mB01Olb9+5fKyaxpTgwUeDPtjYjYj+BemXDaMGRYxLHPzitVPz/N/ Phzw== MIME-Version: 1.0 X-Received: by 10.152.1.6 with SMTP id 6mr3988939lai.14.1369048342276; Mon, 20 May 2013 04:12:22 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Mon, 20 May 2013 04:12:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C374282@ESESSMB209.ericsson.se> References: <51965506.7050008@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374282@ESESSMB209.ericsson.se> Date: Mon, 20 May 2013 12:12:22 +0100 Message-ID: From: Kevin Dempsey To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013c67061f307604dd24689f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 11:12:49 -0000 --089e013c67061f307604dd24689f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Since webrtc is using ICE, the initial answer must have arrived before any media can be sent. However, that doesn't deal with cases where the SSRC is either unknown or can change. An example would be where a media server is used to play files during a call. Each of the file replays can use a different SSRC. On 20 May 2013 11:24, Christer Holmberg wro= te: > Hi,**** > > ** ** > > Whatever mechanism we choose for demuxing RTP packets, I think it is ok > that one has to wait for the SDP answer in order to figure out all > information needed (e.g. the SSRC value used by the remote sender), and t= o > possibly drop media that is received before the SDP answer is received.**= * > * > > ** ** > > In theory this could cause clipping problem, but at least my experience i= s > that it=92s not a problem in reality, the reason being that the SDP answe= r if > often sent (e.g. in a SIP 18x response) well before the remote media.**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Kevin Dempsey > *Sent:* 20. toukokuuta 2013 11:54 > *To:* Emil Ivov > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] A problem with both A and B**** > > ** ** > > I would say that at present only the sending application knows what a > stream is for. The receiving side needs to determine the purpose by > matching the RTP packets to the signalling the applications have done.***= * > > ** ** > > In unbundled situations this is easy as the port it arrives on makes it > obvious. In bundled cases, you would have to ensure the receiver knows so= me > unique property of the RTP *before* it arrives. The best thing would be f= or > the receiver to pick an identifier which, having been signalled in the > offer to the sender, is included in every RTP packet (in a RTP extension > header).**** > > ** ** > > Relying on SSRC signalling would mean that RTP sent before the SSRC > identity arrives would not be handled consistently with RTP arriving afte= r > the SSRC identity.**** > > ** ** > > On 17 May 2013 17:04, Emil Ivov wrote:**** > > I've mentioned this in a couple of other threads but I think it's > important so I am also posting it separately. > > Both plan A and B currently describe semantics that would require O/A > exchanges every time a source is added or removed from a session. > > Whether it is about adding a second webcam, or a conference participant > that leaves or joins, both schemes suggest that the remote party should > be notified with an updated SDP. > > Plan A deals with this by manipulating m=3D lines, while plan B does it > with msid-s. > > We are nowhere near consensus and I think that this fact alone is a > strong argument in favour of the following: > > This is not a problem for rtcweb to solve. > > We all have our own preferences for a solution and those come from the > different use cases we are planning on addressing and the different apps > we are planning to build. The promise of WebRTC is that, by building on > the Web paradigm we would provide building blocks which can then be > assembled into specific solutions (rather than providing the solutions > themselves). > > In other words: it is not our job to try and implant a signalling > protocol into O/A. Signalling is the job of the application. > > Applications alone know the meaning of the stream that came from your > second web cam, or that of the tenth conference participant. They know > which conferencing topology they most care about. They have best > knowledge about what streams they are currently rendering and which ones > they don't need. They know that the names Adam and Justin should be > displayed to describe the streams they are currently getting. > > Most importantly however: they are best placed to know how they'd like > to communicate that information to their peers or IF they need to > communicate it at all. > > Currently neither Plan A nor Plan B would let the application do its > job. However I do believe Plan B is closer. > > If we agree that browsers would give applications the latitude that's > necessary to address these issues with app specific signalling, then the > SDP shouldn't change when they are doing it. Plan B is almost there and > the only remaining problem is its insistence on the pre-announcement of > SSRCs. > > If we get rid of that requirement then all we need would be for the W3C > to make sure that the APIs have everything they need to allow apps to > retrieve SSRC information, send it remotely then pass it down to the > browser again when they receive it. > > I acknowledge that the simulcasting and FEC cases might be a bit > different, which is normal because they are about the resolution of > transport problems. I still think they could be solved with app-specific > signalling and the proper APIs but in this case it would also be worth > investigating the options of doing this through RTP/RTCP. > > Does any of this make any sense? > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb**** > > ** ** > --089e013c67061f307604dd24689f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Since webrtc is using ICE, the initial answer must have ar= rived before any media can be sent.

However, that = doesn't deal with cases where the SSRC is either unknown or can change.= An example would be where a media server is used to play files during a ca= ll. Each of the file replays can use a different SSRC.=A0


On 20 M= ay 2013 11:24, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

Hi,<= /p>

=A0<= /p>

Whatever mechanism we cho= ose for demuxing RTP packets, I think it is ok that one has to wait for the= SDP answer in order to figure out all information needed (e.g. the SSRC value used by the remote sender), and to possibly drop medi= a that is received before the SDP answer is received.<= /p>

=A0<= /p>

In theory this could caus= e clipping problem, but at least my experience is that it=92s not a problem= in reality, the reason being that the SDP answer if often sent (e.g. in a SIP 18x response) well before the remote media.<= /u>

=A0<= /p>

Regards,

=A0<= /p>

Christer

=A0<= /p>

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Kevin Dempsey
Sent: 20. toukokuuta 2013 11:54
To: Emil Ivov
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] A problem with both A and B

=A0

I would say that at present only the sending applica= tion knows what a stream is for. The receiving side needs to determine the = purpose by matching the RTP packets to the signalling the applications have= done.

=A0

In unbundled situations this is easy as the port it = arrives on makes it obvious. In bundled cases, you would have to ensure the= receiver knows some unique property of the RTP *before* it arrives. The be= st thing would be for the receiver to pick an identifier which, having been signalled in the offer to the sen= der, is included in every RTP packet (in a RTP extension header).=

=A0

Relying on SSRC signalling would mean that RTP sent = before the SSRC identity arrives would not be handled consistently with RTP= arriving after the SSRC identity.

=A0

On 17 May 2013 17:04, Emil Ivov <emcho@jitsi.org> wrote:<= u>

I've mentioned this in a couple of other threads= but I think it's
important so I am also posting it separately.

Both plan A and B currently describe semantics that would require O/A
exchanges every time a source is added or removed from a session.

Whether it is about adding a second webcam, or a conference participant
that leaves or joins, both schemes suggest that the remote party should
be notified with an updated SDP.

Plan A deals with this by manipulating m=3D lines, while plan B does it
with msid-s.

We are nowhere near consensus and I think that this fact alone is a
strong argument in favour of the following:

This is not a problem for rtcweb to solve.

We all have our own preferences for a solution and those come from the
different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on
the Web paradigm we would provide building blocks which can then be
assembled into specific solutions (rather than providing the solutions
themselves).

In other words: it is not our job to try and implant a signalling
protocol into O/A. Signalling is the job of the application.

Applications alone know the meaning of the stream that came from your
second web cam, or that of the tenth conference participant. They know
which conferencing topology they most care about. They have best
knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be
displayed to describe the streams they are currently getting.

Most importantly however: they are best placed to know how they'd like<= br> to communicate that information to their peers or IF they need to
communicate it at all.

Currently neither Plan A nor Plan B would let the application do its
job. However I do believe Plan B is closer.

If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and=
the only remaining problem is its insistence on the pre-announcement of
SSRCs.

If we get rid of that requirement then all we need would be for the W3C
to make sure that the APIs have everything they need to allow apps to
retrieve SSRC information, send it remotely then pass it down to the
browser again when they receive it.

I acknowledge that the simulcasting and FEC cases might be a bit
different, which is normal because they are about the resolution of
transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth
investigating the options of doing this through RTP/RTCP.

Does any of this make any sense?

Emil

--
https://jitsi.org=
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=

=A0


--089e013c67061f307604dd24689f-- From csp@csperkins.org Mon May 20 04:17:44 2013 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 C4A2721F90D2 for ; Mon, 20 May 2013 04:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.392 X-Spam-Level: X-Spam-Status: No, score=-106.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ8-0k1y2Q68 for ; Mon, 20 May 2013 04:17:39 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3555F21F8749 for ; Mon, 20 May 2013 04:17:39 -0700 (PDT) Received: from [130.209.247.112] (port=61249 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UeO5x-0007fb-75; Mon, 20 May 2013 12:17:37 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <5199F0A0.8020406@nostrum.com> Date: Mon, 20 May 2013 12:17:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5199F0A0.8020406@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 11:17:44 -0000 On 20 May 2013, at 10:45, Adam Roach wrote: > On 5/18/13 00:10, Martin Thomson wrote: >> On 16 May 2013 23:31, Harald Alvestrand wrote: >>> The demuxing is trivial. In fact, I don't think it's even necessary = to >>> describe it as "demux on PT"; you can't allow SSRC collision between = two >>> tracks with different PT anyway. >> Let's be very, very precise about this. >>=20 >> Demultiplexing is *always* performed based on SSRC. It's just that >> correlation with signaling components (the m-line in this case) might >> use of PT in the absence of prior knowledge of SSRC. >>=20 >> We didn't get this quite right in Plan A. >=20 > Yeah, that's a valid point. It's not really being proposed as a demux = point as much as a correlation token. Thanks for clearing that up -- we = should definitely clear that up in the next version of the document. Rather than try to overload the PT, I would suggest we define an = explicit correlation token that can be sent. Put something in RTCP SDES = and/or RTP header extensions, and in the SDP, to signal what RTP flow = corresponds to what m-line. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 20 04:22:41 2013 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 4541221F913E for ; Mon, 20 May 2013 04:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.418 X-Spam-Level: X-Spam-Status: No, score=-106.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b47pFVNzyGya for ; Mon, 20 May 2013 04:22:36 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCDD21F910D for ; Mon, 20 May 2013 04:22:34 -0700 (PDT) Received: from [130.209.247.112] (port=61269 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UeOAb-0001BW-Im; Mon, 20 May 2013 12:22:31 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <5199F032.9040101@nostrum.com> Date: Mon, 20 May 2013 12:22:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18F6AD0A-2D3F-44F5-900B-E7984D4AE85E@csperkins.org> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5199F032.9040101@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 11:22:42 -0000 On 20 May 2013, at 10:43, Adam Roach wrote: > On 5/17/13 03:15, Harald Alvestrand wrote: >> Since an argument that has been made in favour of Plan A is that it = is (supposedly) more compatible with deployed code, this interests me = greatly.=20 >=20 > The other, probably more important factor when we're talking about = legacy interop is that it will be hard (impossible?) to find *legacy* = implementations that use more than 32 streams -- making this pretty much = a non-issue from a legacy perspective. >=20 > However, I think we do need to be explicit that RTCWEB implementations = need to actually implement the AVT profile as specified, including the = ability to use 96 PTs. Do you want to propose some text for the rtp-usage draft that clarifies = this? If there's agreement, we can then include it.=20 --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Mon May 20 04:31:24 2013 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 6FE5221F9253 for ; Mon, 20 May 2013 04:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QPT+4dRCjgP for ; Mon, 20 May 2013 04:31:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C38121F9239 for ; Mon, 20 May 2013 04:31:15 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-ad-519a0980a872 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.AC.28930.0890A915; Mon, 20 May 2013 13:31:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Mon, 20 May 2013 13:31:12 +0200 From: Christer Holmberg To: Kevin Dempsey Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUxg7Crd1S7QwyEqM9DOrRHv1xJkNp1kAgAA50HD//+zsAIAAJJJw Date: Mon, 20 May 2013 11:31:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C374329@ESESSMB209.ericsson.se> References: <51965506.7050008@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374282@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.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvrW4D56xAgytLtSzW7JzAYnFz/lsW i7X/2tkdmD12zrrL7rFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgyls1byFRwSLPi9NSVbA2M SxS7GDk5JARMJGZd2cUMYYtJXLi3nq2LkYtDSOAwo8SV5w9ZIZwljBL75twCquLgYBOwkOj+ pw3SICKgI3Hw/mR2kDCzgIvE5n3xIGFhAUOJ3xdOMUOUGElcW7+fBcJ2k7i1vpcNxGYRUJVo +fwFrIZXwFfi18uHTBCrfjFKTP7+C2wmp0CgxKkLNiA1jEC3fT+1hgnEZhYQl7j1ZD4TxM0C Ekv2nIe6X1Ti5eN/rCCtEgKKEsv75SDK9SRuTJ3CBmFrSyxb+BpqraDEyZlPWCYwis1CMnUW kpZZSFpmIWlZwMiyipE9NzEzJ73ccBMjMGIObvmtu4Px1DmRQ4zSHCxK4ry92lMDhQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTDWpnD4y3yJPcXCnMl/RHOnUxQX8+pbJxzqb1lt/hv462zT rz8drm85+HsiXgWzXhPe+/HI2dlmHlkWr0/p2mTOm6/8c+E0s5sHRdmaq1d+kfozY4Pj+a6P s9NOqccrd8cl9up8N9Bq1iksNpTYmfxNY5VC99+O9tcaMddkU3t+Nbss7T5VMUmJpTgj0VCL uag4EQDlYaDwZgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 11:31:24 -0000 Hi, >Since webrtc is using ICE, the initial answer must have arrived before any= media can be sent. True. However, keep in mind that BUNDLE does currently not require ICE. >However, that doesn't deal with cases where the SSRC is either unknown or = can change. An example would be where a media server is used to play files = during a call. Each of the file replays can use a different SSRC.=A0 I assume that those files, from the receiver's perspective, will come from = the same remote IP address as the other media within the call? Regards, Christer On 20 May 2013 11:24, Christer Holmberg wr= ote: Hi, =A0 Whatever mechanism we choose for demuxing RTP packets, I think it is ok tha= t one has to wait for the SDP answer in order to figure out all information= needed (e.g. the SSRC value used by the remote sender), and to possibly dr= op media that is received before the SDP answer is received. =A0 In theory this could cause clipping problem, but at least my experience is = that it's not a problem in reality, the reason being that the SDP answer if= often sent (e.g. in a SIP 18x response) well before the remote media. =A0 Regards, =A0 Christer =A0 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Kevin Dempsey Sent: 20. toukokuuta 2013 11:54 To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] A problem with both A and B =A0 I would say that at present only the sending application knows what a strea= m is for. The receiving side needs to determine the purpose by matching the= RTP packets to the signalling the applications have done. =A0 In unbundled situations this is easy as the port it arrives on makes it obv= ious. In bundled cases, you would have to ensure the receiver knows some un= ique property of the RTP *before* it arrives. The best thing would be for t= he receiver to pick an identifier which, having been signalled in the offer= to the sender, is included in every RTP packet (in a RTP extension header)= . =A0 Relying on SSRC signalling would mean that RTP sent before the SSRC identit= y arrives would not be handled consistently with RTP arriving after the SSR= C identity. =A0 On 17 May 2013 17:04, Emil Ivov wrote: I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately. Both plan A and B currently describe semantics that would require O/A exchanges every time a source is added or removed from a session. Whether it is about adding a second webcam, or a conference participant that leaves or joins, both schemes suggest that the remote party should be notified with an updated SDP. Plan A deals with this by manipulating m=3D lines, while plan B does it with msid-s. We are nowhere near consensus and I think that this fact alone is a strong argument in favour of the following: This is not a problem for rtcweb to solve. We all have our own preferences for a solution and those come from the different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on the Web paradigm we would provide building blocks which can then be assembled into specific solutions (rather than providing the solutions themselves). In other words: it is not our job to try and implant a signalling protocol into O/A. Signalling is the job of the application. Applications alone know the meaning of the stream that came from your second web cam, or that of the tenth conference participant. They know which conferencing topology they most care about. They have best knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be displayed to describe the streams they are currently getting. Most importantly however: they are best placed to know how they'd like to communicate that information to their peers or IF they need to communicate it at all. Currently neither Plan A nor Plan B would let the application do its job. However I do believe Plan B is closer. If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and the only remaining problem is its insistence on the pre-announcement of SSRCs. If we get rid of that requirement then all we need would be for the W3C to make sure that the APIs have everything they need to allow apps to retrieve SSRC information, send it remotely then pass it down to the browser again when they receive it. I acknowledge that the simulcasting and FEC cases might be a bit different, which is normal because they are about the resolution of transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth investigating the options of doing this through RTP/RTCP. Does any of this make any sense? Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =A0 From adam@nostrum.com Mon May 20 05:19:30 2013 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 2D70621F859B for ; Mon, 20 May 2013 05:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nao8sC-hI+JF for ; Mon, 20 May 2013 05:19:29 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9DA21F856D for ; Mon, 20 May 2013 05:19:29 -0700 (PDT) Received: from Orochi.local (203-69-99-17.HINET-IP.hinet.net [203.69.99.17] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4KCJIvO085997 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 May 2013 07:19:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <519A14C6.7000009@nostrum.com> Date: Mon, 20 May 2013 20:19:18 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5199F0A0.8020406@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 203.69.99.17 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 12:19:30 -0000 On 5/20/13 19:17, Colin Perkins wrote: > On 20 May 2013, at 10:45, Adam Roach wrote: >> On 5/18/13 00:10, Martin Thomson wrote: >> >>> Let's be very, very precise about this. >>> >>> Demultiplexing is *always* performed based on SSRC. It's just that >>> correlation with signaling components (the m-line in this case) might >>> use of PT in the absence of prior knowledge of SSRC. >>> >>> We didn't get this quite right in Plan A. >> Yeah, that's a valid point. It's not really being proposed as a demux point as much as a correlation token. Thanks for clearing that up -- we should definitely clear that up in the next version of the document. > > Rather than try to overload the PT, I would suggest we define an explicit correlation token that can be sent. Put something in RTCP SDES and/or RTP header extensions, and in the SDP, to signal what RTP flow corresponds to what m-line. > That kind of defeats some of the purpose here, which includes working with existing deployed implementations. /a From kevindempsey70@gmail.com Mon May 20 05:52:01 2013 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 73D7F21F9180 for ; Mon, 20 May 2013 05:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmmZZWg438wo for ; Mon, 20 May 2013 05:51:53 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB1221F912C for ; Mon, 20 May 2013 05:51:50 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id v20so6504642lbc.30 for ; Mon, 20 May 2013 05:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lmckWNSuyZg7x8lWksFvYfQ02gRmKMN6ROdMb8Tnqpk=; b=xA3UdTwcmvbax1VTMIg48HgJxZawU59F5jEavhf9ue4Umb4wzoXAzoebY9PCbEnpVG Gws22oOCf3CefhwdMClmDwnHSzRAyyDSheYdwLEAWcuJcAODqkQP0M5Z5mEaxieTGW5S bhnyP5xGPSgw4mt6A40hVdh0z/k9X7eTZRx6wX1tyeeaBUkETk3sjg7xdfNKum91aAE3 uA7LmTltoSd4FQ3JNSem/1Rkw4SreHNzu6W4HW3b96owzFW1pLHVPZQY6Mbnpi5EB0IY mxvz8hBDmHr2QXxjZmKQII1O40gjS93h/1unPGQj6N3fguBuj3tsg/T+mLGfHJrVFXez WK7Q== MIME-Version: 1.0 X-Received: by 10.112.6.6 with SMTP id w6mr3967702lbw.123.1369054309052; Mon, 20 May 2013 05:51:49 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Mon, 20 May 2013 05:51:48 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C374329@ESESSMB209.ericsson.se> References: <51965506.7050008@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374282@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374329@ESESSMB209.ericsson.se> Date: Mon, 20 May 2013 13:51:48 +0100 Message-ID: From: Kevin Dempsey To: Christer Holmberg Content-Type: multipart/alternative; boundary=14dae93d9736c4f62804dd25cbed Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 12:52:01 -0000 --14dae93d9736c4f62804dd25cbed Content-Type: text/plain; charset=ISO-8859-1 >I assume that those files, from the receiver's perspective, will come from the same remote IP address as the other media within the call? Yes, the RTP payloads are forwarded intact so all have the same source IP/port. On 20 May 2013 12:31, Christer Holmberg wrote: > Hi, > > >Since webrtc is using ICE, the initial answer must have arrived before > any media can be sent. > > True. > > However, keep in mind that BUNDLE does currently not require ICE. > > >However, that doesn't deal with cases where the SSRC is either unknown or > can change. An example would be where a media server is used to play files > during a call. Each of the file replays can use a different SSRC. > > I assume that those files, from the receiver's perspective, will come from > the same remote IP address as the other media within the call? > > Regards, > > Christer > > > > > On 20 May 2013 11:24, Christer Holmberg > wrote: > Hi, > > Whatever mechanism we choose for demuxing RTP packets, I think it is ok > that one has to wait for the SDP answer in order to figure out all > information needed (e.g. the SSRC value used by the remote sender), and to > possibly drop media that is received before the SDP answer is received. > > In theory this could cause clipping problem, but at least my experience is > that it's not a problem in reality, the reason being that the SDP answer if > often sent (e.g. in a SIP 18x response) well before the remote media. > > Regards, > > Christer > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Kevin Dempsey > Sent: 20. toukokuuta 2013 11:54 > To: Emil Ivov > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] A problem with both A and B > > I would say that at present only the sending application knows what a > stream is for. The receiving side needs to determine the purpose by > matching the RTP packets to the signalling the applications have done. > > In unbundled situations this is easy as the port it arrives on makes it > obvious. In bundled cases, you would have to ensure the receiver knows some > unique property of the RTP *before* it arrives. The best thing would be for > the receiver to pick an identifier which, having been signalled in the > offer to the sender, is included in every RTP packet (in a RTP extension > header). > > Relying on SSRC signalling would mean that RTP sent before the SSRC > identity arrives would not be handled consistently with RTP arriving after > the SSRC identity. > > On 17 May 2013 17:04, Emil Ivov wrote: > I've mentioned this in a couple of other threads but I think it's > important so I am also posting it separately. > > Both plan A and B currently describe semantics that would require O/A > exchanges every time a source is added or removed from a session. > > Whether it is about adding a second webcam, or a conference participant > that leaves or joins, both schemes suggest that the remote party should > be notified with an updated SDP. > > Plan A deals with this by manipulating m= lines, while plan B does it > with msid-s. > > We are nowhere near consensus and I think that this fact alone is a > strong argument in favour of the following: > > This is not a problem for rtcweb to solve. > > We all have our own preferences for a solution and those come from the > different use cases we are planning on addressing and the different apps > we are planning to build. The promise of WebRTC is that, by building on > the Web paradigm we would provide building blocks which can then be > assembled into specific solutions (rather than providing the solutions > themselves). > > In other words: it is not our job to try and implant a signalling > protocol into O/A. Signalling is the job of the application. > > Applications alone know the meaning of the stream that came from your > second web cam, or that of the tenth conference participant. They know > which conferencing topology they most care about. They have best > knowledge about what streams they are currently rendering and which ones > they don't need. They know that the names Adam and Justin should be > displayed to describe the streams they are currently getting. > > Most importantly however: they are best placed to know how they'd like > to communicate that information to their peers or IF they need to > communicate it at all. > > Currently neither Plan A nor Plan B would let the application do its > job. However I do believe Plan B is closer. > > If we agree that browsers would give applications the latitude that's > necessary to address these issues with app specific signalling, then the > SDP shouldn't change when they are doing it. Plan B is almost there and > the only remaining problem is its insistence on the pre-announcement of > SSRCs. > > If we get rid of that requirement then all we need would be for the W3C > to make sure that the APIs have everything they need to allow apps to > retrieve SSRC information, send it remotely then pass it down to the > browser again when they receive it. > > I acknowledge that the simulcasting and FEC cases might be a bit > different, which is normal because they are about the resolution of > transport problems. I still think they could be solved with app-specific > signalling and the proper APIs but in this case it would also be worth > investigating the options of doing this through RTP/RTCP. > > Does any of this make any sense? > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --14dae93d9736c4f62804dd25cbed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>I assume that those files, from the receiver's perspective, will = come from the same remote IP address as the other media within the call?
Yes, the RTP pa= yloads are forwarded intact so all have the same source IP/port.


On 20= May 2013 12:31, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:
Hi,

>Since webrtc is using ICE, the initial answer must have arrived before = any media can be sent.

True.

However, keep in mind that BUNDLE does currently not require ICE.

>However, that doesn't deal with cases where the SSRC is either unkn= own or can change. An example would be where a media server is used to play= files during a call. Each of the file replays can use a different SSRC.=A0=

I assume that those files, from the receiver's perspective, will = come from the same remote IP address as the other media within the call?
Regards,

Christer




On 20 May 2013 11:24, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
=A0
Whatever mechanism we choose for demuxing RTP packets, I think it is ok tha= t one has to wait for the SDP answer in order to figure out all information= needed (e.g. the SSRC value used by the remote sender), and to possibly dr= op media that is received before the SDP answer is received.
=A0
In theory this could cause clipping problem, but at least my experience is = that it's not a problem in reality, the reason being that the SDP answe= r if often sent (e.g. in a SIP 18x response) well before the remote media.<= br> =A0
Regards,
=A0
Christer
=A0
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of Kevin Dempsey
Sent: 20. toukokuuta 2013 11:54
To: Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] A problem with both A and B
=A0
I would say that at present only the sending application knows what a strea= m is for. The receiving side needs to determine the purpose by matching the= RTP packets to the signalling the applications have done.
=A0
In unbundled situations this is easy as the port it arrives on makes it obv= ious. In bundled cases, you would have to ensure the receiver knows some un= ique property of the RTP *before* it arrives. The best thing would be for t= he receiver to pick an identifier which, having been signalled in the offer= to the sender, is included in every RTP packet (in a RTP extension header)= .
=A0
Relying on SSRC signalling would mean that RTP sent before the SSRC identit= y arrives would not be handled consistently with RTP arriving after the SSR= C identity.
=A0
On 17 May 2013 17:04, Emil Ivov <emch= o@jitsi.org> wrote:
I've mentioned this in a couple of other threads but I think it's important so I am also posting it separately.

Both plan A and B currently describe semantics that would require O/A
exchanges every time a source is added or removed from a session.

Whether it is about adding a second webcam, or a conference participant
that leaves or joins, both schemes suggest that the remote party should
be notified with an updated SDP.

Plan A deals with this by manipulating m=3D lines, while plan B does it
with msid-s.

We are nowhere near consensus and I think that this fact alone is a
strong argument in favour of the following:

This is not a problem for rtcweb to solve.

We all have our own preferences for a solution and those come from the
different use cases we are planning on addressing and the different apps we are planning to build. The promise of WebRTC is that, by building on
the Web paradigm we would provide building blocks which can then be
assembled into specific solutions (rather than providing the solutions
themselves).

In other words: it is not our job to try and implant a signalling
protocol into O/A. Signalling is the job of the application.

Applications alone know the meaning of the stream that came from your
second web cam, or that of the tenth conference participant. They know
which conferencing topology they most care about. They have best
knowledge about what streams they are currently rendering and which ones they don't need. They know that the names Adam and Justin should be
displayed to describe the streams they are currently getting.

Most importantly however: they are best placed to know how they'd like<= br> to communicate that information to their peers or IF they need to
communicate it at all.

Currently neither Plan A nor Plan B would let the application do its
job. However I do believe Plan B is closer.

If we agree that browsers would give applications the latitude that's necessary to address these issues with app specific signalling, then the SDP shouldn't change when they are doing it. Plan B is almost there and=
the only remaining problem is its insistence on the pre-announcement of
SSRCs.

If we get rid of that requirement then all we need would be for the W3C
to make sure that the APIs have everything they need to allow apps to
retrieve SSRC information, send it remotely then pass it down to the
browser again when they receive it.

I acknowledge that the simulcasting and FEC cases might be a bit
different, which is normal because they are about the resolution of
transport problems. I still think they could be solved with app-specific signalling and the proper APIs but in this case it would also be worth
investigating the options of doing this through RTP/RTCP.

Does any of this make any sense?

Emil

--
https://jitsi.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
=A0


--14dae93d9736c4f62804dd25cbed-- From christer.holmberg@ericsson.com Mon May 20 06:32:15 2013 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 5B57021F91B8 for ; Mon, 20 May 2013 06:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYXtwqGAKILg for ; Mon, 20 May 2013 06:32:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2C721F90F1 for ; Mon, 20 May 2013 06:32:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-e3-519a25d640eb Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 37.8E.28930.6D52A915; Mon, 20 May 2013 15:32:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 20 May 2013 15:32:06 +0200 From: Christer Holmberg To: Adam Roach , Colin Perkins Thread-Topic: [rtcweb] Plan A, respun Thread-Index: AQHOS1D4OJ9/f3yaDU2ZIoLMuUfuQ5j6/lQAgAYylwCAACb0gIAGqKWAgAANLwCAAAQgAIAACXGAgABGrACAAHZegIAAoYQAgARLbQCAABnaAIAAET4AgAA07+A= Date: Mon, 20 May 2013 13:32:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C374483@ESESSMB209.ericsson.se> References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5199F0A0.8020406@nostrum.com> <519A14C6.7000009@nostrum.com> In-Reply-To: <519A14C6.7000009@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre411VmBBicfWFns+buI3WL5yxOM Fmv/tbM7MHtMu3+fzWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgytj93Lygn7Oif/ta1gbG RexdjJwcEgImEv1N3WwQtpjEhXvrgWwuDiGBw4wSczc9ZoRwljBKrPxxCKiDg4NNwEKi+582 SIOIgIvE0w/3mUFsZgF1iTuLz4GVCAuoSFyaWgxiigioSkz9zwUyRUSgi1Fi8+c9TCDlLEDx 1c+WgLXyCvhKHH/yhxVi1XYWic3LPoIdxymgLfFj/wqw4xiBjvt+ag0TxC5xiVtP5jNBHC0g sWTPeWYIW1Ti5eN/rCCLJQQUJZb3y0GU60gs2P2JDcLWlli28DXUXkGJkzOfsExgFJuFZOos JC2zkLTMQtKygJFlFSN7bmJmTnq54SZGYMwc3PJbdwfjqXMihxilOViUxHl7tacGCgmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamBM0zByNNvK0ur+eeUHkRjjhljllkXuJmWlgsrJITd+7fLK klkSfrWGM78hc0LKKZVc+Qa3aNb0tZOC1u/nnfLd9Nv0wDaF5buv+pfdeBZXa2F6sC5LPpdD armdw9Vrt9eW7a+q6W5VnfPje+cGY/77cw6cZ2X1VGJITUpSXhDwdcrJAzP8TyixFGckGmox FxUnAgCmCeNJZwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 13:32:15 -0000 Hi, >>>> Let's be very, very precise about this. >>>> >>>> Demultiplexing is *always* performed based on SSRC. It's just that=20 >>>> correlation with signaling components (the m-line in this case)=20 >>>> might use of PT in the absence of prior knowledge of SSRC. >>>> >>>> We didn't get this quite right in Plan A. >>> Yeah, that's a valid point. It's not really being proposed as a demux p= oint as much as a correlation token. Thanks for clearing that up -- we shou= ld definitely clear that up in the next version of the document. >> >> Rather than try to overload the PT, I would suggest we define an explici= t correlation token that can be sent. Put something in RTCP SDES=20 >> and/or RTP header extensions, and in the SDP, to signal what RTP flow co= rresponds to what m-line. > > That kind of defeats some of the purpose here, which includes working wit= h existing deployed implementations. Existing deployments will use different port numbers, so you would be able = to separate media belonging to different m- lines (as different 5-tuples wi= ll be used), so you would not need to use the extension. Regards, Christer From ron.even.tlv@gmail.com Mon May 20 06:45:59 2013 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 68F7B21F93DA for ; Mon, 20 May 2013 06:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyStsgzMuCzv for ; Mon, 20 May 2013 06:45:58 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 571BE21F93BA for ; Mon, 20 May 2013 06:45:44 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id c10so2093010wiw.9 for ; Mon, 20 May 2013 06:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=RyHTs3oGLB6Xf6E/+BCD7zzOOyxPZetglMhcVbw8KU8=; b=wYpSi6l707W9uQ776Wx2GyKWHWN9FyA0Hao2WBM0oM2+ichw69KPePah86a/gKKV5c dEDKAolOTKjv44c0SesimcfNxS3jExB3Sxf9hsR/8zinTti7u9SILkYjpTXSaIQuJg6p Aw5QwfOCF+FkbnpwuTGKoMnPAYUajWvD28MEclWXu1CzgTB8M/ZjdiD0UJzpjPaeyO4a Aibf79K/2dnf2cfE2ystu58+DJngU8JulXS2UZas4s7Hbetn2X57IaWb4gxXb04Kk826 DhzCVIcPR7d0AuK4z7ucOY8p+ZZCauNsCTBqISR/WZUO1+GUxLtgrRpbF7SZijexRMBI pqyQ== X-Received: by 10.180.97.106 with SMTP id dz10mr7373825wib.2.1369057543502; Mon, 20 May 2013 06:45:43 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id e5sm14856772wiy.5.2013.05.20.06.45.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 May 2013 06:45:42 -0700 (PDT) From: "Roni Even" To: "'Adam Roach'" , "'Emil Ivov'" References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5196460B.9000808@jitsi.org> <519654A5.1050406@jitsi.org> <5199F10B.5030102@nostrum.com> In-Reply-To: <5199F10B.5030102@nostrum.com> Date: Mon, 20 May 2013 16:44:41 +0300 Message-ID: <00c001ce5560$2fb81e60$8f285b20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFGcIWRrin1agXBJhH0vjVWcsv/GwFZH5F1ArTIEZsCkglGJQFrDOq+AaUAEiABlWacbQGpKnBUAp1LxR8CUhS7fgJ4JONZAqbeKfEBJb4I4AGM2sK3AiWscOiZPzUP8A== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 13:45:59 -0000 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: 20 May, 2013 12:47 PM To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun On 5/18/13 00:02, Emil Ivov wrote: > > On 17.05.13, 18:08, Eric Rescorla wrote: >> On Fri, May 17, 2013 at 8:00 AM, Emil Ivov > > wrote: >> >> >> On 17.05.13, 16:07, Eric Rescorla wrote:=line. >> >> >> > then presumably you need to follow this rule to ensure interop, no? >> >> Therefore, the interop part with the "many" endpoints seems to be >> covered already. One still needs to find ways of handling and >> potentially gatewaying ICE and SRTP for many of them but that's a >> different matter. O/A-wise we seem to have consensus on how to do the >> case with the two m= lines that each carry one track. >> >> It seems to me that we have now moved beyond that. >> >> >> The question is how an endpoint which wishes fo offer more than one >> audio and one video does so in a way that doesn't cause older >> endpoints to choke. > I might be misunderstanding or missing something, but isn't it clear > that, if you are trying not to choke anyone, the first thing to do > would be to stick to a single m= line for audio and a single m= line for video? > >Not if you're talking to a device that expects three media streams -- such things have historically used three m=video sections (one for each stream). Which >is kind of the reason we're specifying Plan A the way we are. When a device offers three video m-lines and the other EP can receive only one there is no interoperability specified and this will be a more common case. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ron.even.tlv@gmail.com Mon May 20 06:50:07 2013 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 BEEE721F933B for ; Mon, 20 May 2013 06:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1Bnc3qTU3vw for ; Mon, 20 May 2013 06:50:05 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10D21F9133 for ; Mon, 20 May 2013 06:50:02 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so4940398wgg.21 for ; Mon, 20 May 2013 06:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=c/1aQJ2JJglnvCGPLt5H56gKJ8syOEHp3gEiMF0QVm0=; b=USr8FehrUOorRB8QnOuVnZka2m+/o8FDur+lzXE6YjjD3gpCVX0lW3bVNzXW/13cD7 wwcZu3GVr0Abq+cegkFMm33kqjzu5rMn2T9xdbczh2D/+TXwJWEZQPtt40iyf6E9vD4y nDG2QJhdz0k/Ftj9GfeIIrApArPK+j/vq2vaF7ejMlfD7roF/476RNGDkN0yIX0vwYOJ s8Wh+VizjLFRnAsdtFZtyiBt+Bxr2uES/MUOgnsSeuzPz3lhxcRVze2R3Y8MIw3TOUAk 5zxuP5PDtW6xh5NQgiBJWbfKWll421pxCo1jgwwEnP4XnPgVNgD8z+R7rmNf1pQgEg9V 4/Sw== X-Received: by 10.180.198.175 with SMTP id jd15mr14244401wic.28.1369057798876; Mon, 20 May 2013 06:49:58 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id cw8sm14866364wib.7.2013.05.20.06.49.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 May 2013 06:49:58 -0700 (PDT) From: "Roni Even" To: "'Adam Roach'" , "'Colin Perkins'" References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> <5195CEDF.9040109@alvestrand.no> <5199F0A0.8020406@nostrum.com> <519A14C6.7000009@nostrum.com> In-Reply-To: <519A14C6.7000009@nostrum.com> Date: Mon, 20 May 2013 16:48:57 +0300 Message-ID: <00c101ce5560$c829b140$587d13c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFGcIWRrin1agXBJhH0vjVWcsv/GwFZH5F1ArTIEZsCkglGJQFrDOq+AaUAEiABlWacbQGpKnBUAp1LxR8CUhS7fgHURw3HAfAvQnkCLpQOUgJHXTMamU0dM7A= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 13:50:07 -0000 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: 20 May, 2013 3:19 PM To: Colin Perkins Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan A, respun On 5/20/13 19:17, Colin Perkins wrote: > On 20 May 2013, at 10:45, Adam Roach wrote: >> On 5/18/13 00:10, Martin Thomson wrote: >> >>> Let's be very, very precise about this. >>> >>> Demultiplexing is *always* performed based on SSRC. It's just that >>> correlation with signaling components (the m-line in this case) >>> might use of PT in the absence of prior knowledge of SSRC. >>> >>> We didn't get this quite right in Plan A. >> Yeah, that's a valid point. It's not really being proposed as a demux point as much as a correlation token. Thanks for clearing that up -- we should definitely clear that up in the next version of the document. > > Rather than try to overload the PT, I would suggest we define an explicit correlation token that can be sent. Put something in RTCP SDES and/or RTP header extensions, and in the SDP, to signal what RTP flow corresponds to what m-line. > >That kind of defeats some of the purpose here, which includes working with existing deployed implementations. I do not understand why it breaks. When existing implementation receive three m-lines it is not specified what behavior they will take if they support different number of RTP streams and there is no specification about how they will render the three m-lines (no mapping) /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From pkyzivat@alum.mit.edu Mon May 20 09:17:37 2013 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 C802121F93D7 for ; Mon, 20 May 2013 09:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ic5br4ZCviR for ; Mon, 20 May 2013 09:17:33 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 032E521F93E9 for ; Mon, 20 May 2013 09:17:31 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id eBTS1l0031HzFnQ58GHXD0; Mon, 20 May 2013 16:17:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id eGHX1l00F3ZTu2S3aGHXg8; Mon, 20 May 2013 16:17:31 +0000 Message-ID: <519A4C9A.6020501@alum.mit.edu> Date: Mon, 20 May 2013 12:17:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369066651; bh=7BEo0rjt8EO20Fm9kfyyXJgH0Rzw7qRdYvsqx4/Iq+A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HueRDcgM6A3VsnfxnanpdowVL7WbJcfpp9yFfI9f5X0Q2UW/z8L6cu2ZVl/ik6PDr +Afchxtc8S42sDHo2WIOvhEK76+E8qQuYeTW9pcBtbG4OSBlAFM3QYMZImyppSSt35 CFmLI2ghQbcU7PufnNaGm+9rbnBqJoPak3cZSHrv5iuZbbWZVT4MuowQ7kV65bwmds G48wWJxPdpZCpjlTd7/Qwu7/N79c9HEfxI1zTvyNNFEjTMqYBhr89o+H2N3lcUC/R1 vXQIynkviwpgFAQHbGbyAkR6QAhGAAf9gVxSV+HiifIcM5N6gSSpD175+WNIwHCG6u bTAyhHbbSIhhQ== Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 16:17:37 -0000 On 5/20/13 2:48 AM, Christer Holmberg wrote: > Hi, > > I don't think it's a BUNDLE issue whether adding/removing of streams require an O/A exchange or not. It's an SDP, and SDP O/A, issue. > > BUNDLE is about sharing a 5-tuple. I don't agree. RTP is already able to support multiple RTP streams sharing an RTP session (and 5-tuple). What BUNDLE is about is describing that in SDP. And that includes how SDP O/A works. Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: 17. toukokuuta 2013 23:50 > To: Bernard Aboba > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] A problem with both A and B > >> "Dale R. Worley" wrote: >> DES F11 It must be possible to add and remove one way video flows >> within the bundle without requiring an additional offer/answer >> cycle. > > I'm not sure why this speaks specifically about video... > > On 17 May 2013 13:21, Bernard Aboba wrote: >> It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange). > > This is different I think. Responding to congestion only requires that it be possible to stop sending a given stream. (Or maybe crank down resolution or frame rate.) > > This item talks about addition. That's an entirely different proposition. As long as we assume constraints (you don't need to re-ICE a new transport for the stream, you don't use new packet types and codec profiles), this could be possible. But to get WebRTC to support this requires API changes. > _______________________________________________ > 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 pkyzivat@alum.mit.edu Mon May 20 09:47:08 2013 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 1D7AE21F967D for ; Mon, 20 May 2013 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.267 X-Spam-Level: X-Spam-Status: No, score=0.267 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=0.6, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORb5hlFpyouF for ; Mon, 20 May 2013 09:46:54 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2EB21F95FC for ; Mon, 20 May 2013 09:46:54 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id eB6o1l0031YDfWL5BGmt2h; Mon, 20 May 2013 16:46:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id eGmt1l00d3ZTu2S3gGmtwm; Mon, 20 May 2013 16:46:53 +0000 Message-ID: <519A537C.30908@alum.mit.edu> Date: Mon, 20 May 2013 12:46:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51965506.7050008@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369068413; bh=2RzN0sfydmyYEoqSof1OWTVK2RqOr2sNehjygKqDcdI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Pz8rpl62ZtfMtJ2dCUfuQHf3Mjkd3O7Y4cMh0kV8ormQFywgQnzO04wKr0H4Vp8Nq PeICnCdfDkZSqyvbsJj7J2ND2K0fDrlbOQmRlDRg3H+vh4jlDQzkvTzMlCdUtuZhiK I1/8D1PHOuSQqLw1vNCMJc3LbJllxx6MpwgYZvPiCjoBQifhOuHUv30eKLHYDpzXhS KCRpCQvmm0ltuzGHY9lwtXzl+uAst47VgORXRHok5XAW528eh64G5IGtChuqBQYA7G OiY1xPhdr2SfkxfowArwSqU9SKZ30Q8WuwgwXOQ3ZYAf5dgQp4KuoGgNNwEDS+uFqj npR5Rn3G4vAzQ== Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 16:47:08 -0000 On 5/20/13 4:53 AM, Kevin Dempsey wrote: > I would say that at present only the sending application knows what a > stream is for. The receiving side needs to determine the purpose by > matching the RTP packets to the signalling the applications have done. ISTM that the legacy cases have depended upon doing this in a simplistic way. E.g., the app only supports one audio media stream to be played out over one audio device. So it refuses anything other than a single audio m-line and then maps all the audio packets it receives, regardless of SSRC, to that one device. So it needs minimal signaling. This has gradually evolved to slightly more complex cases, such as audio+video using similar logic. The a=content attribute was added to cover simple cases of multiple media of the same type, but still assuming a separate m-line for each device. All of this assumes that there is a very small range of fundamentally different applications, so signaling is not used much to distinguish them. But clearly this is beginning to break down. ISTM the current plan is to require that the two ends of a session be running the same logical application, and that they then define how to sort out the use of multiple media in an application-specific way. This is what both CLUE and RTCWEB seem to be doing. In the CLUE case the assumption is that initial SIP session setup verifies if the assumption is true, and then defines different actions if it is or isn't. In the case of RTCWEB, I guess the assumption is that it is probably a single web server application controlling both ends. But in cases where that is not true - gatewaying to the sip world - I guess this is left for the web server to figure out. I don't know how this is going to work when a Google+ with no Facebook account wants to interact with a Facebook user that has no Google+ account. ISTM in that case you need separate but equivalent web applications on both providers, and somehow they still need to have a consistent signaling mechanism between them. Thanks, Paul From pkyzivat@alum.mit.edu Mon May 20 10:00:16 2013 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 6E7A721F9682 for ; Mon, 20 May 2013 10:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MepzqPssEm7H for ; Mon, 20 May 2013 10:00:10 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91021F93C8 for ; Mon, 20 May 2013 10:00:10 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id eBeo1l0011swQuc55H09RZ; Mon, 20 May 2013 17:00:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id eH091l00T3ZTu2S3bH09vS; Mon, 20 May 2013 17:00:09 +0000 Message-ID: <519A5699.4070808@alum.mit.edu> Date: Mon, 20 May 2013 13:00:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> <51954162.70909@alvestrand.no> <5195EA95.3030007@jitsi.org> In-Reply-To: <5195EA95.3030007@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369069209; bh=yGND8jVgyA4i1z5anZ7+69cawi080XFCY4BUqjo27O4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r9/ojiS6VagXRHHymmAh9hC7GpGHRWHVw+YK7SYwaLnu1u35tPPeOrlVw11fvQUq+ MKxzTGzLzaluFjz9Y0PnzZAk2/Ij4uJ1IPc8B6QNGzaH+UqQkRWLQHUUgnLkGrLz8Q 418wJ0Ni3I/fs4SgILM1SzD9wHLp1LAzSkf2OMay7YV/9T1GG7VuPzEGhDLHjKCBj2 1+mJ1T+oo4aOE/OxM1kVZzenx/Ad+bpBYp99GhKqpgVHQfLGAXyeq4n+o4hTLhNudi gndDaFjLvI3S2kKx6+HnSYYy4XA8pXirlSFD6NeJIJwkTwTehiAh2yWtx0sAALaxc4 uhQz8OpST/IwQ== Subject: Re: [rtcweb] Common ways of handling video conferences? (Re: Why requiring pre-announcement) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 17:00:16 -0000 On 5/17/13 4:30 AM, Emil Ivov wrote: > On 16.05.13, 23:28, Harald Alvestrand wrote: >> On 05/16/2013 09:22 PM, Emil Ivov wrote: >>>> Then it is another >>>>> question if it happens via SDP or via RTP header extensions or some >>>>> other means. >>>>> >>>>> There was a discussion at the Stockholm rtcweb interim on what >>>>> topologies that would be supported, but I fail to remember if this case >>>>> was included or excluded. >>> I couldn't find the discussion (in what WG did it happen?) but >>> topologies based on RTP translators of one sort or another seem to be >>> the default way of handling video conferencing these days so I don't see >>> how we could possibly rule them out. >>> >> >> This is an interesting statement. I've also heard the claim that "RTP >> translators hardly exist outside the lab" - I think that quip was >> referring to RFC 5117 section 3.3 Topo-Trn-Translators, the story may be >> different for Topo-Media-Translators - but I thought the most common >> form was the section 3.4 Topo-Mixer? > > Until recently, yes certainly, mixers were prevalent (which is arguably > part of the reason why very few people had access to video conferencing). > > I think we'd all agree that this doesn't seem to be the case any longer > and that for various reasons (including cost, quality and flexibility), > most of the conferencing solutions today prefer shifting packets rather > than mixing content. I would like to understand: when "most" is used in this discussion, what are we measuring? - number of distinct implementations (code bases) using this approach? - number of conference sessions set up using this approach? - number of conference user-minutes using this approach? - something else I'm asking because I have no idea and I'm curious. Thanks, Paul From spromano@unina.it Mon May 20 10:11:42 2013 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 1EF2921F96CA; Mon, 20 May 2013 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHKq8d3CV6TI; Mon, 20 May 2013 10:11:37 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC28821F96B9; Mon, 20 May 2013 10:11:34 -0700 (PDT) Received: from [143.225.162.130] ([143.225.162.130]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r4KHBWVP023559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 19:11:32 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4" From: Simon Pietro Romano In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> Date: Mon, 20 May 2013 19:11:31 +0200 Message-Id: <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 20 May 2013 17:11:42 -0000 --Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I keep on thinking that the solution depicted in = http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt = deserves attention. Simon Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: > Regarding the HTTP fallback and whether this could be adapted to be a = TURN over HTTP based solution then I think the same comments that were = made on the TURN over websockets apply. What are the benefits of = creating a new transport for TURN over what we can do using HTTP Connect = as described in = http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations= -00. >=20 > Having said that I am really happy we are having this debate as we = really need to find a solution here that the browser vendors will = implement so I would really like to know which options they prefer. >=20 > I really hope we can get = draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to = document whatever the working group agrees on being the right solution. >=20 > Regards > Andy >=20 >=20 >> -----Original Message----- >> From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] >> Sent: 20 May 2013 10:15 >> To: Gustavo Garc=EDa >> Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >>=20 >> Il giorno Sun, 19 May 2013 23:20:41 -0700 >> Gustavo Garc=EDa ha scritto: >>=20 >>> I agree that TURN over websockets doesn't solve much more scenarios >>> than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing >>> it over HTTP that aside of philosophical discussions would be the >>> solution with better success rate? Otherwise we will have to >>> continue answering for another 10 years "why is this app not working >>> if skype does". >>>=20 >>> Something like this draft sent some months ago but perhaps for TURN >>> instead of direct connections: >>> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >>>=20 >>=20 >>=20 >> When I submitted that draft this summer, I had that exact purpose in >> mind, that is taking care of corner edge cases like restrictive = proxies >> and the like. Of course it was not meant to be a solution, just a way >> to foster discussion in that direction. In that discussion I also >> mentioned some work we did about this in the past, which in part >> apparently ended up in = draft-hutton-rtcweb-nat-firewall-considerations: >>=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html >>=20 >> At the time most people in the ML thought it was either too useless, >> too complex or even harmful, considering it could be considered as a >> "sneaky" way to circumvent rules added by a network administrator, = and >> so unacceptable. Anyway, as I said back then, a solution like this >> doesn't have to be sneaky, and it could very well be conceived in = order >> to be admin-friendly rather than have a parrot and a wooden leg. >>=20 >> Whether we actually need something like this or TURN-over-443 is = enough >> I don't know: I still think it may be useful to tackle scenarios = where >> everything else fails (the "skype works here" effect), so I'd be glad >> to be of help in that direction if needed. >>=20 >> Lorenzo >>=20 >>=20 >>=20 >>> On 16/05/2013, at 01:28, Hutton, Andrew wrote: >>>=20 >>>> I agree with Bernard's comments regarding the impact of DPI but of >>>> course such DPI devices do what they do and we can't and even don't >>>> want to stop them from doing it. However for the case when policy >>>> is such that the firewall will only allow traffic to traverse that >>>> comes from the HTTP Proxy or a network specific TURN server and >>>> there is no deliberate policy to block WebRTC media we need a >>>> solution and this is what >>>> draft-hutton-rtcweb-nat-firewall-considerations-00 addresses. >>>>=20 >>>> So far I don't see the benefit that TURN over websockets would have >>>> in this scenario and it needs additional implementation in the >>>> browser and the TURN server. >>>>=20 >>>> Regards >>>> Andy >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >>>>> Sent: 15 May 2013 18:20 >>>>> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; >> rtcweb@ietf.org >>>>> Subject: RE: [rtcweb] FW: New Version Notification for >>>>> draft-chenxin- behave-turn-websocket-00.txt >>>>>=20 >>>>> Andrew Hutton said: >>>>>> When we wrote the draft http://tools.ietf.org/html/draft-hutton- >>>>> rtcweb-nat-firewall-considerations-00 we did not include this >>>>> option because we did not see the benefit of additional transport >>>>> options for TURN given that the existing options (E.g. TURN/TCP >>>>> and TURN/TLS) seem to be meet our needs. >>>>>>=20 >>>>>> So what would be the benefits that justify this addition >> transport >>>>> option for TURN? >>>>>=20 >>>>> [BA] In my experience, institutions with very restrictive >> security >>>>> policies (e.g. those that don't allow UDP in or out) also tend to >>>>> deploy other measures such as deep packet inspection. So just >>>>> because some traffic is allowed in or out on port 80 does not mean >>>>> that TURN/TCP will be allowed on that port - a DPI box may examine >>>>> the traffic and complain if it doesn't see HTTP being used. On >>>>> the other hand, unless the DPI box is upgraded, it will also >>>>> complain about websockets. So I think draft-chenxin only helps in >>>>> a situation where TURN over Websockets would be allowed when >>>>> TURN/TCP would not be. That scenario is rare, at least at the >>>>> moment. >>>>>=20 >>>>> The argument for TURN over Websocket/TLS is even more difficult to >>>>> make. While DPI boxes may examine traffic destined to port 443 >>>>> carefully to make sure that TLS is really being used, assuming >>>>> that the DPI box does not see anything it considers fishy, the TLS >>>>> exchange will complete and the DPI box will lose visibility. >>>>> After TLS is running, the DPI box does not have much information >>>>> available to distinguish TURN/TLS from HTTP over TLS, with or >>>>> without websockets -- and those things it does have (such as >>>>> packet size) are as likely to result in an objection to websocket >>>>> transport as TURN/TLS. So I'm not sure that draft-chenxin will >>>>> help in that situation either. >>>>=20 >>>>=20 >>>>=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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = keep on thinking that the solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt&n= bsp;deserves = attention.

Simon

Il giorno = 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto:

Regarding the HTTP fallback and whether this could be = adapted to be a TURN over HTTP based solution then I think the same = comments that were made on the TURN over websockets apply. What are the = benefits of creating a new transport for TURN over what we can do using = HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-c= onsiderations-00.

Having said that I am really happy we are = having this debate as we really need to find a solution here that the = browser vendors will implement so I would really like to know which = options they prefer.

I really hope we can get = draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to = document whatever the working group agrees on being the right = solution.

Regards
Andy


-----Original Message-----
From: Lorenzo Miniero = [mailto:lorenzo@meetecho.com]
Sent: 20 May 2013 10:15
To: Gustavo Garc=EDa
Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org
Subject: Re: [rtcweb] New Version Notification for = draft-chenxin-
behave-turn-websocket-00.txt

Il giorno Sun, = 19 May 2013 23:20:41 -0700
Gustavo Garc=EDa <ggb@tokbox.com> ha = scritto:

I agree that TURN over websockets doesn't solve much more = scenarios
than TURN/TLS.   If = trying to fix HTTP Proxy traversal why not = doing
it over HTTP that aside of philosophical discussions would = be the
solution with better success rate?  Otherwise we will = have to
continue answering for another 10 years "why is this app = not working
if skype = does".

Something like this draft sent = some months ago but perhaps for = TURN
instead of direct = connections:
http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt



When I = submitted that draft this summer, I had that exact purpose = in
mind, that is taking care = of corner edge cases like restrictive = proxies
and the like. Of = course it was not meant to be a solution, just a = way
to foster discussion in = that direction. In that discussion I also
mentioned some work we did about this in the past, which = in part
apparently ended up in = draft-hutton-rtcweb-nat-firewall-considerations:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html
=

At the time most people in the ML thought it was either = too useless,
too complex or = even harmful, considering it could be considered as = a
"sneaky" way to circumvent = rules added by a network administrator, and
so unacceptable. Anyway, as I said back then, a solution = like this
doesn't have to be = sneaky, and it could very well be conceived in = order
to be admin-friendly = rather than have a parrot and a wooden leg.

Whether we = actually need something like this or TURN-over-443 is = enough
I don't know: I still = think it may be useful to tackle scenarios = where
everything else fails = (the "skype works here" effect), so I'd be = glad
to be of help in that = direction if needed.

Lorenzo



On 16/05/2013, at 01:28, Hutton, Andrew = wrote:

I = agree with Bernard's comments regarding the impact of DPI but = of
course = such DPI devices do what they do and we can't and even = don't
want = to stop them from doing it. However for the case when = policy
is = such that the firewall will only allow traffic to traverse = that
comes = from the HTTP Proxy or a network specific TURN server = and
there = is no deliberate policy to block WebRTC media we need = a
solution= and this is what
draft-hutton-rtcweb-nat-firewall-considerations-00 = addresses.

So far = I don't see the benefit that TURN over websockets would = have
in = this scenario and it needs additional implementation in = the
browser = and the TURN = server.

Regards
Andy


-----Original = Message-----
From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]
Sent: = 15 May 2013 = 18:20
To: Hutton, Andrew; Chenxin = (Xin); behave@ietf.org;
rtcweb@ietf.org
Subject: RE: [rtcweb] FW: New = Version Notification = for
draft-chenxin- = behave-turn-websocket-00.txt

Andrew Hutton = said:
When = we wrote the draft http://tools.ietf.org/ht= ml/draft-hutton-
rtcweb-nat-firewall-considerations-00 we did not include = this
option because we did not see = the benefit of additional = transport
options for TURN given that the = existing options (E.g. = TURN/TCP
and TURN/TLS) seem to be meet = our = needs.

So = what would be the benefits that justify this = addition
transport
option for = TURN?

[BA] In my experience, =  institutions with very = restrictive
security
policies (e.g. those that don't = allow UDP in or out) also tend = to
deploy other measures such as = deep packet inspection.   So = just
because some traffic is allowed = in or out on port 80 does not = mean
that TURN/TCP will be allowed on = that port - a DPI box may = examine
the traffic and complain if it = doesn't see HTTP being used. =  On
the other hand, unless the DPI = box is upgraded, it will = also
complain about websockets. =  So I think draft-chenxin only helps = in
a situation where TURN over = Websockets would be allowed = when
TURN/TCP would not be. =  That scenario is rare, at least at = the
moment.

The argument for TURN over = Websocket/TLS is even more difficult = to
make. While DPI boxes may = examine traffic destined to port = 443
carefully to make sure that TLS = is really being used, =  assuming
that the DPI box does not see = anything it considers fishy, the = TLS
exchange will complete and the = DPI box will lose = visibility.
After TLS is running, the DPI = box does not have much = information
available to distinguish = TURN/TLS from HTTP over TLS, with = or
without websockets -- and those = things it does have (such = as
packet size) are as likely to = result in an objection to = websocket
transport as TURN/TLS.  So = I'm not sure that draft-chenxin = will
help in that situation = either.




_______________________________________________
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

____________= ___________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4-- From christer.holmberg@ericsson.com Tue May 21 00:20:26 2013 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 C710C21F95EB for ; Tue, 21 May 2013 00:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnv-NaGWYq0o for ; Tue, 21 May 2013 00:20:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0113521F9728 for ; Tue, 21 May 2013 00:20:20 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-66-519b2033633d Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8C.BA.06701.3302B915; Tue, 21 May 2013 09:20:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Tue, 21 May 2013 09:20:19 +0200 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkJuD4AgAPsAUCAAH7PAIABHI7Q Date: Tue, 21 May 2013 07:20:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> In-Reply-To: <519A4C9A.6020501@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvra6xwuxAg6er9C1WbDjAarH2Xzu7 A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxckNNwVXhiuef1zI3MD7l72Lk5JAQMJHY NHMFI4QtJnHh3nq2LkYuDiGBw4wSq+9vY4FwljBKNP16xNTFyMHBJmAh0f1PG6RBRMBXovfy ObBmYQFDid8XTjFDxI0krq3fzwJhu0n8WLwQrIZFQFWi4+spMJsXqHfqt9NQ818ySly4cJIN ZD6ngI5E+2F5kBpGoIO+n1rDBGIzC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBWmVEFCUWN4v B1GuI7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYzsuYmZOenl 5psYgXFwcMtvgx2Mm+6LHWKU5mBREuft054aKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx 13rN/cdht2dkv7F+NU3yxF+PA6meiluv1+cK/HrdaZQr+rY/59v6xZ7ZK/vdKxivSrxr3LH5 HX/dtxvR0fwrE8pm/3jgXG+uIfJ33qH9h578m/+0UXKaxWU5n7MeV+Sml+kv/75pK//zzX8v PDbxSi7iNr746prlFFXWh3XRlrd3PLO6bhjLqcRSnJFoqMVcVJwIAPRU8fFRAgAA Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 07:20:27 -0000 Hi, >> I don't think it's a BUNDLE issue whether adding/removing of streams req= uire an O/A exchange or not. It's an SDP, and SDP O/A, issue. >> >> BUNDLE is about sharing a 5-tuple. > > I don't agree. > > RTP is already able to support multiple RTP streams sharing an RTP sessio= n (and 5-tuple). > > What BUNDLE is about is describing that in SDP. > And that includes how SDP O/A works. Multiple RTP streams can already share an RTP session today, using multiple= SSRCs per m- line :) If adding a new stream means adding a new m- line, then an SDP O/A is obvio= usly needed - bundle or no bundle. If adding a new stream means adding a new SSRC, within an existing m-, then= it is also an SDP O/A issue - bundle or no bundle. Regards, Christer > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Martin Thomson > Sent: 17. toukokuuta 2013 23:50 > To: Bernard Aboba > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] A problem with both A and B > >> "Dale R. Worley" wrote: >> DES F11 It must be possible to add and remove one way video flows >> within the bundle without requiring an additional offer/answer >> cycle. > > I'm not sure why this speaks specifically about video... > > On 17 May 2013 13:21, Bernard Aboba wrote: >> It is important. In fact, I would argue it is critical for congestion co= ntrol (e.g. removal of simulcast or layered streams by the sender should no= t require an O/A exchange). > > This is different I think. Responding to congestion only requires=20 > that it be possible to stop sending a given stream. (Or maybe crank=20 > down resolution or frame rate.) > > This item talks about addition. That's an entirely different proposition= . As long as we assume constraints (you don't need to re-ICE a new transpo= rt for the stream, you don't use new packet types and codec profiles), this= could be possible. But to get WebRTC to support this requires API changes= . > _______________________________________________ > 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 > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Tue May 21 00:32:03 2013 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 C2B1021F972D for ; Tue, 21 May 2013 00:32:03 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiRmkCAjz6rl for ; Tue, 21 May 2013 00:32:02 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B199B21F9743 for ; Tue, 21 May 2013 00:31:56 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it19so152391bkc.27 for ; Tue, 21 May 2013 00:31:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=RQ3JCAyBQGWaybL9mnhsiGQ+k59/ojErhsBfkzZJRwk=; b=PZs87+Q0Wfqh5Xqr2gt+FOFmve6rY6/2JozSYTsS5CQnd28Bye3kca6UOM41LfdzV5 qT6oiirDvAOc/mTlH/vVisiVF5zTxUpJma0lrG1rw5rSVN9l00fFIieNcfH1Sc9vbEyN oZwcSXTonWuIedwpnExvhk3asBS36i+eTGQPHWpa1qfqXt6tfe8C0a7fsYRkF1bgMWFA oajO90zF/MrBtym//nIPeLNeiENhF1cRo1H9h4Ic1noAwkw23oPKCsgJ5QW7s959BWvc Al2UBx66s6v1L1kPz/AxFa5ckcbxbZqlBDvHkdtog6+DV7Lrc4PhlrXI0aKzRVA7H9ui rT1A== X-Received: by 10.205.118.203 with SMTP id fr11mr309900bkc.103.1369121515601; Tue, 21 May 2013 00:31:55 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id jm15sm206275bkb.13.2013.05.21.00.31.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 00:31:54 -0700 (PDT) Message-ID: <519B22E8.9060709@jitsi.org> Date: Tue, 21 May 2013 10:31:52 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnUj+LE9ZJkpO3FodcS5Ogv69vXBfjTzLVYlegf2wUKt/TbCYqlUEuuX1WJVzz5YI67qY9q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 07:32:03 -0000 On 21.05.13, 10:20, Christer Holmberg wrote: > If adding a new stream means adding a new SSRC, within an existing m-, then it is also an SDP O/A issue - bundle or no bundle. Why is that? Emil -- https://jitsi.org From christer.holmberg@ericsson.com Tue May 21 00:38:46 2013 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 A6BC821F976F for ; Tue, 21 May 2013 00:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3cKmh+pjMwU for ; Tue, 21 May 2013 00:38:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9894B21F9754 for ; Tue, 21 May 2013 00:38:39 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-52-519b247e1e06 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A2.7F.31782.E742B915; Tue, 21 May 2013 09:38:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 21 May 2013 09:38:38 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkJuD4AgAPsAUCAAH7PAIABHI7Q///i6gCAACIxYA== Date: Tue, 21 May 2013 07:38:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> In-Reply-To: <519B22E8.9060709@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrW6dyuxAg+ZJxhZrdk5gsVix4QCr xdp/7ewOzB5/339g8liy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZ3542Mhe8Y6m48XohSwPj Y+YuRk4OCQETiePn77FB2GISF+6tB7K5OIQEDjNKXOifzQ7hLGGUONb3k7WLkYODTcBCovuf NkiDiIC8RHfbIiYQm1nAV2LCt+0sILawgKHE7wunmCFqjCSurd/PAmGHSTx/twzMZhFQlZg7 /TgjiM0L1Ptm2g2wuJDAGSaJ71d5QGxOAU2Jjr4Z7CA2I9Bx30+tgdolLnHryXwmiKMFJJbs OQ/1jKjEy8f/wM6UEFCUWN4vB1GuI7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUWwWkqmzkLTM QtIyC0nLAkaWVYzsuYmZOenlRpsYgTFzcMtv1R2Md86JHGKU5mBREuft1Z4aKCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoHR8inPjq5SlTtR3FeX58fqTXc9POUzh/jbuNfS63ZqrTHQjjhu +uvmZpGPTcpKpie8z5tLRu3n+KRR0ynzWcrzYYzs1LtZl9iSPj4zl1/L/NxpTrS1zv5rVyvk 5q0LPXcrc4FK540fybM6VF7P+xarwJkQNv3GxRa+BdX+a5UEiq8c1EuYVialxFKckWioxVxU nAgAKDEbOWcCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 07:38:46 -0000 Hi, >> If adding a new stream means adding a new SSRC, within an existing m-, t= hen it is also an SDP O/A issue - bundle or no bundle. > > Why is that? Because, even WITHOUT bundle, you have to answer whether adding a new SSRC = (or, whatever mechanism we use to identify a stream) within an existing m- = line requires an SDP O/A transaction or not. Of course, IF we are going to define a BUNDLE specific way of signalling RT= P streams, then we of course also need to cover the procedures for adding/r= emoving streams, whether it requires an SDP O/A transaction or not, etc. Regards, Christer From emil@sip-communicator.org Tue May 21 00:45:31 2013 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 6E37021F90F1 for ; Tue, 21 May 2013 00:45:28 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF01m9NuIUl9 for ; Tue, 21 May 2013 00:45:27 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 562F821F8519 for ; Tue, 21 May 2013 00:45:27 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id mx1so154128bkb.40 for ; Tue, 21 May 2013 00:45:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=aJKIZFwg5XcgxMssMNSbtM81xMgakL5mqjy+4yZHjzs=; b=kludOvF+dRJ9N9+OqfaLA14JXcTBYE2obreTQai29HR/bEqJZccl2egf+bYq9z8wLf zuBwDmOcU2vUjBwTEqHiJK+Oj7FboBkQjUgUjh5CxDIE9GMA+uvzX7MgLJBUQE5xoaVZ iFqWcaEORFe1o4c+jQ9rzVVPYy6scrG/wf0h0JVKu/0WrKLvxWFS5xo56DW1ypPc2Zrv 0kAOvtuIQZecQV8nxxxEG3g6tg/f8po/bVdbfqQoLrxpOpaZAYUuC0s+zFHfFjhi4iNr X1CgegxsZDCKoJBkaRVvwwnAlSB1NCmbojibI+zeCjmrApDyH4wo8YjjrbTDP/FU1Klg eYdQ== X-Received: by 10.205.105.196 with SMTP id dr4mr356194bkc.45.1369122326246; Tue, 21 May 2013 00:45:26 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id iy11sm219506bkb.11.2013.05.21.00.45.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 00:45:25 -0700 (PDT) Message-ID: <519B2613.9090707@jitsi.org> Date: Tue, 21 May 2013 10:45:23 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkvnGKdp5sy4Izjyat32vzTLokGrGBOu6G/PyU5OCzZuSJyWeCWQKoSUtO9Vza660QXnmGs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 07:45:32 -0000 On 21.05.13, 10:38, Christer Holmberg wrote: > Hi, > >>> If adding a new stream means adding a new SSRC, within an >>> existing m-, then it is also an SDP O/A issue - bundle or no >>> bundle. >> >> Why is that? > > Because, even WITHOUT bundle, you have to answer whether adding a new > SSRC (or, whatever mechanism we use to identify a stream) within an > existing m- line requires an SDP O/A transaction or not. OK, I guess I took your statement to mean that adding and removing SSRCs to m= lines is a matter that cannot be handled without SDP O/A which I think it isn't (and which is what this thread started with). I obviously agree that it is not a bundle-specific issue. Emil -- https://jitsi.org From kevindempsey70@gmail.com Tue May 21 01:31:43 2013 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 73FE521F9749 for ; Tue, 21 May 2013 01:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnu-jiOJvQyg for ; Tue, 21 May 2013 01:31:39 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0606121F9743 for ; Tue, 21 May 2013 01:31:38 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id r10so457725lbi.25 for ; Tue, 21 May 2013 01:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xhxegyAYw+Vi5ga1WcDIz9a8iVjFKKQuAwIJhHWfFGs=; b=Ra3/VKVHB+fVxbINz55KBdfuZ2sYm14MmUZHg1vnUDFWlacJ2NQNDf9uN5lWFx+01K yodObxN0SHLv2FQ/4dlZ4J0CzFDI4+XQZBZNVGZaqxsSKRZf/Vh3McAAX6KrXyvz0Lhh /WCBOcrDQV2F7J8Y+X5oLjlMmIksbv7Od1eJRKtj6XIP+sZ9Y8sI5VR0PoDoRhxeTBzq 0c1AvvFcvEw5X6U6JFZ3gI8gNLs6t57O2bKiaNWEXGCOPOHOOoL8WWWDzbTqWxwe5JRQ t0qgeN5Omv5EEzSmuOa+1ctuA+xKYOabULAh3jqrN1wh+bAZXxMGC/uF2qRzrwB0HG+S xZoQ== MIME-Version: 1.0 X-Received: by 10.112.201.131 with SMTP id ka3mr900572lbc.113.1369125097897; Tue, 21 May 2013 01:31:37 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Tue, 21 May 2013 01:31:37 -0700 (PDT) In-Reply-To: <519B2613.9090707@jitsi.org> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> <519B2613.9090707@jitsi.org> Date: Tue, 21 May 2013 09:31:37 +0100 Message-ID: From: Kevin Dempsey To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c32a061d062704dd364725 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:31:43 -0000 --001a11c32a061d062704dd364725 Content-Type: text/plain; charset=ISO-8859-1 In cases where each m= line has a different port, when a new SSRC is received usually it is either discarded (when latched to a pre exisiting SSRC stream that does not stop) or is treated as replacing the previous SSRC. When multiplexing is being used it is not obvious whether the new SSRC is replacing a previous one, or is another separate stream. I think that in the multiplex case we need something like a virtual destination port in each RTP packet, such as a RTP header extension or even UDP over UDP! On 21 May 2013 08:45, Emil Ivov wrote: > > > On 21.05.13, 10:38, Christer Holmberg wrote: > > Hi, > > > >>> If adding a new stream means adding a new SSRC, within an > >>> existing m-, then it is also an SDP O/A issue - bundle or no > >>> bundle. > >> > >> Why is that? > > > > Because, even WITHOUT bundle, you have to answer whether adding a new > > SSRC (or, whatever mechanism we use to identify a stream) within an > > existing m- line requires an SDP O/A transaction or not. > > OK, I guess I took your statement to mean that adding and removing SSRCs > to m= lines is a matter that cannot be handled without SDP O/A which I > think it isn't (and which is what this thread started with). > > I obviously agree that it is not a bundle-specific issue. > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c32a061d062704dd364725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In cases where each m=3D line has a different port, when a= new SSRC is received usually it is either discarded (when latched to a pre= exisiting SSRC stream that does not stop) or is treated as replacing the p= revious SSRC.

When multiplexing is being used it is not obvious whet= her the new SSRC is replacing a previous one, or is another separate stream= .

I think that in the multiplex case w= e need something like a virtual destination port in each RTP packet, such a= s a RTP header extension or even UDP over UDP!


On 21 M= ay 2013 08:45, Emil Ivov <emcho@jitsi.org> wrote:


On 21.05.13, 10:38, Christer Holmberg wrote:
> Hi,
>
>>> If adding a new stream means adding a new SSRC, within an
>>> existing m-, then it is also an SDP O/A issue - bundle or no >>> bundle.
>>
>> Why is that?
>
> Because, even WITHOUT bundle, you have to answer whether adding a new<= br> > SSRC (or, whatever mechanism we use to identify a stream) within an > existing m- line requires an SDP O/A transaction or not.

OK, I guess I took your statement to mean that adding and removing SS= RCs
to m=3D lines is a matter that cannot be handled without SDP O/A which I think it isn't (and which is what this thread started with).

I obviously agree that it is not a bundle-specific issue.

Emil

--
https://jitsi.org
_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c32a061d062704dd364725-- From christer.holmberg@ericsson.com Tue May 21 01:57:46 2013 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 8A8D121F97A5 for ; Tue, 21 May 2013 01:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGTI9kVYi82R for ; Tue, 21 May 2013 01:57:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBD421F9798 for ; Tue, 21 May 2013 01:57:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-35-519b36fa946b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B0.8E.06701.AF63B915; Tue, 21 May 2013 10:57:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 21 May 2013 10:57:30 +0200 From: Christer Holmberg To: Kevin Dempsey , Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkJuD4AgAPsAUCAAH7PAIABHI7Q///i6gCAACIxYP//4ZaAgAAM64CAACgpIA== Date: Tue, 21 May 2013 08:57:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C375159@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> <519B2613.9090707@jitsi.org> 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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre5vs9mBBhd7uSzW7JzAYnFz/lsW i7X/2tkdmD12zrrL7rFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgy/u5pZin4w1Ox7eM5xgbG WVxdjJwcEgImEh/bLrBA2GISF+6tZ+ti5OIQEjjMKNE55RojhLOEUeLZzUvsXYwcHGwCFhLd /7RBTBEBT4kzV7JBepkF1CXuLD7HDmILCxhK/L5wihnEFhEwkri2fj8LhJ0lsXjeeSYQm0VA VaLz7E9GEJtXwFei89pCsHohgW/MEue+64DYnAKBEnuefAOrYQS67fupNUwQu8Qlbj2ZzwRx s4DEkj3nmSFsUYmXj/+xgpwmIaAosbxfDqJcR2LB7k9sELa2xLKFr5kh1gpKnJz5hGUCo9gs JFNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLzTcxAiPm4JbfBjsYN90XO8QozcGiJM7bpz01UEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjpl1MrmvvPd5/VvTC1K3bOOyPdrPN6F4vsaLG+phq JK+8elftndqftnyukmVzt3XUNvfWvjLWne8WdY61b+HFvCfJimwyRzJ0Gg+eSC481asueXWf pFq4NsfjW/vVqj+9Y5vzR+X4w8lKPjMz4ysVL/a9N18d6fqV6UDIB+2/Td46QRkLTvYpsRRn JBpqMRcVJwIA6eYm72YCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:57:46 -0000 Hi, > In cases where each m=3D line has a different port, when a new SSRC is re= ceived usually it is either discarded (when latched to a pre exisiting SSRC= stream that does not stop) or is treated as replacing the previous SSRC. > > When multiplexing is being used it is not obvious whether the new SSRC is= replacing a previous one, or is another separate stream. > > I think that in the multiplex case we need something like a virtual desti= nation port in each RTP packet, such as a RTP header extension or even UDP = over UDP! Perhaps. But, then we talk more about how to identify/demux a stream, once it has be= en added. We would still need to answer whether the actual addition of a new stream r= equires a SDP O/A transaction :) Regards, Christer On 21.05.13, 10:38, Christer Holmberg wrote: > Hi, > >>> If adding a new stream means adding a new SSRC, within an >>> existing m-, then it is also an SDP O/A issue - bundle or no >>> bundle. >> >> Why is that? > > Because, even WITHOUT bundle, you have to answer whether adding a new > SSRC (or, whatever mechanism we use to identify a stream) within an > existing m- line requires an SDP O/A transaction or not. OK, I guess I took your statement to mean that adding and removing SSRCs to m=3D lines is a matter that cannot be handled without SDP O/A which I think it isn't (and which is what this thread started with). I obviously agree that it is not a bundle-specific issue. Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From kevindempsey70@gmail.com Tue May 21 02:18:28 2013 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 E493821F878C for ; Tue, 21 May 2013 02:18:28 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttX-S6qArVlo for ; Tue, 21 May 2013 02:18:28 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E321F8C03 for ; Tue, 21 May 2013 02:18:27 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ee20so412023lab.14 for ; Tue, 21 May 2013 02:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x0fnxpBQE7uRcW7lMHhOWt3GnaSIwVhXXIEwoCoTUfo=; b=HXkgIvw5tquxMq/EoJXILJ9jMo6hlAfWUNB7TVoGykjEWxXDFOiE/UlzgyfBNSIh3B 3aMzIrdkkyKmZlOhX+pjduTt0hhtmj3GBawUALt7P01HNZZjLF0EWe8YuNWRHmsqxGHD WhRcejf9B4qj6F7Vwzi/7CmZNd/1Mq3BIngmqN7zTKlvD7YTTM4INQZ6V/8momS8t9xY XZqbNyZ55eaoa/lgaN26XkgavzMvnP71aJeAn5p6HiW+P9ZUrTKNDo/6NoJYjL2wgRAH Xk2UfhOBVemMjgfS5YncHQMxIhB51/x1poIXEfrIIiTdSV1xGbhgpv4MmIsXCNDuwfjQ 3c4Q== MIME-Version: 1.0 X-Received: by 10.112.17.7 with SMTP id k7mr989620lbd.124.1369127905136; Tue, 21 May 2013 02:18:25 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Tue, 21 May 2013 02:18:25 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C375159@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> <519B2613.9090707@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375159@ESESSMB209.ericsson.se> Date: Tue, 21 May 2013 10:18:25 +0100 Message-ID: From: Kevin Dempsey To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3d8d07014e204dd36ee4d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:18:29 -0000 --001a11c3d8d07014e204dd36ee4d Content-Type: text/plain; charset=ISO-8859-1 Clearly adding a new m= line needs a SDP O/A. So in the multiplex case I would think that adding another m= line equivalent to a bundle would also need a SDP O/A. In the non multiplex case changing to a different source doesn't require a SDP O/A. However, unless there is some identifier in the RTP packets that the receiver knows already, such a change would need to be signalled in the multiplex case. On 21 May 2013 09:57, Christer Holmberg wrote: > Hi, > > > In cases where each m= line has a different port, when a new SSRC is > received usually it is either discarded (when latched to a pre exisiting > SSRC stream that does not stop) or is treated as replacing the previous > SSRC. > > > > When multiplexing is being used it is not obvious whether the new SSRC > is replacing a previous one, or is another separate stream. > > > > I think that in the multiplex case we need something like a virtual > destination port in each RTP packet, such as a RTP header extension or even > UDP over UDP! > > Perhaps. > > But, then we talk more about how to identify/demux a stream, once it has > been added. > > We would still need to answer whether the actual addition of a new stream > requires a SDP O/A transaction :) > > Regards, > > Christer > > > > On 21.05.13, 10:38, Christer Holmberg wrote: > > Hi, > > > >>> If adding a new stream means adding a new SSRC, within an > >>> existing m-, then it is also an SDP O/A issue - bundle or no > >>> bundle. > >> > >> Why is that? > > > > Because, even WITHOUT bundle, you have to answer whether adding a new > > SSRC (or, whatever mechanism we use to identify a stream) within an > > existing m- line requires an SDP O/A transaction or not. > OK, I guess I took your statement to mean that adding and removing SSRCs > to m= lines is a matter that cannot be handled without SDP O/A which I > think it isn't (and which is what this thread started with). > > I obviously agree that it is not a bundle-specific issue. > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3d8d07014e204dd36ee4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Clearly adding a new m=3D line needs a SDP O/A. So in the = multiplex case I would think that adding another m=3D line equivalent to a = bundle would also need a SDP O/A.

In the non multi= plex case changing to a different source doesn't require a SDP O/A. How= ever, =A0unless there is some identifier in the RTP packets that the receiv= er knows already, such a change would need to be signalled in the multiplex= case.


On 21 M= ay 2013 09:57, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:
Hi,

> In cases where each m=3D line has a different port, when a new SSRC is= received usually it is either discarded (when latched to a pre exisiting S= SRC stream that does not stop) or is treated as replacing the previous SSRC= .
>
> When multiplexing is being used it is not obvious whether the new SSRC= is replacing a previous one, or is another separate stream.
>
> I think that in the multiplex case we need something like a virtual de= stination port in each RTP packet, such as a RTP header extension or even U= DP over UDP!

Perhaps.

But, then we talk more about how to identify/demux a stream, once it has be= en added.

We would still need to answer whether the actual addition of a new stream r= equires a SDP O/A transaction :)

Regards,

Christer



On 21.05.13, 10:38, Christer Holmberg wrote:
> Hi,
>
>>> If adding a new stream means adding a new SSRC, within an
>>> existing m-, then it is also an SDP O/A issue - bundle or no >>> bundle.
>>
>> Why is that?
>
> Because, even WITHOUT bundle, you have to answer whether adding a new<= br> > SSRC (or, whatever mechanism we use to identify a stream) within an > existing m- line requires an SDP O/A transaction or not.
OK, I guess I took your statement to mean that adding and removing SSRCs to m=3D lines is a matter that cannot be handled without SDP O/A which I think it isn't (and which is what this thread started with).

I obviously agree that it is not a bundle-specific issue.

Emil

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


--001a11c3d8d07014e204dd36ee4d-- From emil@sip-communicator.org Tue May 21 02:20:10 2013 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 AA36421F97D1 for ; Tue, 21 May 2013 02:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJNdPcHT3Vcd for ; Tue, 21 May 2013 02:20:09 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 142C021F97B6 for ; Tue, 21 May 2013 02:20:08 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so212119bkc.17 for ; Tue, 21 May 2013 02:20:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ebpSBmO3R10oFXrS6iGZKJMdgjnvcEAV2adyopxQIBg=; b=dda1vTUbZ3FM57nEBkQRiN3k/0+EsvSfcQDyOeQvcLdHlboKp0Mipj3TpZQuPuZB+o q1uDzLmDE2VEYGJvgKJZDhAgar8B/wFwqFrmGs36Ir8B8bfm1tsGfYNkDK+4cuh3vzsQ Oa7pKARKSw0mgtQkLMeyqkFyj/JnnsMsT/w9PrV90MjQW/Y/Uqj8ofKcCaKNedC/rsA4 vWQURYMrQ0W9ecqdRFMr/45tMIdYWPHGPP09fXbIjzrhc2s+eC1Gc8mAhRyYdqckJ4N8 0zxZtR6FA0JxA0eYCgs2ZXta2UUh3WRqjrDP+2ehgnH4179wC5dLsNC7JYdAp4BKhkmq +qqQ== X-Received: by 10.204.189.7 with SMTP id dc7mr411242bkb.108.1369128008024; Tue, 21 May 2013 02:20:08 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id kn5sm344545bkb.20.2013.05.21.02.19.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 02:19:56 -0700 (PDT) Message-ID: <519B3C3A.5070108@jitsi.org> Date: Tue, 21 May 2013 12:19:54 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> <51954162.70909@alvestrand.no> <5195EA95.3030007@jitsi.org> <519A5699.4070808@alum.mit.edu> In-Reply-To: <519A5699.4070808@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlVBWRkwnRqb1u4B75LJGPEHv9y7uFXqRL0Fse2HPN274mOrL4up1K+wLIMm8unlXCUZTpL Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Common ways of handling video conferences? (Re: Why requiring pre-announcement) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:20:10 -0000 Hey Paul, On 20.05.13, 20:00, Paul Kyzivat wrote: > On 5/17/13 4:30 AM, Emil Ivov wrote: >> On 16.05.13, 23:28, Harald Alvestrand wrote: >>> On 05/16/2013 09:22 PM, Emil Ivov wrote: >>>>> Then it is another >>>>>> question if it happens via SDP or via RTP header extensions or some >>>>>> other means. >>>>>> >>>>>> There was a discussion at the Stockholm rtcweb interim on what >>>>>> topologies that would be supported, but I fail to remember if this case >>>>>> was included or excluded. >>>> I couldn't find the discussion (in what WG did it happen?) but >>>> topologies based on RTP translators of one sort or another seem to be >>>> the default way of handling video conferencing these days so I don't see >>>> how we could possibly rule them out. >>>> >>> >>> This is an interesting statement. I've also heard the claim that "RTP >>> translators hardly exist outside the lab" - I think that quip was >>> referring to RFC 5117 section 3.3 Topo-Trn-Translators, the story may be >>> different for Topo-Media-Translators - but I thought the most common >>> form was the section 3.4 Topo-Mixer? >> >> Until recently, yes certainly, mixers were prevalent (which is arguably >> part of the reason why very few people had access to video conferencing). >> >> I think we'd all agree that this doesn't seem to be the case any longer >> and that for various reasons (including cost, quality and flexibility), >> most of the conferencing solutions today prefer shifting packets rather >> than mixing content. > > I would like to understand: when "most" is used in this discussion, what > are we measuring? > - number of distinct implementations (code bases) using this approach? > - number of conference sessions set up using this approach? > - number of conference user-minutes using this approach? > - something else I was referring to easily observable trends. I certainly don't have exact numbers. I don't think I implied that and I don't think it's the most important thing here. Skype, Hangouts, iChat, Asterisk, FreeSWITCH, Jitsi Videobridge, all (seem to) have taken that approach rather than going for content mixing. While in RTCWEB we can't agree on the exact approach yet we all seem to have accepted that conferencing would imply separate RTP streams. The work you are doing in CLUE is another example since it is also about manipulating individual RTP streams. Similar observations could be made about the not so distant past where content mixing seemed to be the default way of handling video conferencing. So, the point I was making here was that: With this shift in mind, topologies resembling RTP translators would likely continue being increasingly popular. Constraints such as "Thou shalt always pre-know your SSRCs" are hence likely to affect and weigh on a big number of scenarios. Does this make more sense? Emil -- https://jitsi.org From christer.holmberg@ericsson.com Tue May 21 02:29:33 2013 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 2A31621F904B for ; Tue, 21 May 2013 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfQvfT+V5v63 for ; Tue, 21 May 2013 02:29:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 14C9221F929F for ; Tue, 21 May 2013 02:29:24 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-77-519b3e731727 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 69.55.31782.37E3B915; Tue, 21 May 2013 11:29:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 21 May 2013 11:29:22 +0200 From: Christer Holmberg To: Kevin Dempsey Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkJuD4AgAPsAUCAAH7PAIABHI7Q///i6gCAACIxYP//4ZaAgAAM64CAACgpIP//5OqAAAR1XaA= Date: Tue, 21 May 2013 09:29:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3751EC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> <519B2613.9090707@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375159@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW6x3exAg461xhZrdk5gsbg5/y2L xdp/7ewOzB47Z91l91iy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZp5u0ClYKVzydfJ6xgbGP v4uRk0NCwERix4NnzBC2mMSFe+vZuhi5OIQEDjNK3Fq1lAnCWcIo8fX6Z8YuRg4ONgELie5/ 2iANIgI6EgfvT2YHCTMLuEhs3hcPEhYWMJT4feEUM0SJkcS19ftZIOwyiR2XPjOB2CwCqhLn Pu0Ci/MK+Er0bOljB7GFBBpZJdp7BUFsToFAiaNHt7OC2IxAt30/tQasl1lAXOLWk/lMEDcL SCzZcx7qflGJl4//sYKcIyGgKLG8Xw6iXEdiwe5PbBC2tsSyha+ZIdYKSpyc+YRlAqPYLCRT ZyFpmYWkZRaSlgWMLKsY2XMTM3PSy402MQLj5eCW36o7GO+cEznEKM3BoiTO26s9NVBIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QD4/wX3Jsmyv8tsHrQf/2X+OvwL/GzOb+obbrkuD5uu1Q9 29kAre13WCJm/1lwsimLUyzTzStm/eP5zks7Su9O2fwwe8O6X8wyjk8mf/lWsF83Mfelmf+u 7sp9HwLO/P/uyD2zqkN1g6Eyc+9Ny9Yb9zft2bawrEhidn3Xc2HpBasjMv5lWgpP0lNiKc5I NNRiLipOBACSoBrAZQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:29:33 -0000 Hi, >Clearly adding a new m=3D line needs a SDP O/A. Correct.=20 >So in the multiplex case I would think that adding another m=3D line equiv= alent to a bundle would also need a SDP O/A. Yes. In my opinion, adding a new m- line requires an SDP O/A - bundle or no= bundle. > In the non multiplex case changing to a different source doesn't require = a SDP O/A. However, unless there is=20 > some identifier in the RTP packets that the receiver knows already, such = a change would need to be signalled in the multiplex case. What do you mean by "non-multiplex"? 1) No bundle, but possibly multiple SSRCs per m- line; or 2) No bundle, and only one SSRC per m- line Regards, Christer >=20 On 21 May 2013 09:57, Christer Holmberg wr= ote: Hi, > In cases where each m=3D line has a different port, when a new SSRC is re= ceived usually it is either discarded (when latched to a pre exisiting SSRC= stream that does not stop) or is treated as replacing the previous SSRC. > > When multiplexing is being used it is not obvious whether the new SSRC is= replacing a previous one, or is another separate stream. > > I think that in the multiplex case we need something like a virtual desti= nation port in each RTP packet, such as a RTP header extension or even UDP = over UDP! Perhaps. But, then we talk more about how to identify/demux a stream, once it has be= en added. We would still need to answer whether the actual addition of a new stream r= equires a SDP O/A transaction :) Regards, Christer On 21.05.13, 10:38, Christer Holmberg wrote: > Hi, > >>> If adding a new stream means adding a new SSRC, within an >>> existing m-, then it is also an SDP O/A issue - bundle or no >>> bundle. >> >> Why is that? > > Because, even WITHOUT bundle, you have to answer whether adding a new > SSRC (or, whatever mechanism we use to identify a stream) within an > existing m- line requires an SDP O/A transaction or not. OK, I guess I took your statement to mean that adding and removing SSRCs to m=3D lines is a matter that cannot be handled without SDP O/A which I think it isn't (and which is what this thread started with). I obviously agree that it is not a bundle-specific issue. Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Tue May 21 02:36:39 2013 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 D63D621F97F1 for ; Tue, 21 May 2013 02:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iK8PjqskkHg for ; Tue, 21 May 2013 02:36:39 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 820FB21F97EC for ; Tue, 21 May 2013 02:36:38 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so222622bkc.17 for ; Tue, 21 May 2013 02:36:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=mDFrHW5ApQ5FHteTxsONFCferjXEDWWoCr8KxK824W0=; b=G9U+eIoFJIZ1UcC0ME3g3CQep5tsoan9baVyKy4DG5K5Ycwy0ugb8LL18l6SFBjrRV K5UalXoeugZORnndcbCEDQoe9Ro84A3L9NiTuZmlabXkE0D1ZSbb/mmaT7ZkKZqApY8n aftparyWiT8ZLCbo6iXhtV5J1k9a8EPiBwikDl1+nTQHwByCCCgNEUEstegjo2jMtZQI EzpzOCGsuyr5svCIBfSa7LzO4lxkLDiLX1LUCmX5eqHPCr3FlkGs+cnJ4kiwq+PF4knN eeKF0SdODDIuVWaywDV2jCZEYk8gddyF4DYwTQyEAt5T4MX2KQBVnT56qIGi84mXyKJp LrIw== X-Received: by 10.204.226.136 with SMTP id iw8mr579043bkb.135.1369128997482; Tue, 21 May 2013 02:36:37 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id es13sm377264bkc.8.2013.05.21.02.36.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 02:36:36 -0700 (PDT) Message-ID: <519B4022.8010802@jitsi.org> Date: Tue, 21 May 2013 12:36:34 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kevin Dempsey References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519B22E8.9060709@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375034@ESESSMB209.ericsson.se> <519B2613.9090707@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C375159@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmV8SJg4JsHtIemNYCeo7kQDXsSlaG+2cusns9LnMs0+gAC56TFGO57qVy3sFwmnHBu57jE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:36:40 -0000 On 21.05.13, 12:18, Kevin Dempsey wrote: > Clearly adding a new m= line needs a SDP O/A. So in the multiplex case I > would think that adding another m= line equivalent to a bundle would > also need a SDP O/A. > > In the non multiplex case changing to a different source doesn't require > a SDP O/A. Note that, unless your are relying on RTCP BYEs, this is due to the application _assuming_ that the new SSRC is a change. Even if implicit, this can still be regarded as application specific signalling. > However, unless there is some identifier in the RTP packets > that the receiver knows already, such a change would need to be > signalled in the multiplex case. The same assumption and opposite implicit signalling can also work here. This also seems to be the default assumption suggested by RTP. Anyways, the point is that it is up to apps to handle this, rather than having browsers taking care of it through O/A. Emil > > On 21 May 2013 09:57, Christer Holmberg > wrote: > > Hi, > > > In cases where each m= line has a different port, when a new SSRC > is received usually it is either discarded (when latched to a pre > exisiting SSRC stream that does not stop) or is treated as replacing > the previous SSRC. > > > > When multiplexing is being used it is not obvious whether the new > SSRC is replacing a previous one, or is another separate stream. > > > > I think that in the multiplex case we need something like a > virtual destination port in each RTP packet, such as a RTP header > extension or even UDP over UDP! > > Perhaps. > > But, then we talk more about how to identify/demux a stream, once it > has been added. > > We would still need to answer whether the actual addition of a new > stream requires a SDP O/A transaction :) > > Regards, > > Christer > > > > On 21.05.13, 10:38, Christer Holmberg wrote: > > Hi, > > > >>> If adding a new stream means adding a new SSRC, within an > >>> existing m-, then it is also an SDP O/A issue - bundle or no > >>> bundle. > >> > >> Why is that? > > > > Because, even WITHOUT bundle, you have to answer whether adding a new > > SSRC (or, whatever mechanism we use to identify a stream) within an > > existing m- line requires an SDP O/A transaction or not. > OK, I guess I took your statement to mean that adding and removing SSRCs > to m= lines is a matter that cannot be handled without SDP O/A which I > think it isn't (and which is what this thread started with). > > I obviously agree that it is not a bundle-specific issue. > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- https://jitsi.org From ron.even.tlv@gmail.com Tue May 21 03:55:05 2013 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 2080321F9294 for ; Tue, 21 May 2013 03:55:05 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USnUPd5bKXCh for ; Tue, 21 May 2013 03:55:04 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E61A721F8FC4 for ; Tue, 21 May 2013 03:55:03 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id h10so293687eaj.20 for ; Tue, 21 May 2013 03:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=USxexeyKGKjv1Wr4cGKlTo8BLQbPRw9carXQgNxgyMU=; b=ntAk6tmjX9j58CUnx7w+hfP6AknY3VJARPy4QKN0fA799L43EaTxk3dPuV7IZM/OJ0 EiF9/sAnM3sX3R5u9UbEVinAywNMn76KHCsGLImWoeCoAZnPlzHt2fp+yrmwnjqZMklU 3eK429wL9TX5X77TngHdAt88y/68R6GxN9QigIoNV0r29tC1jyH9OAuhgApom500+a9B pjeLyp8SdggMvbqCYx+itVsCXbbi0ve4aK3xSDAsQiJOwkDVW2H2AEweqA5mua0O5nH9 syAhs/2g1LryniH5kZRM0H/e50y5kzjxP+gOHeDnxzOpaihPtaltwaOMT7nNkCH1R+kw YZwg== X-Received: by 10.14.87.9 with SMTP id x9mr5394347eee.3.1369133701892; Tue, 21 May 2013 03:55:01 -0700 (PDT) Received: from RoniE (bzq-79-182-167-109.red.bezeqint.net. [79.182.167.109]) by mx.google.com with ESMTPSA id m48sm2680928eeh.16.2013.05.21.03.54.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 May 2013 03:55:00 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , "'Paul Kyzivat'" References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org> <51954162.70909@alvestrand.no> <5195EA95.3030007@jitsi.org> <519A5699.4070808@alum.mit.edu> <519B3C3A.507010 8@jitsi.org> In-Reply-To: <519B3C3A.5070108@jitsi.org> Date: Tue, 21 May 2013 13:53:59 +0300 Message-ID: <012601ce5611$81a28e70$84e7ab50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfgBm/E5GwI97agwAp+/pLsCyytiXwDIVonUAlmxJFACHZYargFsQzTKAe86FxsCoc74OQFXL3XqAiJ5QYoB4ehCCAH2lME7AcarIHQBkI9W1wKnQc2oAmfXvhICI8r7SpcT5u8w Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Common ways of handling video conferences? (Re: Why requiring pre-announcement) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 10:55:05 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: 21 May, 2013 12:20 PM > To: Paul Kyzivat > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Common ways of handling video conferences? (Re: > Why requiring pre-announcement) > > Hey Paul, > > On 20.05.13, 20:00, Paul Kyzivat wrote: > > On 5/17/13 4:30 AM, Emil Ivov wrote: > >> On 16.05.13, 23:28, Harald Alvestrand wrote: > >>> On 05/16/2013 09:22 PM, Emil Ivov wrote: > >>>>> Then it is another > >>>>>> question if it happens via SDP or via RTP header extensions or > >>>>>> some other means. > >>>>>> > >>>>>> There was a discussion at the Stockholm rtcweb interim on what > >>>>>> topologies that would be supported, but I fail to remember if > >>>>>> this case was included or excluded. > >>>> I couldn't find the discussion (in what WG did it happen?) but > >>>> topologies based on RTP translators of one sort or another seem to > >>>> be the default way of handling video conferencing these days so I > >>>> don't see how we could possibly rule them out. > >>>> > >>> > >>> This is an interesting statement. I've also heard the claim that > >>> "RTP translators hardly exist outside the lab" - I think that quip > >>> was referring to RFC 5117 section 3.3 Topo-Trn-Translators, the > >>> story may be different for Topo-Media-Translators - but I thought > >>> the most common form was the section 3.4 Topo-Mixer? > >> > >> Until recently, yes certainly, mixers were prevalent (which is > >> arguably part of the reason why very few people had access to video > conferencing). > >> > >> I think we'd all agree that this doesn't seem to be the case any > >> longer and that for various reasons (including cost, quality and > >> flexibility), most of the conferencing solutions today prefer > >> shifting packets rather than mixing content. > > > > I would like to understand: when "most" is used in this discussion, > > what are we measuring? > > - number of distinct implementations (code bases) using this approach? > > - number of conference sessions set up using this approach? > > - number of conference user-minutes using this approach? > > - something else > > I was referring to easily observable trends. I certainly don't have exact > numbers. I don't think I implied that and I don't think it's the most important > thing here. Skype, Hangouts, iChat, Asterisk, FreeSWITCH, Jitsi Videobridge, > all (seem to) have taken that approach rather than going for content mixing. > > While in RTCWEB we can't agree on the exact approach yet we all seem to > have accepted that conferencing would imply separate RTP streams. The > work you are doing in CLUE is another example since it is also about > manipulating individual RTP streams. > > Similar observations could be made about the not so distant past where > content mixing seemed to be the default way of handling video > conferencing. > > So, the point I was making here was that: > > With this shift in mind, topologies resembling RTP translators would likely > continue being increasingly popular. Constraints such as "Thou shalt always > pre-know your SSRCs" are hence likely to affect and weigh on a big number > of scenarios. > > Does this make more sense? [Roni Even] This make sense but I assume that this approach works better with scalable video (SVC) or simulcast for endpoint mixing and I did not see that RTCweb wants to mandate such support in the MTI video codec discussion. > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Tue May 21 06:34:17 2013 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 EDC3121F96BC; Tue, 21 May 2013 06:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhvj8cANgMSj; Tue, 21 May 2013 06:34:12 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id AD4EF21F974B; Tue, 21 May 2013 06:34:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 477811EB851A; Tue, 21 May 2013 15:34:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 21 May 2013 15:34:10 +0200 From: "Hutton, Andrew" To: Simon Pietro Romano Thread-Topic: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVTqUu83hGBO03EOmioPLICQbqpkN5f0AgABIK4CAAXZogA== Date: Tue, 21 May 2013 13:34:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> In-Reply-To: <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:34:17 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Simon I believe all possible solutions deserve attention however my feeling is th= at the HTTP Connect based mechanism for connecting to the TURN server via T= URN/TCP/TLS has a good chance of being implemented by browsers. What I would really like to happen is for draft-hutton-rtcweb-nat-firewall-= considerations to be adopted and progressed by the WG to describe the prefe= rred solution whatever it might be. In the next update we could add some text describing the alternatives to th= e HTTP CONNECT based mechanism to promote further discussion at least we se= em to have some agreement that a solution is needed. Regards Andy From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: 20 May 2013 18:12 To: Hutton, Andrew Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-tur= n-websocket-00.txt I keep on thinking that the solution depicted in http://tools.ietf.org/id/d= raft-miniero-rtcweb-http-fallback-00.txt deserves attention. Simon Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: Regarding the HTTP fallback and whether this could be adapted to be a TURN = over HTTP based solution then I think the same comments that were made on t= he TURN over websockets apply. What are the benefits of creating a new tran= sport for TURN over what we can do using HTTP Connect as described in http:= //tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00. Having said that I am really happy we are having this debate as we really n= eed to find a solution here that the browser vendors will implement so I wo= uld really like to know which options they prefer. I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations ad= opted and use it to document whatever the working group agrees on being the= right solution. Regards Andy -----Original Message----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] Sent: 20 May 2013 10:15 To: Gustavo Garc=EDa Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.or= g Subject: Re: [rtcweb] New Version Notification for draft-chenxin- behave-turn-websocket-00.txt Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa > ha scritto: I agree that TURN over websockets doesn't solve much more scenarios than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over HTTP that aside of philosophical discussions would be the solution with better success rate? Otherwise we will have to continue answering for another 10 years "why is this app not working if skype does". Something like this draft sent some months ago but perhaps for TURN instead of direct connections: http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt When I submitted that draft this summer, I had that exact purpose in mind, that is taking care of corner edge cases like restrictive proxies and the like. Of course it was not meant to be a solution, just a way to foster discussion in that direction. In that discussion I also mentioned some work we did about this in the past, which in part apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations: http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html At the time most people in the ML thought it was either too useless, too complex or even harmful, considering it could be considered as a "sneaky" way to circumvent rules added by a network administrator, and so unacceptable. Anyway, as I said back then, a solution like this doesn't have to be sneaky, and it could very well be conceived in order to be admin-friendly rather than have a parrot and a wooden leg. Whether we actually need something like this or TURN-over-443 is enough I don't know: I still think it may be useful to tackle scenarios where everything else fails (the "skype works here" effect), so I'd be glad to be of help in that direction if needed. Lorenzo On 16/05/2013, at 01:28, Hutton, Andrew wrote: I agree with Bernard's comments regarding the impact of DPI but of course such DPI devices do what they do and we can't and even don't want to stop them from doing it. However for the case when policy is such that the firewall will only allow traffic to traverse that comes from the HTTP Proxy or a network specific TURN server and there is no deliberate policy to block WebRTC media we need a solution and this is what draft-hutton-rtcweb-nat-firewall-considerations-00 addresses. So far I don't see the benefit that TURN over websockets would have in this scenario and it needs additional implementation in the browser and the TURN server. Regards Andy -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 15 May 2013 18:20 To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- behave-turn-websocket-00.txt Andrew Hutton said: When we wrote the draft http://tools.ietf.org/html/draft-hutton- rtcweb-nat-firewall-considerations-00 we did not include this option because we did not see the benefit of additional transport options for TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. So what would be the benefits that justify this addition transport option for TURN? [BA] In my experience, institutions with very restrictive security policies (e.g. those that don't allow UDP in or out) also tend to deploy other measures such as deep packet inspection. So just because some traffic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine the traffic and complain if it doesn't see HTTP being used. On the other hand, unless the DPI box is upgraded, it will also complain about websockets. So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP would not be. That scenario is rare, at least at the moment. The argument for TURN over Websocket/TLS is even more difficult to make. While DPI boxes may examine traffic destined to port 443 carefully to make sure that TLS is really being used, assuming that the DPI box does not see anything it considers fishy, the TLS exchange will complete and the DPI box will lose visibility. After TLS is running, the DPI box does not have much information available to distinguish TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as packet size) are as likely to result in an objection to websocket transport as TURN/TLS. So I'm not sure that draft-chenxin will help in that situation either. _______________________________________________ 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _\= \|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Feder= ico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Mag= ritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) )= / (_/ --_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Simon

 <= /p>

I believe all possible so= lutions deserve attention however my feeling is that the HTTP Connect based= mechanism for connecting to the TURN server via TURN/TCP/TLS has a good chance of being implemented by browsers.

 <= /p>

What I would really like = to happen is for draft-hutton-rtcweb-nat-firewall-considerations to be adop= ted and progressed by the WG to describe the preferred solution whatever it might be.

 <= /p>

In the next update we cou= ld add some text describing the alternatives to the HTTP CONNECT based mech= anism to promote further discussion at least we seem to have some agreement that a solution is needed.

 <= /p>

Regards=

Andy

 <= /p>

 <= /p>

From: Simon Pi= etro Romano [mailto:spromano@unina.it]
Sent: 20 May 2013 18:12
To: Hutton, Andrew
Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.= org
Subject: Re: [rtcweb] New Version Notification for draft-chenxin-beh= ave-turn-websocket-00.txt

 

I keep on thinking that the solution depicted in&nbs= p;http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt deserves attention.

 

Simon

 

Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andre= w ha scritto:



Regarding the HTTP fallback and whether this could b= e adapted to be a TURN over HTTP based solution then I think the same comme= nts that were made on the TURN over websockets apply. What are the benefits= of creating a new transport for TURN over what we can do using HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-= 00.

Having said that I am really happy we are having this debate as we really n= eed to find a solution here that the browser vendors will implement so I wo= uld really like to know which options they prefer.

I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations ad= opted and use it to document whatever the working group agrees on being the= right solution.

Regards
Andy



-----Original Message-----

From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]

Sent: 20 May 2013 10:15

To: Gustavo Garc=EDa

Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org

Subject: Re: [rtcweb] New Version Notification for d= raft-chenxin-

behave-turn-websocket-00.txt

 

Il giorno Sun, 19 May 2013 23:20:41 -0700=

Gustavo Garc=EDa <ggb@tokbox.com> ha scritto:

 

I agree that TURN over websockets doesn't solve much= more scenarios

than TURN/TLS.   If trying to fix HTTP Pro= xy traversal why not doing

it over HTTP that aside of philosophical discussions= would be the

solution with better success rate?  Otherwise w= e will have to

continue answering for another 10 years "why is= this app not working

if skype does".

 

Something like this draft sent some months ago but p= erhaps for TURN

instead of direct connections:

http://tools.ietf.org/id/draft-miniero-rtcweb-ht= tp-fallback-00.txt

 

 

 

When I submitted that draft this summer, I had that = exact purpose in

mind, that is taking care of corner edge cases like = restrictive proxies

and the like. Of course it was not meant to be a sol= ution, just a way

to foster discussion in that direction. In that disc= ussion I also

mentioned some work we did about this in the past, w= hich in part

apparently ended up in draft-hutton-rtcweb-nat-firew= all-considerations:

 

http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg05041.html

 

At the time most people in the ML thought it was eit= her too useless,

too complex or even harmful, considering it could be= considered as a

"sneaky" way to circumvent rules added by = a network administrator, and

so unacceptable. Anyway, as I said back then, a solu= tion like this

doesn't have to be sneaky, and it could very well be= conceived in order

to be admin-friendly rather than have a parrot and a= wooden leg.

 

Whether we actually need something like this or TURN= -over-443 is enough

I don't know: I still think it may be useful to tack= le scenarios where

everything else fails (the "skype works here&qu= ot; effect), so I'd be glad

to be of help in that direction if needed.

 

Lorenzo

 

 

 

On 16/05/2013, at 01:28, Hutton, Andrew wrote:<= /o:p>

 

I agree with Bernard's comments regarding the impact= of DPI but of

course such DPI devices do what they do and we can't= and even don't

want to stop them from doing it. However for the cas= e when policy

is such that the firewall will only allow traffic to= traverse that

comes from the HTTP Proxy or a network specific TURN= server and

there is no deliberate policy to block WebRTC media = we need a

solution and this is what

draft-hutton-rtcweb-nat-firewall-considerations-00 a= ddresses.

 

So far I don't see the benefit that TURN over websoc= kets would have

in this scenario and it needs additional implementat= ion in the

browser and the TURN server.

 

Regards

Andy

 

 

-----Original Message-----

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]

Sent: 15 May 2013 18:20

To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org;

rtcweb@ietf.org

Subject: RE: [rtcweb] FW: New Version Notification f= or

draft-chenxin- behave-turn-websocket-00.txt

 

Andrew Hutton said:

When we wrote the draft http://tools.ietf.org/html/draft-hutton-

rtcweb-nat-firewall-considerations-00 we did not inc= lude this

option because we did not see the benefit of additio= nal transport

options for TURN given that the existing options (E.= g. TURN/TCP

and TURN/TLS) seem to be meet our needs.<= /p>

 

So what would be the benefits that justify this addi= tion

transport

option for TURN?

 

[BA] In my experience,  institutions with very = restrictive

security

policies (e.g. those that don't allow UDP in or out)= also tend to

deploy other measures such as deep packet inspection= .   So just

because some traffic is allowed in or out on port 80= does not mean

that TURN/TCP will be allowed on that port - a DPI b= ox may examine

the traffic and complain if it doesn't see HTTP bein= g used.  On

the other hand, unless the DPI box is upgraded, it w= ill also

complain about websockets.  So I think draft-ch= enxin only helps in

a situation where TURN over Websockets would be allo= wed when

TURN/TCP would not be.  That scenario is rare, = at least at the

moment.

 

The argument for TURN over Websocket/TLS is even mor= e difficult to

make. While DPI boxes may examine traffic destined t= o port 443

carefully to make sure that TLS is really being used= ,  assuming

that the DPI box does not see anything it considers = fishy, the TLS

exchange will complete and the DPI box will lose vis= ibility.

After TLS is running, the DPI box does not have much= information

available to distinguish TURN/TLS from HTTP over TLS= , with or

without websockets -- and those things it does have = (such as

packet size) are as likely to result in an objection= to websocket

transport as TURN/TLS.  So I'm not sure that dr= aft-chenxin will

help in that situation either.

 

 

 

 

_______________________________________________=

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


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

 

      &nbs= p;                         &n= bsp;            = ;            &n= bsp;             &nb= sp; _\\|//_

      &nbs= p;                            = ;            &n= bsp;              ( O-O )

   ~~~~~~~~~~~~= ~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

      &nbs= p;                 =             &nb= sp;            =        Simon Pietro Romano

      &nbs= p;         &nb= sp;            =             &nb= sp;      Universita' di Na= poli Federico II

      &nbs= p;          &n= bsp;              Computer Engineering Department =

                 =     Phone: +39 081 7683823 -- Fax: +39 081 7683816

      &nbs= p;                     &n= bsp;              e-mail: spromano@unina.it

 <= /p>

           &nb= sp;          <<Molti mi dic= ono che lo scoraggiamento =CB l'alibi degli 

           &nb= sp;          idioti. Ci rifl= etto un istante; e mi scoraggio>>. Magritte.

      &nbs= p;              &nb= sp;            =                       = ;  oooO

  ~~~~~~~~~~~~~~~~~~= ~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nb= sp;            =             &nb= sp;                   =        \ (            ( =   )

           &nb= sp;            =             =                     &nbs= p;   \_)          ) /

      &nbs= p;                     &n= bsp;                     =                      = ;(_/

 <= /p>

 

 

 

--_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_-- From pkyzivat@alum.mit.edu Tue May 21 13:14:00 2013 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 3383121F95E7 for ; Tue, 21 May 2013 13:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqfmmEg1ybDV for ; Tue, 21 May 2013 13:13:54 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 40DA721F95D0 for ; Tue, 21 May 2013 13:13:54 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id ek1H1l03Y1vXlb853kDt4L; Tue, 21 May 2013 20:13:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id ekDt1l00N3ZTu2S3dkDt0z; Tue, 21 May 2013 20:13:53 +0000 Message-ID: <519BD580.7080205@alum.mit.edu> Date: Tue, 21 May 2013 16:13:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369167233; bh=FS0q/iRBDYdyHCzIokOLMTcpiUHiIYKbKbBOhOVlwnQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GBTJwYxR2PlHG57Z5UlZEpMssk//27Ox58PfiK5hV/ppnRY2sZiJLW+qbn0SQ9+Jd o9T+v1y51AURYK4KbhbREAFBJtTO2exgnMYrMfCYZ/xNAUCQqWLkCoCRaFA5YKZiBi k/I8zFNMNVUD702eLmB8Mp89UehpZOv3M+zJOmimCXgdrXgEm4wkA9r6ZUDL6M8mT6 ryxE88canByAwqwfvahIrux1tOlHhGcF9TZliYbvsIpatZJAxRBn4wCxIMH97PUeIv sLN9MvjbhCgqx9wDJRJemrsJ4z9OglVUb+vuCvLE52TU7P/it80izltye9w7QkK49N 3RXnTF9ZSK+Ow== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 20:14:00 -0000 On 5/21/13 3:20 AM, Christer Holmberg wrote: > Hi, > >>> I don't think it's a BUNDLE issue whether adding/removing of streams require an O/A exchange or not. It's an SDP, and SDP O/A, issue. >>> >>> BUNDLE is about sharing a 5-tuple. >> >> I don't agree. >> >> RTP is already able to support multiple RTP streams sharing an RTP session (and 5-tuple). >> >> What BUNDLE is about is describing that in SDP. >> And that includes how SDP O/A works. > > Multiple RTP streams can already share an RTP session today, using multiple SSRCs per m- line :) > > If adding a new stream means adding a new m- line, then an SDP O/A is obviously needed - bundle or no bundle. > > If adding a new stream means adding a new SSRC, within an existing m-, then it is also an SDP O/A issue - bundle or no bundle. AFAIK there is wide agreement that an RTP *session* can carry multiple RTP streams. An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP session. There is disagreement whether it is permissible for the resulting RTP session to carry multiple RTP streams. The specs are ambiguous on this point. Clearly there are well identified cases where they do, and we aren't likely to rule those incorrect. Its also clear that some of these cases start out sending a single SSRC, and then later "add" another. (It may actually be a substitution.) So it seems clear to me that you may add an RTP stream to an RTP session described by an m-line without doing another O/A exchange. What is lacking in such cases is a mechanism for describing the role and intent of each RTP stream in the RTP session. In some cases it is possible to get by without this, by assuming that the two ends have consistent *assumptions* about how to infer the role/intent. But there are many cases where this isn't enough. Extra SDP syntax has been defined in an ad hoc way to get at bits and pieces of this problem. E.g., the a=ssrc attribute. What has already been defined doesn't seem suficient for all the new cases we are no discussing. BUNDLE is *another* proposal for addressing part or all of this problem. But BUNDLE brings along another problem: for BUNDLE to be useful, it must be possible to associate each RTP packet with one of the bundled m-lines. Without BUNDLE we don't have that problem. To summarize: - without bundle, we need a mechanism for describing the role/intent of each RTP stream in the RTP session. *If* we choose to describe that with SDP, then we need an O/A exchange each time we add an RTP stream. - with BUNDLE and Plan A, the assumption is that each m-line in the bundle describes a single RTP stream, and so the other SDP stuff in that media section can be used to describe the role/intent of that RTP stream. By design this requires a new m-line for each RTP stream, so adding one requires an O/A. We then assume that there is enough stuff in each media section to decide which m-line each packet should be associated with. - with BUNDLE and Plan B, there may be multiple RTP streams per m-line. As in Plan A we need to associate each packet with one of the m-lines. Like the no-bundle case we still need some mechanism to describe the role/intent if the individual RTP streams. In some cases (e.g., a=ssrc) the same info that classifies to an m-line may also specify the role of each stream. That case also leads to an O/A for each stream add. If you have a non-SDP way to discover the role/intent of each RTP stream, and you use a way of classifying to one of the bundled m-lines *without* enumerating every RTP stream, then you can perhaps avoid an O/A for each stream add. E.g., if you just bundle one audio and one video m-line, and use PT to distinguish those. Note: in above I said Plan A uses an m-line for each RTP stream. That isn't always the case. There are some cases (at least in clue) where each m-line is intended to describe a "flow" (clue capture) that may correspond to different RTP streams over time, or that might include supporting FEC streams, etc. Depending on your assumptions about this case it may start to take on some of the characteristics of Plan B. Thanks, Paul From martin.thomson@gmail.com Tue May 21 15:03:01 2013 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 722011F0D3A for ; Tue, 21 May 2013 15:03:01 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gPx2rGCbPxU for ; Tue, 21 May 2013 15:03:01 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A68D21F0D37 for ; Tue, 21 May 2013 15:03:00 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ed20so1290060lab.9 for ; Tue, 21 May 2013 15:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mGxwBbJH5ur0kIjT9acILwKNl+VXTnBHZcqq+35ShnU=; b=xiRb5unxX+IydqwZhIOELNSQVfrjdlhXmIBU8wvQg6fRVwZMYw8wcBOoiLJlbX7UcM 42Pnc7rmCM13HUrwQ9HpqPThYhG8mnzBQhiwBs8QatomES2jlr9vWRX+84B/lRzM7bEh uwN0LM14IFs1gxL0cEKtVI8xnUgc+e3OIm/C0jgCQD/h4PGo6GIpKQKVqpyqgJP1/6b8 4GrE4gUG9JbAzzTxq7t0JBxKPY0MxjF70NfXTCihiFwM7vuZ0op28IVSUWu0Hmf+58GO 7lJi1Rh/EcIx7iQeALSrfBL2iemEWsUSjWHnA9vVfoEh+VXT3nA16nh4qlpcmhacf1sm WAtQ== MIME-Version: 1.0 X-Received: by 10.112.204.194 with SMTP id la2mr2671582lbc.38.1369173779568; Tue, 21 May 2013 15:02:59 -0700 (PDT) Received: by 10.112.235.233 with HTTP; Tue, 21 May 2013 15:02:59 -0700 (PDT) In-Reply-To: <519BD580.7080205@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> Date: Tue, 21 May 2013 15:02:59 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 22:03:01 -0000 This is an excellent summary. On 21 May 2013 13:13, Paul Kyzivat wrote: > AFAIK there is wide agreement that an RTP *session* can carry multiple RTP > streams. > > An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP > session. There is disagreement whether it is permissible for the resulting > RTP session to carry multiple RTP streams. Nitpick: As I understand it, there's a disagreement whether O/A allows for creating multiple streams *in each negotiated direction*... as determined by a=sendrecv/sendonly/recvonly/inactive. In the Plan A view, there are 0 or 1 streams in the each "negotiated open" direction. The SSRC might change over time, but it maps to the same rendering. In the Plan B view, there are 0 or more streams in the each "negotiated open" direction. I believe that the assumption is that every SSRC is a different rendering (in the absence of a=ssrc:... previous-ssrc:...). > The specs are ambiguous on this > point. Clearly there are well identified cases where they do, and we aren't > likely to rule those incorrect. Its also clear that some of these cases > start out sending a single SSRC, and then later "add" another. (It may > actually be a substitution.) From karl.stahl@intertex.se Tue May 21 16:03:08 2013 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 3BCA411E80E8; Tue, 21 May 2013 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WuA9d85G2iU; Tue, 21 May 2013 16:03:01 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 039D121F929F; Tue, 21 May 2013 16:02:57 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305220102421239; Wed, 22 May 2013 01:02:42 +0200 From: "Karl Stahl" To: , References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> Date: Wed, 22 May 2013 01:02:40 +0200 Message-ID: <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CE5688.0ECFE650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOVTqUu83hGBO03EOmioPLICQbqpkN5f0AgABIK4CAAXZogIAAbTOA Content-Language: sv Subject: [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 23:03:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CE5688.0ECFE650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, =20 Isn=92t such a low quality fallback channel for penetrating restrictive NAT/Firewalls NEGATIVE for RTCweb? =20 QUALITY: Any tunneling of RTP through the =93always open=94 HTTP 80 or = HTTPS 443 ports is RTP over an error correcting TCP channel. Thus, lost packets = will be retransmitted, resulting in second long packet delays. Jitter buffers don=92t handle that and if they did, we will not be happy with second = long delays in RTC, i.e. two-way real-time communications. That is why we run = RTP over UDP. =20 (When discussing QoS, some will stand up and tell that sound quality = really was good =96 it is all about bandwidth, etc. Yes, quality in an IP = network is good when you don=92t fill the pipe =96 even this TCP-pipe is. But in = today=92s data crowded networks, where you are not alone, the pipe is filled at = every email or click on a webpage. Then packets are lost, and with the = fallback discussed you don=92t even have the benefit of UDP over TCP transport.) =20 SKYPE: Yes, I know Skype has a similar fallback =96 same low quality - = and I have heard the argument =93Otherwise we will have to continue answering = for another 10 years "why is this app not working if skype does". But why = should that be the ambition of the RTCweb standards? =20 DECIDING NETWORK USAGE: Doesn=92t the network administrator that = configured the firewall have a legitimate right to decide what traffic should be on = his network? If he only wants internal traffic and surfing, shouldn=92t it = be his choice to be able to configure just that? And if a service provider (SP) blocks all but surfing on his access, the user can get another = subscription if he wants to benefit from using RTCweb (and that SP will go out of business=85or can just offer his access at a very low cost for surfing = only usage). =20 Not getting RTCweb through a restrictive firewall, may rather encourage = the network administer to resolve the problem properly, than if we provide a fallback with lousy quality. Then the user may not be interested in the = =93bad RTCweb=94 and won=92t ask his network administrator to =93enable it=94. =20 BETTER THAN BEST EFFORT: Actually, it we =93enable networks for = RTCweb=94, we could quality wise get a BETTER pipes for RTCweb media than for surfing! = The STUN/TURN server address provided actually allows ICE/TURN/STUN media to = be routed another path than data traffic =96 a better path, maybe even with = level 3 QoS (diffserve or RSVP if we are lucky). =20 Remember, that we finally are stepping up from 100 years old 3,5 kHz = voice only to potentially telepresence HiFi HD 3.5 Mbps quality. We should encourage that the networks support this potential, rather than = providing a low quality fallback, that will bring a bad user experience to RTCweb. =20 NEW VIEW ON ICE: I think it is time to view the ICE/TURN/STUN protocol = suit in an alternative way. Instead of being a way to fool or trick media = through a NAT/Firewall that is unaware of what is happening, regard = ICE/TURN/STUN as a protocol to Request Access for RTC through the firewall. Firewalls =96 = if combined with the STUN/TURN server =96 could then respond not just by = opening a path for RTC, but could also prioritize and shape the traffic in the firewall for much better quality. (A firewall is often the point where congestion can be controlled.) And the firewall could request quality = over the transport network for the RTC media (heard cable operators were interested to do that with their reservation type of QoS they use for = voice) =96 others could use diffserve. =20 TURN and STUN servers also include authentication =96 Maybe they were = intended for =93Request pass trough=94 rather than =93Fool media through=94, were = they? =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [ mailto:rtcweb-bounces@ietf.org] F=F6r = Hutton, Andrew Skickat: den 21 maj 2013 15:34 Till: Simon Pietro Romano Kopia: rtcweb@ietf.org; = behave@ietf.org =C4mne: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt =20 Hi Simon =20 I believe all possible solutions deserve attention however my feeling is that the HTTP Connect based mechanism for connecting to the TURN server = via TURN/TCP/TLS has a good chance of being implemented by browsers. =20 What I would really like to happen is for draft-hutton-rtcweb-nat-firewall-considerations to be adopted and = progressed by the WG to describe the preferred solution whatever it might be. =20 In the next update we could add some text describing the alternatives to = the HTTP CONNECT based mechanism to promote further discussion at least we = seem to have some agreement that a solution is needed. =20 Regards Andy =20 =20 From: Simon Pietro Romano [mailto:spromano@unina.it]=20 Sent: 20 May 2013 18:12 To: Hutton, Andrew Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt =20 I keep on thinking that the solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt = deserves attention. =20 Simon =20 Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: Regarding the HTTP fallback and whether this could be adapted to be a = TURN over HTTP based solution then I think the same comments that were made = on the TURN over websockets apply. What are the benefits of creating a new transport for TURN over what we can do using HTTP Connect as described = in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-0 0. Having said that I am really happy we are having this debate as we = really need to find a solution here that the browser vendors will implement so = I would really like to know which options they prefer. I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to document whatever the working group agrees on = being the right solution. Regards Andy -----Original Message----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] Sent: 20 May 2013 10:15 To: Gustavo Garc=EDa Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-chenxin- behave-turn-websocket-00.txt =20 Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa ha scritto: =20 I agree that TURN over websockets doesn't solve much more scenarios than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over HTTP that aside of philosophical discussions would be the solution with better success rate? Otherwise we will have to continue answering for another 10 years "why is this app not working if skype does". =20 Something like this draft sent some months ago but perhaps for TURN instead of direct connections: http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt =20 =20 =20 When I submitted that draft this summer, I had that exact purpose in mind, that is taking care of corner edge cases like restrictive proxies and the like. Of course it was not meant to be a solution, just a way to foster discussion in that direction. In that discussion I also mentioned some work we did about this in the past, which in part apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations: =20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html =20 At the time most people in the ML thought it was either too useless, too complex or even harmful, considering it could be considered as a "sneaky" way to circumvent rules added by a network administrator, and so unacceptable. Anyway, as I said back then, a solution like this doesn't have to be sneaky, and it could very well be conceived in order to be admin-friendly rather than have a parrot and a wooden leg. =20 Whether we actually need something like this or TURN-over-443 is enough I don't know: I still think it may be useful to tackle scenarios where everything else fails (the "skype works here" effect), so I'd be glad to be of help in that direction if needed. =20 Lorenzo =20 =20 =20 On 16/05/2013, at 01:28, Hutton, Andrew wrote: =20 I agree with Bernard's comments regarding the impact of DPI but of course such DPI devices do what they do and we can't and even don't want to stop them from doing it. However for the case when policy is such that the firewall will only allow traffic to traverse that comes from the HTTP Proxy or a network specific TURN server and there is no deliberate policy to block WebRTC media we need a solution and this is what draft-hutton-rtcweb-nat-firewall-considerations-00 addresses. =20 So far I don't see the benefit that TURN over websockets would have in this scenario and it needs additional implementation in the browser and the TURN server. =20 Regards Andy =20 =20 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 15 May 2013 18:20 To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- behave-turn-websocket-00.txt =20 Andrew Hutton said: When we wrote the draft http://tools.ietf.org/html/draft-hutton- rtcweb-nat-firewall-considerations-00 we did not include this option because we did not see the benefit of additional transport options for TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. =20 So what would be the benefits that justify this addition transport option for TURN? =20 [BA] In my experience, institutions with very restrictive security policies (e.g. those that don't allow UDP in or out) also tend to deploy other measures such as deep packet inspection. So just because some traffic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine the traffic and complain if it doesn't see HTTP being used. On the other hand, unless the DPI box is upgraded, it will also complain about websockets. So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP would not be. That scenario is rare, at least at the moment. =20 The argument for TURN over Websocket/TLS is even more difficult to make. While DPI boxes may examine traffic destined to port 443 carefully to make sure that TLS is really being used, assuming that the DPI box does not see anything it considers fishy, the TLS exchange will complete and the DPI box will lose visibility. After TLS is running, the DPI box does not have much information available to distinguish TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as packet size) are as likely to result in an objection to websocket transport as TURN/TLS. So I'm not sure that draft-chenxin will help in that situation either. =20 =20 =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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro = Romano Universita' di Napoli Federico II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it =20 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) = ) / = (_/ =20 =20 =20 =20 ------=_NextPart_000_0001_01CE5688.0ECFE650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Al= l,

 

Is= n’t such a low quality fallback channel for penetrating = restrictive NAT/Firewalls NEGATIVE for RTCweb?

 

QU= ALITY: Any tunneling of RTP through the “always open” HTTP = 80 or HTTPS 443 ports is RTP over an error correcting TCP channel. Thus, = lost packets will be retransmitted, resulting in second long packet = delays. Jitter buffers don’t handle that and if they did, we will = not be happy with second long delays in RTC, i.e. two-way real-time = communications. That is why we run RTP over UDP.

 

(W= hen discussing QoS, some will stand up and tell that sound quality = really was good – it is all about bandwidth, etc. Yes, quality in = an IP network is good when you don’t fill the pipe – even = this TCP-pipe is. But in today’s data crowded networks, where you = are not alone, the pipe is filled at every email or click on a webpage. = Then packets are lost, and with the fallback discussed you don’t = even have the benefit of UDP over TCP = transport.)

 

SK= YPE: Yes, I know Skype has a similar fallback – same low quality - = and I have heard the argument “Otherwise = we will have to continue answering for another 10 years "why is = this app not working if skype does". Bu= t why should that be the ambition of the RTCweb = standards?

 

DE= CIDING NETWORK USAGE: Doesn’t the network administrator that = configured the firewall have a legitimate right to decide what traffic = should be on his network? If he only wants internal traffic and surfing, = shouldn’t it be his choice to be able to configure just that? And = if a service provider (SP) blocks all but surfing on his access, the = user can get another subscription if he wants to benefit from using = =A0RTCweb (and that SP will go out of business…or can just offer = his access at a very low cost for surfing only = usage).

 

No= t getting RTCweb through a restrictive firewall, may rather encourage = the network administer to resolve the problem properly, than if we = provide a fallback with lousy quality. Then the user may not be = interested in the “bad RTCweb” and won’t ask his = network administrator to “enable = it”.

 

BE= TTER THAN BEST EFFORT: Actually, it we “enable networks for = RTCweb”, we could quality wise get a BETTER pipes for RTCweb media = than for surfing! The STUN/TURN server address provided actually allows = ICE/TURN/STUN media to be routed another path than data traffic – = a better path, maybe even with level 3 QoS (diffserve or RSVP if we are = lucky).

 

Re= member, that we finally are stepping up from 100 years old 3,5 kHz voice = only to potentially telepresence HiFi HD 3.5 Mbps quality. We should = encourage that the networks support this potential, rather than = providing a low quality fallback, that will bring a bad user experience = to RTCweb.

 

NE= W VIEW ON ICE: I think it is time to view the ICE/TURN/STUN protocol = suit in an alternative way. Instead of being a way to fool or trick = media through a NAT/Firewall that is unaware of what is happening, = regard ICE/TURN/STUN as a protocol to Request Access for RTC through the = firewall. Firewalls – if combined with the STUN/TURN server = – could then respond not just by opening a path for RTC, but could = also prioritize and shape the traffic in the firewall for much better = quality. (A firewall is often the point where congestion can be = controlled.) And the firewall could request quality over the transport = network for the RTC media (heard cable operators were interested to do = that with their reservation type of QoS they use for voice) – = others could use diffserve.

 

TU= RN and STUN servers also include authentication – Maybe they were = intended for “Request pass trough” rather than “Fool = media through”, were they?

 

/K= arl

 

 

Fr=E5n: = rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] F=F6r = Hutton, Andrew
Skickat: den 21 maj 2013 = 15:34
Till: Simon Pietro Romano
Kopia: rtcweb@ietf.org; = behave@ietf.org
=C4mn= e: Re: [rtcweb] New Version Notification for = draft-chenxin-behave-turn-websocket-00.txt

 

Hi Simon

 

I believe all possible solutions deserve attention however my feeling = is that the HTTP Connect based mechanism for connecting to the TURN = server via TURN/TCP/TLS has a good chance of being implemented by = browsers.

 

What I would really like to happen is for = draft-hutton-rtcweb-nat-firewall-considerations to be adopted and = progressed by the WG to describe the preferred solution whatever it = might be.

 

In the next update we could add some text describing the alternatives = to the HTTP CONNECT based mechanism to promote further discussion at = least we seem to have some agreement that a solution is = needed.

 

Regards

Andy

 

 

From:= Simon = Pietro Romano [mailto:spromano@unina.it] =
Sent: 20 May 2013 18:12
To: Hutton, = Andrew
Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.org
Subject: = Re: [rtcweb] New Version Notification for = draft-chenxin-behave-turn-websocket-00.txt

 

I keep on thinking that the = solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt=  deserves attention.

 

Simon

 

Il giorno 20/mag/2013, alle ore = 13:06, Hutton, Andrew ha scritto:




Regarding the HTTP fallback and = whether this could be adapted to be a TURN over HTTP based solution then = I think the same comments that were made on the TURN over websockets = apply. What are the benefits of creating a new transport for TURN over = what we can do using HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall= -considerations-00.

Having said that I am really happy we are = having this debate as we really need to find a solution here that the = browser vendors will implement so I would really like to know which = options they prefer.

I really hope we can get = draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to = document whatever the working group agrees on being the right = solution.

Regards
Andy




-----Original = Message-----

From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]

Sent: 20 May 2013 = 10:15

To: Gustavo = Garc=EDa

Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org

=

Subject: Re: [rtcweb] New Version = Notification for = draft-chenxin-

behave-turn-websocket-00.txt

 

Il giorno Sun, 19 May 2013 23:20:41 = -0700

Gustavo Garc=EDa <ggb@tokbox.com> ha = scritto:

 

I agree that TURN over websockets = doesn't solve much more = scenarios

than TURN/TLS.   If = trying to fix HTTP Proxy traversal why not = doing

it over HTTP that aside of = philosophical discussions would be = the

solution with better success rate? =  Otherwise we will have = to

continue answering for another 10 = years "why is this app not = working

if skype = does".

 

Something like this draft sent some = months ago but perhaps for = TURN

instead of direct = connections:

http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt=

 

 

 

When I submitted that draft this = summer, I had that exact purpose = in

mind, that is taking care of corner = edge cases like restrictive = proxies

and the like. Of course it was not = meant to be a solution, just a = way

to foster discussion in that = direction. In that discussion I = also

mentioned some work we did about = this in the past, which in = part

apparently ended up in = draft-hutton-rtcweb-nat-firewall-considerations:

 

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html

 

At the time most people in the ML = thought it was either too = useless,

too complex or even harmful, = considering it could be considered as = a

"sneaky" way to = circumvent rules added by a network administrator, = and

so unacceptable. Anyway, as I said = back then, a solution like = this

doesn't have to be sneaky, and it = could very well be conceived in = order

to be admin-friendly rather than = have a parrot and a wooden = leg.

 

Whether we actually need something = like this or TURN-over-443 is = enough

I don't know: I still think it may = be useful to tackle scenarios = where

everything else fails (the = "skype works here" effect), so I'd be = glad

to be of help in that direction if = needed.

 

Lorenzo

 

 

 

On 16/05/2013, at 01:28, Hutton, = Andrew wrote:

 

I agree with Bernard's comments = regarding the impact of DPI but = of

course such DPI devices do what = they do and we can't and even = don't

want to stop them from doing it. = However for the case when = policy

is such that the firewall will only = allow traffic to traverse = that

comes from the HTTP Proxy or a = network specific TURN server = and

there is no deliberate policy to = block WebRTC media we need = a

solution and this is = what

draft-hutton-rtcweb-nat-firewall-considerations-00 = addresses.

 

So far I don't see the benefit that = TURN over websockets would = have

in this scenario and it needs = additional implementation in = the

browser and the TURN = server.

 

Regards

Andy

 

 

-----Original = Message-----

=

From: Bernard Aboba [mailto:bernard_aboba@hotmail.co= m]

Sent: 15 May 2013 = 18:20

To: Hutton, Andrew; Chenxin (Xin); = behave@ietf.org;

rtcweb@ietf.org

=

Subject: RE: [rtcweb] FW: New = Version Notification = for

draft-chenxin- = behave-turn-websocket-00.txt

 

Andrew Hutton = said:

When we wrote the draft http://tools.ietf.org/h= tml/draft-hutton-

rtcweb-nat-firewall-considerations-00 we did not include = this

option because we did not see the = benefit of additional = transport

options for TURN given that the = existing options (E.g. = TURN/TCP

and TURN/TLS) seem to be meet our = needs.

 

So what would be the benefits that = justify this = addition

transport

option for = TURN?

 

[BA] In my experience, =  institutions with very = restrictive

<= /blockquote>

security

policies (e.g. those that don't = allow UDP in or out) also tend = to

deploy other measures such as deep = packet inspection.   So = just

because some traffic is allowed in = or out on port 80 does not = mean

that TURN/TCP will be allowed on = that port - a DPI box may = examine

the traffic and complain if it = doesn't see HTTP being used. =  On

the other hand, unless the DPI box = is upgraded, it will = also

complain about websockets.  So = I think draft-chenxin only helps = in

a situation where TURN over = Websockets would be allowed = when

TURN/TCP would not be.  That = scenario is rare, at least at = the

moment.

 

The argument for TURN over = Websocket/TLS is even more difficult = to

make. While DPI boxes may examine = traffic destined to port = 443

carefully to make sure that TLS is = really being used, =  assuming

that the DPI box does not see = anything it considers fishy, the = TLS

exchange will complete and the DPI = box will lose = visibility.

<= /blockquote>

After TLS is running, the DPI box = does not have much = information

<= /blockquote>

available to distinguish TURN/TLS = from HTTP over TLS, with = or

without websockets -- and those = things it does have (such = as

packet size) are as likely to = result in an objection to = websocket

transport as TURN/TLS.  So I'm = not sure that draft-chenxin = will

help in that situation = either.

 

 

 

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

=

https://www.ietf.or= g/mailman/listinfo/rtcweb

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

=

https://www.ietf.or= g/mailman/listinfo/rtcweb


_______________________________________________
rtcwe= b mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

 

                    =          &n= bsp;           &nb= sp;           &nbs= p;            =      =   _\\|//_

                    =                &n= bsp;           &nb= sp;            =   ( O-O )

  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<= span lang=3DEN-US>

                  =           &n= bsp;           &nb= sp;           &nbs= p;   Simon Pietro Romano

                     &n= bsp;           &nb= sp;           &nbs= p;  Universita' = di Napoli Federico II

                        &n= bsp;       Computer Engineering = Department 

                     Phone: +39 081 = 7683823 -- Fax: +39 081 7683816

                    =                     =    e-mail: spromano@unina.it

 

           &nbs= p;          <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 

           &nbs= p;          idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.

                       &n= bsp;           &nb= sp;                 =      oooO

  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nbs= p;            = ;            =            =                  \ ( =            (   )

           &nbs= p;            = ;                       =               \_)     =      ) /

                    =                     =                     =            (_/

 

 

 

 

------=_NextPart_000_0001_01CE5688.0ECFE650-- From simon.perreault@viagenie.ca Wed May 22 01:00:11 2013 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 E479921F92FB; Wed, 22 May 2013 01:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc4+dS2r9iUH; Wed, 22 May 2013 01:00:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8598C21F92F5; Wed, 22 May 2013 01:00:11 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B531240409; Wed, 22 May 2013 04:00:10 -0400 (EDT) Message-ID: <519C7B17.8070405@viagenie.ca> Date: Wed, 22 May 2013 10:00:23 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org, rtcweb@ietf.org References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> In-Reply-To: <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:00:12 -0000 Le 2013-05-22 01:02, Karl Stahl a écrit : > Doesn’t the network administrator that configured the firewall have > a legitimate right to decide what traffic should be on his network? IMHO this is the strongest argument. STUN/TURN/ICE have always been about NAT traversal. Firewall traversal is a completely different beast. It implies a kind of battle between the client and the firewall, where the client implementer is trying to be smarter than the firewall administrator. This is a battle the IETF should not engage in. Let the vendors play that game. Simon From stefan.lk.hakansson@ericsson.com Wed May 22 01:51:12 2013 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 85C8C21F9619 for ; Wed, 22 May 2013 01:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.874 X-Spam-Level: X-Spam-Status: No, score=-4.874 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcMPAGFOE+dA for ; Wed, 22 May 2013 01:50:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03021F9610 for ; Wed, 22 May 2013 01:50:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-62-519c86f01150 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9A.67.28930.0F68C915; Wed, 22 May 2013 10:50:56 +0200 (CEST) Received: from [150.132.141.62] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 22 May 2013 10:50:56 +0200 Message-ID: <519C86EF.5080601@ericsson.com> Date: Wed, 22 May 2013 10:50:55 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> In-Reply-To: <519BD580.7080205@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvre6HtjmBBrNualis/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ3fnzEW/FevmD/jIGMD4wz5LkZODgkBE4nJV2eyQthiEhfu rWfrYuTiEBI4xSixbuUBsISQwBpGiS+TuUFsXgFticuXz7CA2CwCqhLzey6ygdhsAoES1/// YgKxRQWiJOase8AGUS8ocXLmE7B6EQFhia2vesFqhAUMJZ7e/88Ksewok8Tpr18YQRKcAjoS P3fcBbOZBWwlLsy5zgJhy0tsfzuHGeIgXYl3r++xTmAUmIVkxywkLbOQtCxgZF7FyJ6bmJmT Xm64iREYaAe3/NbdwXjqnMghRmkOFiVx3l7tqYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GJ0fvVz/1H/tT4umSjehis7pAYXCnhKx4od/2CU5OASoeK71SNT13bbqZuriYrevzNej7yg7 meZL5EYan0zZdnnWXac7t3a4bTD+9S1YaHaIaHSgW/AeqekiK+8Z6d1oTVSoPm/N0N9b7aWs 883EYHLDrNaUY3fKe/m2/RVrn8ezndNFPGSmEktxRqKhFnNRcSIA/3h6NwICAAA= Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 08:51:13 -0000 I think this was a good summary. But regarding "a mechanism for describing the role and intent of each RTP stream in the RTP session.", do we really need that? Isn't the combination of ssrc and the msid draft sufficient? Together the clearly identify how ssrc's map into PC-streams and PC-tracks, and the application can convey the remaining info (e.g. PC-stream xx represents the speaker audio+video, yy the room video etc.) needed in any way it likes . Stefan On 2013-05-21 22:13, Paul Kyzivat wrote: > On 5/21/13 3:20 AM, Christer Holmberg wrote: >> Hi, >> >>>> I don't think it's a BUNDLE issue whether adding/removing of streams >>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue. >>>> >>>> BUNDLE is about sharing a 5-tuple. >>> >>> I don't agree. >>> >>> RTP is already able to support multiple RTP streams sharing an RTP >>> session (and 5-tuple). >>> >>> What BUNDLE is about is describing that in SDP. >>> And that includes how SDP O/A works. >> >> Multiple RTP streams can already share an RTP session today, using >> multiple SSRCs per m- line :) >> >> If adding a new stream means adding a new m- line, then an SDP O/A is >> obviously needed - bundle or no bundle. >> >> If adding a new stream means adding a new SSRC, within an existing m-, >> then it is also an SDP O/A issue - bundle or no bundle. > > AFAIK there is wide agreement that an RTP *session* can carry multiple > RTP streams. > > An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP > session. There is disagreement whether it is permissible for the > resulting RTP session to carry multiple RTP streams. The specs are > ambiguous on this point. Clearly there are well identified cases where > they do, and we aren't likely to rule those incorrect. Its also clear > that some of these cases start out sending a single SSRC, and then later > "add" another. (It may actually be a substitution.) > > So it seems clear to me that you may add an RTP stream to an RTP session > described by an m-line without doing another O/A exchange. > > What is lacking in such cases is a mechanism for describing the role and > intent of each RTP stream in the RTP session. In some cases it is > possible to get by without this, by assuming that the two ends have > consistent *assumptions* about how to infer the role/intent. But there > are many cases where this isn't enough. > > Extra SDP syntax has been defined in an ad hoc way to get at bits and > pieces of this problem. E.g., the a=ssrc attribute. What has already > been defined doesn't seem suficient for all the new cases we are no > discussing. > > BUNDLE is *another* proposal for addressing part or all of this problem. > But BUNDLE brings along another problem: for BUNDLE to be useful, it > must be possible to associate each RTP packet with one of the bundled > m-lines. Without BUNDLE we don't have that problem. > > To summarize: > > - without bundle, we need a mechanism for describing the role/intent > of each RTP stream in the RTP session. *If* we choose to describe > that with SDP, then we need an O/A exchange each time we add > an RTP stream. > > - with BUNDLE and Plan A, the assumption is that each m-line in the > bundle describes a single RTP stream, and so the other SDP stuff > in that media section can be used to describe the role/intent of > that RTP stream. By design this requires a new m-line for each > RTP stream, so adding one requires an O/A. We then assume that there > is enough stuff in each media section to decide which m-line each > packet should be associated with. > > - with BUNDLE and Plan B, there may be multiple RTP streams per > m-line. As in Plan A we need to associate each packet with one of > the m-lines. Like the no-bundle case we still need some mechanism > to describe the role/intent if the individual RTP streams. > In some cases (e.g., a=ssrc) the same info that classifies to > an m-line may also specify the role of each stream. That case > also leads to an O/A for each stream add. > > If you have a non-SDP way to discover the role/intent of each > RTP stream, and you use a way of classifying to one of the > bundled m-lines *without* enumerating every RTP stream, then > you can perhaps avoid an O/A for each stream add. E.g., if you > just bundle one audio and one video m-line, and use PT to > distinguish those. > > Note: in above I said Plan A uses an m-line for each RTP stream. That > isn't always the case. There are some cases (at least in clue) where > each m-line is intended to describe a "flow" (clue capture) that may > correspond to different RTP streams over time, or that might include > supporting FEC streams, etc. Depending on your assumptions about this > case it may start to take on some of the characteristics of Plan B. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From karl.stahl@intertex.se Wed May 22 02:05:45 2013 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 50EF421F8FDB; Wed, 22 May 2013 02:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.985 X-Spam-Level: X-Spam-Status: No, score=0.985 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNJ7jOfUbfpq; Wed, 22 May 2013 02:05:40 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2621F8E8E; Wed, 22 May 2013 02:05:36 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305221104535380; Wed, 22 May 2013 11:04:53 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , , References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> In-Reply-To: <519C7B17.8070405@viagenie.ca> Date: Wed, 22 May 2013 11:04:34 +0200 Message-ID: <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5Wwm4Iz5ivH6XVS8ew4EYtZaoshgABmkjA Content-Language: sv Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:05:45 -0000 > Firewall traversal is a completely different beast. Not really. There are always firewall functions included in "a NAT" = (e.g. open for traffic from inside to outside and you can then get traffic = back the same path - with some timeout), even if the RFCs only call the box = "a NAT". I prefer to say NAT/Firewall. ICE/TURN/STUN handles both the NAT and firewall issues to a limit. And the drafts behave-turn-websocket and other about tunneling through http(s) ports are an attempt to extend the limit where the firewall = function (not NAT) is blocking RTCweb (in this case). Actually I think ICE/TURN/STUN even works with a firewall that does not = have NAT enabled at all (as long as UDP ports from inside to outside are open = to use).=20 Having said that, I of course agree that IETF should not extend TURN = with tunneling to pass through a restrictive firewall. /Karl =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Simon Perreault Skickat: den 22 maj 2013 10:00 Till: behave@ietf.org; rtcweb@ietf.org =C4mne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Le 2013-05-22 01:02, Karl Stahl a =E9crit : > Doesn=92t the network administrator that configured the firewall have = a=20 > legitimate right to decide what traffic should be on his network? IMHO this is the strongest argument. STUN/TURN/ICE have always been about NAT traversal. Firewall traversal = is a completely different beast. It implies a kind of battle between the = client and the firewall, where the client implementer is trying to be smarter = than the firewall administrator. This is a battle the IETF should not engage = in. Let the vendors play that game. Simon _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From simon.perreault@viagenie.ca Wed May 22 02:30:43 2013 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 7DA5421F9640; Wed, 22 May 2013 02:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbBkohnjdwa0; Wed, 22 May 2013 02:30:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0A21F963C; Wed, 22 May 2013 02:30:42 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 529C747143; Wed, 22 May 2013 05:30:41 -0400 (EDT) Message-ID: <519C904B.2040305@viagenie.ca> Date: Wed, 22 May 2013 11:30:51 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Karl Stahl References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> In-Reply-To: <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org, behave@ietf.org Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 09:30:44 -0000 Le 2013-05-22 11:04, Karl Stahl a écrit : >> Firewall traversal is a completely different beast. > > Not really. There are always firewall functions included in "a NAT" (e.g. > open for traffic from inside to outside and you can then get traffic back > the same path - with some timeout), even if the RFCs only call the box "a > NAT". I prefer to say NAT/Firewall. You're focusing on the technical aspect. The difference I'm considering is not technical. NAT traversal is performed with the agreement of everyone involved, whereas firewall traversal is a battle between the client implementer and the firewall administrator. There's also a potential arms race: firewalls will evolve with the ability to block whatever we standardize, so we will need a newer traversal method, which firewalls will end up blocking as well, etc. etc. etc. We don't want to play that game. NAT traversal: ok Firewall traversal: not for the IETF Simon From harald@alvestrand.no Wed May 22 04:55:49 2013 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 A041A21F9346 for ; Wed, 22 May 2013 04:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSIygDK5O+rl for ; Wed, 22 May 2013 04:55:44 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 280D321F9223 for ; Wed, 22 May 2013 04:55:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D46BC39E140 for ; Wed, 22 May 2013 13:55:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPuXU3lfRh0C for ; Wed, 22 May 2013 13:55:41 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 975AC39E031 for ; Wed, 22 May 2013 13:55:41 +0200 (CEST) Message-ID: <519CB23C.2050405@alvestrand.no> Date: Wed, 22 May 2013 13:55:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5191F4B8.2020602@ericsson.com> <5192011A.8030903@jitsi.org> In-Reply-To: <5192011A.8030903@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] [MMUSIC] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 11:55:50 -0000 On 05/14/2013 11:17 AM, Emil Ivov wrote: > > On 14.05.13, 11:24, Stefan HĆ„kansson LK wrote: >> On 2013-05-13 19:58, Bernard Aboba wrote: >>> >>> On May 12, 2013, at 10:18, "Stefan HĆ„kansson LK" >>> wrote: >>> >>>>> I would hope there will normally not be SDP changes for either of >>>>> those events. >>>> I would like to avoid them too, but I'm not sure how. >>> [BA] It is probably not possible to avoid them in all cases, but we >>> can define RTCP functionality which along with some set of >>> functionality (e.g. Simulcast, layered coding) will minimize them. >>> This is worth doing (and soon). >> I agree to this! > RTCP `certainly sounds a lot better than SDP O/A > > Emil > If something's doable doing app-level signalling, it can be deployed at the speed of app updates - but each app has to do it on its own. If something's doable using RTCP, it can be deployed at the speed of browser updates - but you have to convince the browser people to do it first. SDP O/A extensions are in an uncomfortable place between these extremes, I think. But it's not obvious to me that one of the three always "sounds better" than the other ones. From harald@alvestrand.no Wed May 22 05:31:33 2013 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 8BB7621F96B6 for ; Wed, 22 May 2013 05:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpvtkEhX5nX6 for ; Wed, 22 May 2013 05:31:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 131DA21F96B1 for ; Wed, 22 May 2013 05:31:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E66839E140; Wed, 22 May 2013 14:31:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ7pq8um7QVC; Wed, 22 May 2013 14:31:24 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 00A9739E031; Wed, 22 May 2013 14:31:23 +0200 (CEST) Message-ID: <519CBA9B.8030509@alvestrand.no> Date: Wed, 22 May 2013 14:31:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080701050205080204030008" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-uberti-rtcweb-plan-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 12:31:33 -0000 This is a multi-part message in MIME format. --------------080701050205080204030008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The formatting gave me some pause, but just a few points.... >2.1 > > These layouts can change dynamically, depending on the conference > content and the preferences of the receiver. As such, there are not > well-defined 'roles', that could be used to group sources into > specific 'large' or 'thumbnail' categories. As such, the requirement > Plan B attempts to satisfy is support for sending and receiving up to > hundreds of simultaneous, hetereogeneous sources. [BA] While I agree that the layouts can change dynamically, I am wondering if there is an implication that the burden of determining the 'roles' is on the mixer. For example, it might be assumed that the mixer allocates an SSRC for the 'large' category, and other SSRCs for the 'thumbnails' and then these SSRCs are statically mapped to MSTs and rendered. However, another way to handle it is for the browser to handle the role assignment, and I would argue that this could make more sense in some cases, particularly since this could make the mixer a lot simpler, or even obviate the need for a mixer entirely (e.g. an RTP translator might work in some cases). [HTA] I think what the draft attempts to say and what Bernard is trying to say as "another way" are the same thing - we're looking at a scenario where SSRCs don't have preallocated roles that dictate whether they make sense as a thumbnail-sized flows or a big-screen flow. The decision can be taken at the sender, at the mixer or at the receiver - that depends on application logic, and should be left to application logic. >2.6. Simple binding of MediaStreamTrack to SDP > > In WebRTC, each media source is identified by a MediaStreamTrack > object. In order to ensure that the MSTs created by the sender show > up at the receiver, each MST's id attribute needs to be reflected in > SDP. [BA] While I might understand why the MST ID might be useful to expose in the API, I don't see why this needs to be signaled over the wire. In general, since WebRTC is supposed to be "signaling independent", we should try to avoid signaling things that don't need to be signaled. With respect to MST id, a number of approaches seem preferrable, including use of an RTP SDES item, or (even better) allowing the receiver to determine which MediaStreamTrack an incoming RTP stream belongs to when the SSRC is first received. [HTA] I'm thinking about ways to achieve that effect, but that puts more requirements on the out-of-band signalling channels, not less. The purpose of MSID was to allocate stable identifiers for the streams, without prejudging the ways in which these could be associated with each other. --------------080701050205080204030008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The formatting gave me some pause, but just a few points....

>2.1
>
>   These layouts can change dynamically, depending on the conference
>   content and the preferences of the receiver.  As such, there are not
>   well-defined 'roles', that could be used to group sources into
>   specific 'large' or 'thumbnail' categories.  As such, the requirement
>   Plan B attempts to satisfy is support for sending and receiving up to
>   hundreds of simultaneous, hetereogeneous sources.

[BA] While I agree that the layouts can change dynamically, I am wondering if there is an implication that the burden of determining the 'roles' is on the mixer.  For example, it might be assumed that the mixer allocates an SSRC for the 'large' category, and other SSRCs for the 'thumbnails' and then these SSRCs are statically mapped to MSTs and rendered.  However, another way to handle it is for the browser to handle the role assignment, and I would argue that this could make more sense in some cases, particularly since this could make the mixer a lot simpler, or even obviate the need for a mixer entirely (e.g. an RTP translator might work in some cases). 

[HTA] I think what the draft attempts to say and what Bernard is trying to say as "another way" are the same thing - we're looking at a scenario where SSRCs don't have preallocated roles that dictate whether they make sense as a thumbnail-sized flows or a big-screen flow.

The decision can be taken at the sender, at the mixer or at the receiver - that depends on application logic, and should be left to application logic.


>2.6.  Simple binding of MediaStreamTrack to SDP
>
>   In WebRTC, each media source is identified by a MediaStreamTrack
>   object.  In order to ensure that the MSTs created by the sender show
>   up at the receiver, each MST's id attribute needs to be reflected in
>   SDP.

[BA] While I might understand why the MST ID might be useful to expose in the API, I don't see why this needs to be signaled over the wire. In general, since WebRTC is supposed to be "signaling independent", we should try to avoid signaling things that don't need to be signaled.  With respect to MST id, a number of approaches seem preferrable, including use of an RTP SDES item, or (even better)
allowing the receiver to determine which MediaStreamTrack an incoming RTP stream belongs to when the SSRC is first received.

[HTA] I'm thinking about ways to achieve that effect, but that puts more requirements on the out-of-band signalling channels, not less. The purpose of MSID was to allocate stable identifiers for the streams, without prejudging the ways in which these could be associated with each other.

--------------080701050205080204030008-- From stefan.lk.hakansson@ericsson.com Wed May 22 06:24:32 2013 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 4712021F85C9 for ; Wed, 22 May 2013 06:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.46 X-Spam-Level: X-Spam-Status: No, score=-5.46 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOergDPKvH4g for ; Wed, 22 May 2013 06:24:27 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 827CB21F9289 for ; Wed, 22 May 2013 06:24:26 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-78-519cc706a544 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.DD.31782.607CC915; Wed, 22 May 2013 15:24:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 22 May 2013 15:24:22 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand Thread-Topic: [rtcweb] [MMUSIC] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOVuNUVc0cHK+7F0+aAnWXwRLxCw== Date: Wed, 22 May 2013 13:24:21 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2D033B@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5191F4B8.2020602@ericsson.com> <5192011A.8030903@jitsi.org> <519CB23C.2050405@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvrS7b8TmBBo3/lS2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGV8eR9RcFy04klrZQPjScEuRk4OCQETiZ5d zcwQtpjEhXvr2boYuTiEBA4zSizo/cII4SxhlGiaeIoRpIpNIFBi674FbCC2iICOxMP9DUwg NrOAusSdxefYuxg5OIQFwiQuz+OAKAmXaJgwEapcT+L79h5WkBIWAVWJ8ycqQcK8Ar4St149 Y4VYdZVF4nfzBBaQBCPQQd9PrYEaLy5x68l8JohDBSSW7DkPdbSoxMvH/1ghbCWJHxsusUDU 60ncmDqFDcLWlli28DUzxDJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25iZk56udEm RmAcHNzyW3UH451zIocYpTlYlMR5e7WnBgoJpCeWpGanphakFsUXleakFh9iZOLglGpgrNjE WVoe4rJw6/Ekn+1HnV3LLprqyx4PebXnSex+ywrFtdM/awlfdFKI1N9slCToX3W66pD8pmhb jkVWMq8nTb96lrly+jaLubfD9htcV7c4e3ijn6aWn7dRs6BWxLbGbl71JdZ27yfPrClbvJ+d 6a2Kluur56zSZZZL0q5tlHVb/XKB7hcVJZbijERDLeai4kQAptQsg1ECAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 13:24:32 -0000 On 5/22/13 1:56 PM, Harald Alvestrand wrote:=0A= > On 05/14/2013 11:17 AM, Emil Ivov wrote:=0A= >>=0A= >> On 14.05.13, 11:24, Stefan H=E5kansson LK wrote:=0A= >>> On 2013-05-13 19:58, Bernard Aboba wrote:=0A= >>>>=0A= >>>> On May 12, 2013, at 10:18, "Stefan H=E5kansson LK"=0A= >>>> wrote:=0A= >>>>=0A= >>>>>> I would hope there will normally not be SDP changes for either of=0A= >>>>>> those events.=0A= >>>>> I would like to avoid them too, but I'm not sure how.=0A= >>>> [BA] It is probably not possible to avoid them in all cases, but we=0A= >>>> can define RTCP functionality which along with some set of=0A= >>>> functionality (e.g. Simulcast, layered coding) will minimize them.=0A= >>>> This is worth doing (and soon).=0A= >>> I agree to this!=0A= >> RTCP `certainly sounds a lot better than SDP O/A=0A= >>=0A= >> Emil=0A= >>=0A= > If something's doable doing app-level signalling, it can be deployed at= =0A= > the speed of app updates - but each app has to do it on its own.=0A= >=0A= > If something's doable using RTCP, it can be deployed at the speed of=0A= > browser updates - but you have to convince the browser people to do it=0A= > first.=0A= >=0A= > SDP O/A extensions are in an uncomfortable place between these extremes,= =0A= > I think. But it's not obvious to me that one of the three always "sounds= =0A= > better" than the other ones.=0A= =0A= I think that having things like pause/resume signaling (and perhaps =0A= resolution and the like) in RTCP would be better than SDP, not least =0A= because you escape the session related state model for this kind of =0A= signaling (which I can see can be frequent in scenarios when you want to = =0A= save transmission). And I think that standardized signaling it preferred = =0A= since the functionality enabled would then be easily available also to =0A= more naive developers.=0A= =0A= But, I think what you prefer to a large extent depends on your =0A= viewpoint, and also what scenarios you consider, so I could agree that =0A= it is not obvious that one way would always be better than the other ones.= =0A= =0A= There was a discussion on RTCP vs SDP signaling at an earlier IETF =0A= meeting, and the group at that time preferred SDP signaling. But I don't = =0A= think a concrete proposal on how to do pause request/indication, resume =0A= request/indication etc. was ever put together (there are hints in the =0A= draft-juberti-plan-00). Perhaps that should be the first thing to do?=0A= =0A= >=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From pkyzivat@alum.mit.edu Wed May 22 08:31:29 2013 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 A18E421F91A0 for ; Wed, 22 May 2013 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbbudKgc+Lln for ; Wed, 22 May 2013 08:31:23 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 1872B21F83EF for ; Wed, 22 May 2013 08:31:19 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id ezak1l00617dt5G5A3XKCH; Wed, 22 May 2013 15:31:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id f3XK1l00Z3ZTu2S3Z3XKVP; Wed, 22 May 2013 15:31:19 +0000 Message-ID: <519CE4C6.1040003@alum.mit.edu> Date: Wed, 22 May 2013 11:31:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369236679; bh=LE1nBk32dQ/FE/Dmo8733WNU7Uoj6P/k5kPEPMjkwfY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MAtecd82/2eRXx8KqviuopBiYv0Pz7EDf6HOLaDy7oVfug46N/RVclI1Cp+m4ywz0 tlFo0FKt1YKlX0I4o9CUyeeoydgY8uhqAzDCzwd329rJKxixhE2z9rPeYl8M9ELnhy dRdd0gKj+o8qGjJXAC4BDSR00NdFe0muUhqpuGpsfFxrexOIl4sT2Z/iNXSjyZ7CWE 4ATsnMSbbrRU9Jgts3s37vDjDA8JKI+hIt6DtikZYGY9YnYtKYVl0g7pXR8P9KgXBv Lx1S+k03YWOvI57EPRfLH4haRWqV8DfhH+wm9TJr7c14m9hFY/wDQsveiTdcCtlP+p KCR1Z78Xjegdg== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:31:29 -0000 On 5/21/13 6:02 PM, Martin Thomson wrote: > This is an excellent summary. > > On 21 May 2013 13:13, Paul Kyzivat wrote: >> AFAIK there is wide agreement that an RTP *session* can carry multiple RTP >> streams. >> >> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP >> session. There is disagreement whether it is permissible for the resulting >> RTP session to carry multiple RTP streams. > > Nitpick: > > As I understand it, there's a disagreement whether O/A allows for > creating multiple streams *in each negotiated direction*... as > determined by a=sendrecv/sendonly/recvonly/inactive. > In the Plan A view, there are 0 or 1 streams in the each "negotiated > open" direction. The SSRC might change over time, but it maps to the > same rendering. So your nit is that for sendrecv there might be *two* (one each way) rather than just one? Sure, *for BUNDLE* I agree with that. I don't agree that is the agreed meaning of an unbundled m-line. > In the Plan B view, there are 0 or more streams in the each > "negotiated open" direction. I believe that the assumption is that > every SSRC is a different rendering (in the absence of a=ssrc:... > previous-ssrc:...). Or some other attributes that affect it. >> The specs are ambiguous on this >> point. Clearly there are well identified cases where they do, and we aren't >> likely to rule those incorrect. Its also clear that some of these cases >> start out sending a single SSRC, and then later "add" another. (It may >> actually be a substitution.) > From pkyzivat@alum.mit.edu Wed May 22 08:39:13 2013 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 6D7EA21F955C for ; Wed, 22 May 2013 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMzTmEZRe82c for ; Wed, 22 May 2013 08:39:08 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id BAFE721F95DC for ; Wed, 22 May 2013 08:39:04 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta02.westchester.pa.mail.comcast.net with comcast id ezfR1l0030SCNGk513f4Qn; Wed, 22 May 2013 15:39:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id f3f31l01C3ZTu2S3V3f3fC; Wed, 22 May 2013 15:39:04 +0000 Message-ID: <519CE696.1010606@alum.mit.edu> Date: Wed, 22 May 2013 11:39:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> In-Reply-To: <519C86EF.5080601@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369237144; bh=cJv0QA/iVTqfuGOAtNn0LJWhu0MIahZ9J+Da+5bo/Ms=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MN/uH09vncc0yfItGSuvO9pIoHAE8HzlDrVf8Hfa/j9kEsEQ0CdR3MalxHQrG5XQf W3vYS/EonJcWxjLi8yr5YAiSXWsSm5tEKzGVOyWgubNtUI7zd5sfKNjvEe/PY4C+VL c1Pamqq88ce2Y5kPPDHFFloEY6iDVfqK53doL+ApGzOM1+q9ppZWOEqdv0f7Qd37gz SADTcjR/OQc49LYhE+KnlAFFL/QKSMPAYHhZAaj4vAYtUAqRQJXwB4OqVvZhcJTlxG EKJfe/L50nT8VoIlVJlHNA7lZkX/vIMeyrcKCDmRDy7C+JukPEUtVWUaLfkBjjuDEo G6nuwczV0EBUQ== Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 15:39:13 -0000 On 5/22/13 4:50 AM, Stefan Håkansson LK wrote: > I think this was a good summary. > > But regarding "a mechanism for describing the role and intent of each > RTP stream in the RTP session.", do we really need that? Isn't the > combination of ssrc and the msid draft sufficient? > > Together the clearly identify how ssrc's map into PC-streams and > PC-tracks, and the application can convey the remaining info (e.g. > PC-stream xx represents the speaker audio+video, yy the room video etc.) > needed in any way it likes . My statements were not intended to be rtcweb-specific. The bundling stuff is going to be a more general SDP extension. IMO the problems that rtcweb and clue have encountered that need this are just the tip of the iceberg. My point about the role/intent is that the application must have some means to determine this. It doesn't always need to be in SDP. But the old approach that is mostly based on the cases being so simple that it is always obvious without signaling are now breaking down. And in the case of SIP apps there are few mechanisms to build on other than SDP. Thanks, Paul > Stefan > > On 2013-05-21 22:13, Paul Kyzivat wrote: >> On 5/21/13 3:20 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> I don't think it's a BUNDLE issue whether adding/removing of streams >>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue. >>>>> >>>>> BUNDLE is about sharing a 5-tuple. >>>> >>>> I don't agree. >>>> >>>> RTP is already able to support multiple RTP streams sharing an RTP >>>> session (and 5-tuple). >>>> >>>> What BUNDLE is about is describing that in SDP. >>>> And that includes how SDP O/A works. >>> >>> Multiple RTP streams can already share an RTP session today, using >>> multiple SSRCs per m- line :) >>> >>> If adding a new stream means adding a new m- line, then an SDP O/A is >>> obviously needed - bundle or no bundle. >>> >>> If adding a new stream means adding a new SSRC, within an existing m-, >>> then it is also an SDP O/A issue - bundle or no bundle. >> >> AFAIK there is wide agreement that an RTP *session* can carry multiple >> RTP streams. >> >> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP >> session. There is disagreement whether it is permissible for the >> resulting RTP session to carry multiple RTP streams. The specs are >> ambiguous on this point. Clearly there are well identified cases where >> they do, and we aren't likely to rule those incorrect. Its also clear >> that some of these cases start out sending a single SSRC, and then later >> "add" another. (It may actually be a substitution.) >> >> So it seems clear to me that you may add an RTP stream to an RTP session >> described by an m-line without doing another O/A exchange. >> >> What is lacking in such cases is a mechanism for describing the role and >> intent of each RTP stream in the RTP session. In some cases it is >> possible to get by without this, by assuming that the two ends have >> consistent *assumptions* about how to infer the role/intent. But there >> are many cases where this isn't enough. >> >> Extra SDP syntax has been defined in an ad hoc way to get at bits and >> pieces of this problem. E.g., the a=ssrc attribute. What has already >> been defined doesn't seem suficient for all the new cases we are no >> discussing. >> >> BUNDLE is *another* proposal for addressing part or all of this problem. >> But BUNDLE brings along another problem: for BUNDLE to be useful, it >> must be possible to associate each RTP packet with one of the bundled >> m-lines. Without BUNDLE we don't have that problem. >> >> To summarize: >> >> - without bundle, we need a mechanism for describing the role/intent >> of each RTP stream in the RTP session. *If* we choose to describe >> that with SDP, then we need an O/A exchange each time we add >> an RTP stream. >> >> - with BUNDLE and Plan A, the assumption is that each m-line in the >> bundle describes a single RTP stream, and so the other SDP stuff >> in that media section can be used to describe the role/intent of >> that RTP stream. By design this requires a new m-line for each >> RTP stream, so adding one requires an O/A. We then assume that there >> is enough stuff in each media section to decide which m-line each >> packet should be associated with. >> >> - with BUNDLE and Plan B, there may be multiple RTP streams per >> m-line. As in Plan A we need to associate each packet with one of >> the m-lines. Like the no-bundle case we still need some mechanism >> to describe the role/intent if the individual RTP streams. >> In some cases (e.g., a=ssrc) the same info that classifies to >> an m-line may also specify the role of each stream. That case >> also leads to an O/A for each stream add. >> >> If you have a non-SDP way to discover the role/intent of each >> RTP stream, and you use a way of classifying to one of the >> bundled m-lines *without* enumerating every RTP stream, then >> you can perhaps avoid an O/A for each stream add. E.g., if you >> just bundle one audio and one video m-line, and use PT to >> distinguish those. >> >> Note: in above I said Plan A uses an m-line for each RTP stream. That >> isn't always the case. There are some cases (at least in clue) where >> each m-line is intended to describe a "flow" (clue capture) that may >> correspond to different RTP streams over time, or that might include >> supporting FEC streams, etc. Depending on your assumptions about this >> case it may start to take on some of the characteristics of Plan B. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 stefan.lk.hakansson@ericsson.com Wed May 22 09:08:37 2013 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 DE33B21F9654 for ; Wed, 22 May 2013 09:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.909 X-Spam-Level: X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7muvAV52cSm4 for ; Wed, 22 May 2013 09:08:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E736321F966F for ; Wed, 22 May 2013 09:08:31 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-76-519ced7ea725 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BC.24.31782.E7DEC915; Wed, 22 May 2013 18:08:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Wed, 22 May 2013 18:08:30 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnvVOdWtOdCUWaMjkjMpyI8A== Date: Wed, 22 May 2013 16:08:29 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrW7d2zmBBpNvqFqs2HCA1WLtv3Z2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjxWbLghfWFXtnf2RpYPyi38XIySEhYCLR e7mBCcIWk7hwbz1bFyMXh5DAYUaJ7k/fwBJCAksYJY4u1Aax2QQCJbbuWwBUxMEhIqAhMWmr GkiYWUBd4s7ic+wgtrCAocTT+/9ZQWwRASOJa+v3s0DYehIbNr0Ai7MIqErM7pkFFucV8JX4 t+4oM8TeicwS/Q0v2EASjEAHfT+1hgligbjErSfzoQ4VkFiy5zwzhC0q8fLxP1YIW0micckT Voh6PYkbU6ewQdjaEssWvmaGWCYocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGJkz03MzEkv N9rECIyEg1t+q+5gvHNO5BCjNAeLkjhvr/bUQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M WyaXb3/PdvVP2N6d5z7vv3HU8FBtWaTK2+19pXoHQtv+NDrfMHOzyXSq3cVcsoT9Wr7Afv2H csddFRyPyTAteddUylWo+GLW5M1yL9ZN7NZ7M/FZ0HIhBsbsg+qH9M5ItPIIJZ9ve97paMW6 r/U85/Mv1e/6b1782pv52PZ8Wbb01rQU75tsSizFGYmGWsxFxYkAbaKyF1ICAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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 May 2013 16:08:38 -0000 On 5/22/13 5:41 PM, Paul Kyzivat wrote:=0A= > On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote:=0A= >> I think this was a good summary.=0A= >>=0A= >> But regarding "a mechanism for describing the role and intent of each=0A= >> RTP stream in the RTP session.", do we really need that? Isn't the=0A= >> combination of ssrc and the msid draft sufficient?=0A= >>=0A= >> Together the clearly identify how ssrc's map into PC-streams and=0A= >> PC-tracks, and the application can convey the remaining info (e.g.=0A= >> PC-stream xx represents the speaker audio+video, yy the room video etc.)= =0A= >> needed in any way it likes .=0A= >=0A= > My statements were not intended to be rtcweb-specific. The bundling=0A= > stuff is going to be a more general SDP extension. IMO the problems that= =0A= > rtcweb and clue have encountered that need this are just the tip of the= =0A= > iceberg.=0A= =0A= You're probably right in this (and I have to admit my comments are =0A= usually quite rtcweb centric).=0A= =0A= >=0A= > My point about the role/intent is that the application must have some=0A= > means to determine this. It doesn't always need to be in SDP. But the=0A= > old approach that is mostly based on the cases being so simple that it=0A= > is always obvious without signaling are now breaking down. And in the=0A= > case of SIP apps there are few mechanisms to build on other than SDP.=0A= =0A= I agree to the above.=0A= =0A= But taking my usual rtcweb shortcut, could we imagine that rtcweb solves = =0A= this with something like msid (i.e. you just provide the identity of =0A= each stream, and leave it up to the app to exchange what content it =0A= represents)?=0A= =0A= Once we have something that is usable in a SIP world (an agreed way to =0A= signal this in SDP), perhaps the web app could add that to the SDP. (Not = =0A= that clean, but could work).=0A= =0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= >> Stefan=0A= >>=0A= >> On 2013-05-21 22:13, Paul Kyzivat wrote:=0A= >>> On 5/21/13 3:20 AM, Christer Holmberg wrote:=0A= >>>> Hi,=0A= >>>>=0A= >>>>>> I don't think it's a BUNDLE issue whether adding/removing of streams= =0A= >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue.=0A= >>>>>>=0A= >>>>>> BUNDLE is about sharing a 5-tuple.=0A= >>>>>=0A= >>>>> I don't agree.=0A= >>>>>=0A= >>>>> RTP is already able to support multiple RTP streams sharing an RTP=0A= >>>>> session (and 5-tuple).=0A= >>>>>=0A= >>>>> What BUNDLE is about is describing that in SDP.=0A= >>>>> And that includes how SDP O/A works.=0A= >>>>=0A= >>>> Multiple RTP streams can already share an RTP session today, using=0A= >>>> multiple SSRCs per m- line :)=0A= >>>>=0A= >>>> If adding a new stream means adding a new m- line, then an SDP O/A is= =0A= >>>> obviously needed - bundle or no bundle.=0A= >>>>=0A= >>>> If adding a new stream means adding a new SSRC, within an existing m-,= =0A= >>>> then it is also an SDP O/A issue - bundle or no bundle.=0A= >>>=0A= >>> AFAIK there is wide agreement that an RTP *session* can carry multiple= =0A= >>> RTP streams.=0A= >>>=0A= >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP= =0A= >>> session. There is disagreement whether it is permissible for the=0A= >>> resulting RTP session to carry multiple RTP streams. The specs are=0A= >>> ambiguous on this point. Clearly there are well identified cases where= =0A= >>> they do, and we aren't likely to rule those incorrect. Its also clear= =0A= >>> that some of these cases start out sending a single SSRC, and then late= r=0A= >>> "add" another. (It may actually be a substitution.)=0A= >>>=0A= >>> So it seems clear to me that you may add an RTP stream to an RTP sessio= n=0A= >>> described by an m-line without doing another O/A exchange.=0A= >>>=0A= >>> What is lacking in such cases is a mechanism for describing the role an= d=0A= >>> intent of each RTP stream in the RTP session. In some cases it is=0A= >>> possible to get by without this, by assuming that the two ends have=0A= >>> consistent *assumptions* about how to infer the role/intent. But there= =0A= >>> are many cases where this isn't enough.=0A= >>>=0A= >>> Extra SDP syntax has been defined in an ad hoc way to get at bits and= =0A= >>> pieces of this problem. E.g., the a=3Dssrc attribute. What has already= =0A= >>> been defined doesn't seem suficient for all the new cases we are no=0A= >>> discussing.=0A= >>>=0A= >>> BUNDLE is *another* proposal for addressing part or all of this problem= .=0A= >>> But BUNDLE brings along another problem: for BUNDLE to be useful, it=0A= >>> must be possible to associate each RTP packet with one of the bundled= =0A= >>> m-lines. Without BUNDLE we don't have that problem.=0A= >>>=0A= >>> To summarize:=0A= >>>=0A= >>> - without bundle, we need a mechanism for describing the role/intent=0A= >>> of each RTP stream in the RTP session. *If* we choose to describe= =0A= >>> that with SDP, then we need an O/A exchange each time we add=0A= >>> an RTP stream.=0A= >>>=0A= >>> - with BUNDLE and Plan A, the assumption is that each m-line in the=0A= >>> bundle describes a single RTP stream, and so the other SDP stuff=0A= >>> in that media section can be used to describe the role/intent of=0A= >>> that RTP stream. By design this requires a new m-line for each=0A= >>> RTP stream, so adding one requires an O/A. We then assume that ther= e=0A= >>> is enough stuff in each media section to decide which m-line each= =0A= >>> packet should be associated with.=0A= >>>=0A= >>> - with BUNDLE and Plan B, there may be multiple RTP streams per=0A= >>> m-line. As in Plan A we need to associate each packet with one of= =0A= >>> the m-lines. Like the no-bundle case we still need some mechanism= =0A= >>> to describe the role/intent if the individual RTP streams.=0A= >>> In some cases (e.g., a=3Dssrc) the same info that classifies to=0A= >>> an m-line may also specify the role of each stream. That case=0A= >>> also leads to an O/A for each stream add.=0A= >>>=0A= >>> If you have a non-SDP way to discover the role/intent of each=0A= >>> RTP stream, and you use a way of classifying to one of the=0A= >>> bundled m-lines *without* enumerating every RTP stream, then=0A= >>> you can perhaps avoid an O/A for each stream add. E.g., if you=0A= >>> just bundle one audio and one video m-line, and use PT to=0A= >>> distinguish those.=0A= >>>=0A= >>> Note: in above I said Plan A uses an m-line for each RTP stream. That= =0A= >>> isn't always the case. There are some cases (at least in clue) where=0A= >>> each m-line is intended to describe a "flow" (clue capture) that may=0A= >>> correspond to different RTP streams over time, or that might include=0A= >>> supporting FEC streams, etc. Depending on your assumptions about this= =0A= >>> case it may start to take on some of the characteristics of Plan B.=0A= >>>=0A= >>> Thanks,=0A= >>> Paul=0A= >>>=0A= >>> _______________________________________________=0A= >>> rtcweb mailing list=0A= >>> rtcweb@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>=0A= >> _______________________________________________=0A= >> rtcweb mailing list=0A= >> rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From suhasietf@gmail.com Thu May 23 01:04:09 2013 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 914E811E819D for ; Thu, 23 May 2013 01:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7VgpgnF6R03 for ; Thu, 23 May 2013 01:04:04 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 20C0421F9721 for ; Thu, 23 May 2013 01:04:04 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id s14so1717277qeb.12 for ; Thu, 23 May 2013 01:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7zBgGGuKD22AfL4NGym4xxYRMxRJ65Wb1kkA2dGoqoo=; b=PnCDccKRZ1lt7EDDzFfqTujMbdQQRgxU+c/1GCSvFN2gHBJIAobky6BdL77vHWYl4P umhM47tujY75sp1rZVADEDT2LtfkCCkeJOzJ04lEZRTA/Q6YGWumzpyWe9LmSLH89NvR 80aENT/5ME9VKkrbTeN5OXXtQnLKVr6toYY6/IgPANmY8Fo27UJ5yVSy6FaNHLqQZ4Tv IU4/bSxN6DcobIsbo1jbo7WCAYGAUTPUNeVKSV+ExpTUTBPPGs4BH4yq7sOFay7O39AZ 9VofEBNioVr0vZ9NklhhBSt5aeflKGrw7c660fW8ryZ7UKP6SFFIfkmmkUvk1hfhEB9q OH5Q== MIME-Version: 1.0 X-Received: by 10.49.86.10 with SMTP id l10mr10522030qez.56.1369296239229; Thu, 23 May 2013 01:03:59 -0700 (PDT) Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 01:03:59 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> Date: Thu, 23 May 2013 01:03:59 -0700 Message-ID: From: Suhas Nandakumar To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=047d7bdc88acee9bd204dd5e1f37 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 08:04:09 -0000 --047d7bdc88acee9bd204dd5e1f37 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great Summarization Paul. My 2 cents SDP O/A enables parties in a session to decide on a compatible view of the session. This implies setting up appropriate transport , media stack (encoders, decoders) context and alike in a way that the parties involved can have a successful session. Regardless of Plan A or Plan B , any modifications to session parameters ( adding new source, removing a source, modifying existing parameters) that impacts resources managed, needs to be negotiated and O/A helps in this regard. Thanks Suhas On Wed, May 22, 2013 at 9:08 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 5/22/13 5:41 PM, Paul Kyzivat wrote: > > On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote: > >> I think this was a good summary. > >> > >> But regarding "a mechanism for describing the role and intent of each > >> RTP stream in the RTP session.", do we really need that? Isn't the > >> combination of ssrc and the msid draft sufficient? > >> > >> Together the clearly identify how ssrc's map into PC-streams and > >> PC-tracks, and the application can convey the remaining info (e.g. > >> PC-stream xx represents the speaker audio+video, yy the room video etc= .) > >> needed in any way it likes . > > > > My statements were not intended to be rtcweb-specific. The bundling > > stuff is going to be a more general SDP extension. IMO the problems tha= t > > rtcweb and clue have encountered that need this are just the tip of the > > iceberg. > > You're probably right in this (and I have to admit my comments are > usually quite rtcweb centric). > > > > > My point about the role/intent is that the application must have some > > means to determine this. It doesn't always need to be in SDP. But the > > old approach that is mostly based on the cases being so simple that it > > is always obvious without signaling are now breaking down. And in the > > case of SIP apps there are few mechanisms to build on other than SDP. > > I agree to the above. > > But taking my usual rtcweb shortcut, could we imagine that rtcweb solves > this with something like msid (i.e. you just provide the identity of > each stream, and leave it up to the app to exchange what content it > represents)? > > Once we have something that is usable in a SIP world (an agreed way to > signal this in SDP), perhaps the web app could add that to the SDP. (Not > that clean, but could work). > > > > > Thanks, > > Paul > > > >> Stefan > >> > >> On 2013-05-21 22:13, Paul Kyzivat wrote: > >>> On 5/21/13 3:20 AM, Christer Holmberg wrote: > >>>> Hi, > >>>> > >>>>>> I don't think it's a BUNDLE issue whether adding/removing of strea= ms > >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue. > >>>>>> > >>>>>> BUNDLE is about sharing a 5-tuple. > >>>>> > >>>>> I don't agree. > >>>>> > >>>>> RTP is already able to support multiple RTP streams sharing an RTP > >>>>> session (and 5-tuple). > >>>>> > >>>>> What BUNDLE is about is describing that in SDP. > >>>>> And that includes how SDP O/A works. > >>>> > >>>> Multiple RTP streams can already share an RTP session today, using > >>>> multiple SSRCs per m- line :) > >>>> > >>>> If adding a new stream means adding a new m- line, then an SDP O/A i= s > >>>> obviously needed - bundle or no bundle. > >>>> > >>>> If adding a new stream means adding a new SSRC, within an existing m= -, > >>>> then it is also an SDP O/A issue - bundle or no bundle. > >>> > >>> AFAIK there is wide agreement that an RTP *session* can carry multipl= e > >>> RTP streams. > >>> > >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP > >>> session. There is disagreement whether it is permissible for the > >>> resulting RTP session to carry multiple RTP streams. The specs are > >>> ambiguous on this point. Clearly there are well identified cases wher= e > >>> they do, and we aren't likely to rule those incorrect. Its also clear > >>> that some of these cases start out sending a single SSRC, and then > later > >>> "add" another. (It may actually be a substitution.) > >>> > >>> So it seems clear to me that you may add an RTP stream to an RTP > session > >>> described by an m-line without doing another O/A exchange. > >>> > >>> What is lacking in such cases is a mechanism for describing the role > and > >>> intent of each RTP stream in the RTP session. In some cases it is > >>> possible to get by without this, by assuming that the two ends have > >>> consistent *assumptions* about how to infer the role/intent. But ther= e > >>> are many cases where this isn't enough. > >>> > >>> Extra SDP syntax has been defined in an ad hoc way to get at bits and > >>> pieces of this problem. E.g., the a=3Dssrc attribute. What has alread= y > >>> been defined doesn't seem suficient for all the new cases we are no > >>> discussing. > >>> > >>> BUNDLE is *another* proposal for addressing part or all of this > problem. > >>> But BUNDLE brings along another problem: for BUNDLE to be useful, it > >>> must be possible to associate each RTP packet with one of the bundled > >>> m-lines. Without BUNDLE we don't have that problem. > >>> > >>> To summarize: > >>> > >>> - without bundle, we need a mechanism for describing the role/intent > >>> of each RTP stream in the RTP session. *If* we choose to describe > >>> that with SDP, then we need an O/A exchange each time we add > >>> an RTP stream. > >>> > >>> - with BUNDLE and Plan A, the assumption is that each m-line in the > >>> bundle describes a single RTP stream, and so the other SDP stuff > >>> in that media section can be used to describe the role/intent of > >>> that RTP stream. By design this requires a new m-line for each > >>> RTP stream, so adding one requires an O/A. We then assume that > there > >>> is enough stuff in each media section to decide which m-line each > >>> packet should be associated with. > >>> > >>> - with BUNDLE and Plan B, there may be multiple RTP streams per > >>> m-line. As in Plan A we need to associate each packet with one of > >>> the m-lines. Like the no-bundle case we still need some mechanism > >>> to describe the role/intent if the individual RTP streams. > >>> In some cases (e.g., a=3Dssrc) the same info that classifies to > >>> an m-line may also specify the role of each stream. That case > >>> also leads to an O/A for each stream add. > >>> > >>> If you have a non-SDP way to discover the role/intent of each > >>> RTP stream, and you use a way of classifying to one of the > >>> bundled m-lines *without* enumerating every RTP stream, then > >>> you can perhaps avoid an O/A for each stream add. E.g., if you > >>> just bundle one audio and one video m-line, and use PT to > >>> distinguish those. > >>> > >>> Note: in above I said Plan A uses an m-line for each RTP stream. That > >>> isn't always the case. There are some cases (at least in clue) where > >>> each m-line is intended to describe a "flow" (clue capture) that may > >>> correspond to different RTP streams over time, or that might include > >>> supporting FEC streams, etc. Depending on your assumptions about this > >>> case it may start to take on some of the characteristics of Plan B. > >>> > >>> Thanks, > >>> Paul > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > 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 > --047d7bdc88acee9bd204dd5e1f37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Great Summarization Paul.

My 2 ce= nts

SDP O/A enables parties in a sessi= on to decide on a compatible view of the session. This implies setting up a= ppropriate transport =A0, media stack (encoders, decoders)=A0context and al= ike=A0in a way that the parties involved can have a successful session.

Regardless of Plan A or Plan B , any modifi= cations to session parameters ( adding new source, removing a source, modif= ying existing parameters) that impacts resources managed, needs to be negot= iated and O/A helps in this regard.

Thanks
Suhas


On Wed, May 22, = 2013 at 9:08 AM, Stefan H=E5kansson LK <stefan.lk.hakansson= @ericsson.com> wrote:
On 5/22/13 5:41 PM, Paul K= yzivat wrote:
> On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote:
>> I think this was a good summary.
>>
>> But regarding "a mechanism for describing the role and intent= of each
>> RTP stream in the RTP session.", do we really need that? Isn&= #39;t the
>> combination of ssrc and the msid draft sufficient?
>>
>> Together the clearly identify how ssrc's map into PC-streams a= nd
>> PC-tracks, and the application can convey the remaining info (e.g.=
>> PC-stream xx represents the speaker audio+video, yy the room video= etc.)
>> needed in any way it likes .
>
> My statements were not intended to be rtcweb-specific. The bundling > stuff is going to be a more general SDP extension. IMO the problems th= at
> rtcweb and clue have encountered that need this are just the tip of th= e
> iceberg.

You're probably right in this (and I have to admit my comments ar= e
usually quite rtcweb centric).

>
> My point about the role/intent is that the application must have some<= br> > means to determine this. It doesn't always need to be in SDP. But = the
> old approach that is mostly based on the cases being so simple that it=
> is always obvious without signaling are now breaking down. And in the<= br> > case of SIP apps there are few mechanisms to build on other than SDP.<= br>
I agree to the above.

But taking my usual rtcweb shortcut, could we imagine that rtcweb solves this with something like msid (i.e. you just provide the identity of
each stream, and leave it up to the app to exchange what content it
represents)?

Once we have something that is usable in a SIP world (an agreed way to
signal this in SDP), perhaps the web app could add that to the SDP. (Not that clean, but could work).

>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Stefan
>>
>> On 2013-05-21 22:13, Paul Kyzivat wrote:
>>> On 5/21/13 3:20 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>>>> I don't think it's a BUNDLE issue whether = adding/removing of streams
>>>>>> require an O/A exchange or not. It's an SDP, a= nd SDP O/A, issue.
>>>>>>
>>>>>> BUNDLE is about sharing a 5-tuple.
>>>>>
>>>>> I don't agree.
>>>>>
>>>>> RTP is already able to support multiple RTP streams sh= aring an RTP
>>>>> session (and 5-tuple).
>>>>>
>>>>> What BUNDLE is about is describing that in SDP.
>>>>> And that includes how SDP O/A works.
>>>>
>>>> Multiple RTP streams can already share an RTP session toda= y, using
>>>> multiple SSRCs per m- line :)
>>>>
>>>> If adding a new stream means adding a new m- line, then an= SDP O/A is
>>>> obviously needed - bundle or no bundle.
>>>>
>>>> If adding a new stream means adding a new SSRC, within an = existing m-,
>>>> then it is also an SDP O/A issue - bundle or no bundle. >>>
>>> AFAIK there is wide agreement that an RTP *session* can carry = multiple
>>> RTP streams.
>>>
>>> An SDP O/A exchange negotiating an RTP m-line pair establishes= an RTP
>>> session. There is disagreement whether it is permissible for t= he
>>> resulting RTP session to carry multiple RTP streams. The specs= are
>>> ambiguous on this point. Clearly there are well identified cas= es where
>>> they do, and we aren't likely to rule those incorrect. Its= also clear
>>> that some of these cases start out sending a single SSRC, and = then later
>>> "add" another. (It may actually be a substitution.)<= br> >>>
>>> So it seems clear to me that you may add an RTP stream to an R= TP session
>>> described by an m-line without doing another O/A exchange.
>>>
>>> What is lacking in such cases is a mechanism for describing th= e role and
>>> intent of each RTP stream in the RTP session. In some cases it= is
>>> possible to get by without this, by assuming that the two ends= have
>>> consistent *assumptions* about how to infer the role/intent. B= ut there
>>> are many cases where this isn't enough.
>>>
>>> Extra SDP syntax has been defined in an ad hoc way to get at b= its and
>>> pieces of this problem. E.g., the a=3Dssrc attribute. What has= already
>>> been defined doesn't seem suficient for all the new cases = we are no
>>> discussing.
>>>
>>> BUNDLE is *another* proposal for addressing part or all of thi= s problem.
>>> But BUNDLE brings along another problem: for BUNDLE to be usef= ul, it
>>> must be possible to associate each RTP packet with one of the = bundled
>>> m-lines. Without BUNDLE we don't have that problem.
>>>
>>> To summarize:
>>>
>>> - without bundle, we need a mechanism for describing the role/= intent
>>> =A0 =A0 of each RTP stream in the RTP session. *If* we choose = to describe
>>> =A0 =A0 that with SDP, then we need an O/A exchange each time = we add
>>> =A0 =A0 an RTP stream.
>>>
>>> - with BUNDLE and Plan A, the assumption is that each m-line i= n the
>>> =A0 =A0 bundle describes a single RTP stream, and so the other= SDP stuff
>>> =A0 =A0 in that media section can be used to describe the role= /intent of
>>> =A0 =A0 that RTP stream. By design this requires a new m-line = for each
>>> =A0 =A0 RTP stream, so adding one requires an O/A. We then ass= ume that there
>>> =A0 =A0 is enough stuff in each media section to decide which = m-line each
>>> =A0 =A0 packet should be associated with.
>>>
>>> - with BUNDLE and Plan B, there may be multiple RTP streams pe= r
>>> =A0 =A0 m-line. As in Plan A we need to associate each packet = with one of
>>> =A0 =A0 the m-lines. Like the no-bundle case we still need som= e mechanism
>>> =A0 =A0 to describe the role/intent if the individual RTP stre= ams.
>>> =A0 =A0 In some cases (e.g., a=3Dssrc) the same info that clas= sifies to
>>> =A0 =A0 an m-line may also specify the role of each stream. Th= at case
>>> =A0 =A0 also leads to an O/A for each stream add.
>>>
>>> =A0 =A0 If you have a non-SDP way to discover the role/intent = of each
>>> =A0 =A0 RTP stream, and you use a way of classifying to one of= the
>>> =A0 =A0 bundled m-lines *without* enumerating every RTP stream= , then
>>> =A0 =A0 you can perhaps avoid an O/A for each stream add. E.g.= , if you
>>> =A0 =A0 just bundle one audio and one video m-line, and use PT= to
>>> =A0 =A0 distinguish those.
>>>
>>> Note: in above I said Plan A uses an m-line for each RTP strea= m. That
>>> isn't always the case. There are some cases (at least in c= lue) where
>>> each m-line is intended to describe a "flow" (clue c= apture) that may
>>> correspond to different RTP streams over time, or that might i= nclude
>>> supporting FEC streams, etc. Depending on your assumptions abo= ut this
>>> case it may start to take on some of the characteristics of Pl= an B.
>>>
>>> =A0 =A0 =A0 Thanks,
>>> =A0 =A0 =A0 Paul
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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

--047d7bdc88acee9bd204dd5e1f37-- From kevindempsey70@gmail.com Thu May 23 01:40:33 2013 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 76ADA11E81AA for ; Thu, 23 May 2013 01:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA8gx1QoF7WT for ; Thu, 23 May 2013 01:40:29 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5921F94A6 for ; Thu, 23 May 2013 01:40:28 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id x10so3038914lbi.7 for ; Thu, 23 May 2013 01:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9VGx6PQPIHr0B17AhmTvQB/siTESyFM6dWh8Kl9NijM=; b=YNfdgCWuhn2B0I2f8zMaYrqBkLWIeJiZu3vSjeynrLK6MO9cBzTI0KNBaPO8QfM+mi cwwjW3x6ppOnXM5shvvmJhrGiCk5u64K+7Veu29gC4mrU1E8XnV2JrdQiM1B4JkIK5QW u8UZ27/NnKvOk9hAOdcyDSuwNWLBAg2EQZ8rkzUvDcxpODQ+EkjoAFKlXRemZegBeH8a 9cIJXmXiVJHduJDG7xm2A/WhY4TZrZU7wlNy88KaH/Wyxugpgwc1JvGKOX9vkh12WOVH KeuZXxp1wSgX+ZnHkGR/PhjHnfXvbLoprK+NMM6V5ljVZ7iU0u5QgDbsrN3vfxbzE0hA 0Eug== MIME-Version: 1.0 X-Received: by 10.152.87.69 with SMTP id v5mr5921583laz.24.1369298427365; Thu, 23 May 2013 01:40:27 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Thu, 23 May 2013 01:40:27 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> Date: Thu, 23 May 2013 09:40:27 +0100 Message-ID: From: Kevin Dempsey To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=001a11c34f405ace8c04dd5ea280 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 08:40:33 -0000 --001a11c34f405ace8c04dd5ea280 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adding or removing a source generally doesn't need a SDP O/A. The offerer has indicated where media of a given type should be sent. The answerer can arrange for any source it wants to send to that destination. It is unusual for an answerer to send more that one SSRC at a time, but changing the source (and SSRC) is not uncommon. How the offerer handles the change of SSRC, or receiving multiple SSRCs is application specific. I believe most SIP endpoints I have used render only one SSRC per m=3D line at a time and have some mechanism to switch SSRC whe= n the one they were rendering stops. On 23 May 2013 09:03, Suhas Nandakumar wrote: > Great Summarization Paul. > > My 2 cents > > SDP O/A enables parties in a session to decide on a compatible view of th= e > session. This implies setting up appropriate transport , media stack > (encoders, decoders) context and alike in a way that the parties involved > can have a successful session. > > Regardless of Plan A or Plan B , any modifications to session parameters = ( > adding new source, removing a source, modifying existing parameters) that > impacts resources managed, needs to be negotiated and O/A helps in this > regard. > > Thanks > Suhas > > > On Wed, May 22, 2013 at 9:08 AM, Stefan H=E5kansson LK < > stefan.lk.hakansson@ericsson.com> wrote: > >> On 5/22/13 5:41 PM, Paul Kyzivat wrote: >> > On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote: >> >> I think this was a good summary. >> >> >> >> But regarding "a mechanism for describing the role and intent of each >> >> RTP stream in the RTP session.", do we really need that? Isn't the >> >> combination of ssrc and the msid draft sufficient? >> >> >> >> Together the clearly identify how ssrc's map into PC-streams and >> >> PC-tracks, and the application can convey the remaining info (e.g. >> >> PC-stream xx represents the speaker audio+video, yy the room video >> etc.) >> >> needed in any way it likes . >> > >> > My statements were not intended to be rtcweb-specific. The bundling >> > stuff is going to be a more general SDP extension. IMO the problems th= at >> > rtcweb and clue have encountered that need this are just the tip of th= e >> > iceberg. >> >> You're probably right in this (and I have to admit my comments are >> usually quite rtcweb centric). >> >> > >> > My point about the role/intent is that the application must have some >> > means to determine this. It doesn't always need to be in SDP. But the >> > old approach that is mostly based on the cases being so simple that it >> > is always obvious without signaling are now breaking down. And in the >> > case of SIP apps there are few mechanisms to build on other than SDP. >> >> I agree to the above. >> >> But taking my usual rtcweb shortcut, could we imagine that rtcweb solves >> this with something like msid (i.e. you just provide the identity of >> each stream, and leave it up to the app to exchange what content it >> represents)? >> >> Once we have something that is usable in a SIP world (an agreed way to >> signal this in SDP), perhaps the web app could add that to the SDP. (Not >> that clean, but could work). >> >> > >> > Thanks, >> > Paul >> > >> >> Stefan >> >> >> >> On 2013-05-21 22:13, Paul Kyzivat wrote: >> >>> On 5/21/13 3:20 AM, Christer Holmberg wrote: >> >>>> Hi, >> >>>> >> >>>>>> I don't think it's a BUNDLE issue whether adding/removing of >> streams >> >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue. >> >>>>>> >> >>>>>> BUNDLE is about sharing a 5-tuple. >> >>>>> >> >>>>> I don't agree. >> >>>>> >> >>>>> RTP is already able to support multiple RTP streams sharing an RTP >> >>>>> session (and 5-tuple). >> >>>>> >> >>>>> What BUNDLE is about is describing that in SDP. >> >>>>> And that includes how SDP O/A works. >> >>>> >> >>>> Multiple RTP streams can already share an RTP session today, using >> >>>> multiple SSRCs per m- line :) >> >>>> >> >>>> If adding a new stream means adding a new m- line, then an SDP O/A = is >> >>>> obviously needed - bundle or no bundle. >> >>>> >> >>>> If adding a new stream means adding a new SSRC, within an existing >> m-, >> >>>> then it is also an SDP O/A issue - bundle or no bundle. >> >>> >> >>> AFAIK there is wide agreement that an RTP *session* can carry multip= le >> >>> RTP streams. >> >>> >> >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an RT= P >> >>> session. There is disagreement whether it is permissible for the >> >>> resulting RTP session to carry multiple RTP streams. The specs are >> >>> ambiguous on this point. Clearly there are well identified cases whe= re >> >>> they do, and we aren't likely to rule those incorrect. Its also clea= r >> >>> that some of these cases start out sending a single SSRC, and then >> later >> >>> "add" another. (It may actually be a substitution.) >> >>> >> >>> So it seems clear to me that you may add an RTP stream to an RTP >> session >> >>> described by an m-line without doing another O/A exchange. >> >>> >> >>> What is lacking in such cases is a mechanism for describing the role >> and >> >>> intent of each RTP stream in the RTP session. In some cases it is >> >>> possible to get by without this, by assuming that the two ends have >> >>> consistent *assumptions* about how to infer the role/intent. But the= re >> >>> are many cases where this isn't enough. >> >>> >> >>> Extra SDP syntax has been defined in an ad hoc way to get at bits an= d >> >>> pieces of this problem. E.g., the a=3Dssrc attribute. What has alrea= dy >> >>> been defined doesn't seem suficient for all the new cases we are no >> >>> discussing. >> >>> >> >>> BUNDLE is *another* proposal for addressing part or all of this >> problem. >> >>> But BUNDLE brings along another problem: for BUNDLE to be useful, it >> >>> must be possible to associate each RTP packet with one of the bundle= d >> >>> m-lines. Without BUNDLE we don't have that problem. >> >>> >> >>> To summarize: >> >>> >> >>> - without bundle, we need a mechanism for describing the role/intent >> >>> of each RTP stream in the RTP session. *If* we choose to describ= e >> >>> that with SDP, then we need an O/A exchange each time we add >> >>> an RTP stream. >> >>> >> >>> - with BUNDLE and Plan A, the assumption is that each m-line in the >> >>> bundle describes a single RTP stream, and so the other SDP stuff >> >>> in that media section can be used to describe the role/intent of >> >>> that RTP stream. By design this requires a new m-line for each >> >>> RTP stream, so adding one requires an O/A. We then assume that >> there >> >>> is enough stuff in each media section to decide which m-line eac= h >> >>> packet should be associated with. >> >>> >> >>> - with BUNDLE and Plan B, there may be multiple RTP streams per >> >>> m-line. As in Plan A we need to associate each packet with one o= f >> >>> the m-lines. Like the no-bundle case we still need some mechanis= m >> >>> to describe the role/intent if the individual RTP streams. >> >>> In some cases (e.g., a=3Dssrc) the same info that classifies to >> >>> an m-line may also specify the role of each stream. That case >> >>> also leads to an O/A for each stream add. >> >>> >> >>> If you have a non-SDP way to discover the role/intent of each >> >>> RTP stream, and you use a way of classifying to one of the >> >>> bundled m-lines *without* enumerating every RTP stream, then >> >>> you can perhaps avoid an O/A for each stream add. E.g., if you >> >>> just bundle one audio and one video m-line, and use PT to >> >>> distinguish those. >> >>> >> >>> Note: in above I said Plan A uses an m-line for each RTP stream. Tha= t >> >>> isn't always the case. There are some cases (at least in clue) where >> >>> each m-line is intended to describe a "flow" (clue capture) that may >> >>> correspond to different RTP streams over time, or that might include >> >>> supporting FEC streams, etc. Depending on your assumptions about thi= s >> >>> case it may start to take on some of the characteristics of Plan B. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c34f405ace8c04dd5ea280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adding or removing a source generally doesn't need a S= DP O/A. The offerer has indicated where media of a given type should be sen= t. The answerer can arrange for any source it wants to send to that destina= tion. It is unusual for an answerer to send more that one SSRC at a time, b= ut changing =A0the source (and SSRC) is not uncommon.

How the offerer handles the change of SSRC, or receivi= ng multiple SSRCs is application specific. I believe most SIP endpoints I h= ave used render only one SSRC per m=3D line at a time and have some mechani= sm to switch SSRC when the one they were rendering stops.


On 23 M= ay 2013 09:03, Suhas Nandakumar <suhasietf@gmail.com> wrot= e:
Great Summarization Paul.
My 2 cents

SDP O/A enables parti= es in a session to decide on a compatible view of the session. This implies= setting up appropriate transport =A0, media stack (encoders, decoders)=A0c= ontext and alike=A0in a way that the parties involved can have a successful= session.

Regardless of Plan A or Plan B , any modifications to s= ession parameters ( adding new source, removing a source, modifying existin= g parameters) that impacts resources managed, needs to be negotiated and O/= A helps in this regard.

Thanks
Suhas


On Wed, = May 22, 2013 at 9:08 AM, Stefan H=E5kansson LK <stefan.lk.h= akansson@ericsson.com> wrote:
On 5/22/13 5:41 PM, Paul Kyzivat wrote:=
> On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote:
>> I think this was a good summary.
>>
>> But regarding "a mechanism for describing the role and intent= of each
>> RTP stream in the RTP session.", do we really need that? Isn&= #39;t the
>> combination of ssrc and the msid draft sufficient?
>>
>> Together the clearly identify how ssrc's map into PC-streams a= nd
>> PC-tracks, and the application can convey the remaining info (e.g.=
>> PC-stream xx represents the speaker audio+video, yy the room video= etc.)
>> needed in any way it likes .
>
> My statements were not intended to be rtcweb-specific. The bundling > stuff is going to be a more general SDP extension. IMO the problems th= at
> rtcweb and clue have encountered that need this are just the tip of th= e
> iceberg.

You're probably right in this (and I have to admit my comments ar= e
usually quite rtcweb centric).

>
> My point about the role/intent is that the application must have some<= br> > means to determine this. It doesn't always need to be in SDP. But = the
> old approach that is mostly based on the cases being so simple that it=
> is always obvious without signaling are now breaking down. And in the<= br> > case of SIP apps there are few mechanisms to build on other than SDP.<= br>
I agree to the above.

But taking my usual rtcweb shortcut, could we imagine that rtcweb solves this with something like msid (i.e. you just provide the identity of
each stream, and leave it up to the app to exchange what content it
represents)?

Once we have something that is usable in a SIP world (an agreed way to
signal this in SDP), perhaps the web app could add that to the SDP. (Not that clean, but could work).

>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Stefan
>>
>> On 2013-05-21 22:13, Paul Kyzivat wrote:
>>> On 5/21/13 3:20 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>>>> I don't think it's a BUNDLE issue whether = adding/removing of streams
>>>>>> require an O/A exchange or not. It's an SDP, a= nd SDP O/A, issue.
>>>>>>
>>>>>> BUNDLE is about sharing a 5-tuple.
>>>>>
>>>>> I don't agree.
>>>>>
>>>>> RTP is already able to support multiple RTP streams sh= aring an RTP
>>>>> session (and 5-tuple).
>>>>>
>>>>> What BUNDLE is about is describing that in SDP.
>>>>> And that includes how SDP O/A works.
>>>>
>>>> Multiple RTP streams can already share an RTP session toda= y, using
>>>> multiple SSRCs per m- line :)
>>>>
>>>> If adding a new stream means adding a new m- line, then an= SDP O/A is
>>>> obviously needed - bundle or no bundle.
>>>>
>>>> If adding a new stream means adding a new SSRC, within an = existing m-,
>>>> then it is also an SDP O/A issue - bundle or no bundle. >>>
>>> AFAIK there is wide agreement that an RTP *session* can carry = multiple
>>> RTP streams.
>>>
>>> An SDP O/A exchange negotiating an RTP m-line pair establishes= an RTP
>>> session. There is disagreement whether it is permissible for t= he
>>> resulting RTP session to carry multiple RTP streams. The specs= are
>>> ambiguous on this point. Clearly there are well identified cas= es where
>>> they do, and we aren't likely to rule those incorrect. Its= also clear
>>> that some of these cases start out sending a single SSRC, and = then later
>>> "add" another. (It may actually be a substitution.)<= br> >>>
>>> So it seems clear to me that you may add an RTP stream to an R= TP session
>>> described by an m-line without doing another O/A exchange.
>>>
>>> What is lacking in such cases is a mechanism for describing th= e role and
>>> intent of each RTP stream in the RTP session. In some cases it= is
>>> possible to get by without this, by assuming that the two ends= have
>>> consistent *assumptions* about how to infer the role/intent. B= ut there
>>> are many cases where this isn't enough.
>>>
>>> Extra SDP syntax has been defined in an ad hoc way to get at b= its and
>>> pieces of this problem. E.g., the a=3Dssrc attribute. What has= already
>>> been defined doesn't seem suficient for all the new cases = we are no
>>> discussing.
>>>
>>> BUNDLE is *another* proposal for addressing part or all of thi= s problem.
>>> But BUNDLE brings along another problem: for BUNDLE to be usef= ul, it
>>> must be possible to associate each RTP packet with one of the = bundled
>>> m-lines. Without BUNDLE we don't have that problem.
>>>
>>> To summarize:
>>>
>>> - without bundle, we need a mechanism for describing the role/= intent
>>> =A0 =A0 of each RTP stream in the RTP session. *If* we choose = to describe
>>> =A0 =A0 that with SDP, then we need an O/A exchange each time = we add
>>> =A0 =A0 an RTP stream.
>>>
>>> - with BUNDLE and Plan A, the assumption is that each m-line i= n the
>>> =A0 =A0 bundle describes a single RTP stream, and so the other= SDP stuff
>>> =A0 =A0 in that media section can be used to describe the role= /intent of
>>> =A0 =A0 that RTP stream. By design this requires a new m-line = for each
>>> =A0 =A0 RTP stream, so adding one requires an O/A. We then ass= ume that there
>>> =A0 =A0 is enough stuff in each media section to decide which = m-line each
>>> =A0 =A0 packet should be associated with.
>>>
>>> - with BUNDLE and Plan B, there may be multiple RTP streams pe= r
>>> =A0 =A0 m-line. As in Plan A we need to associate each packet = with one of
>>> =A0 =A0 the m-lines. Like the no-bundle case we still need som= e mechanism
>>> =A0 =A0 to describe the role/intent if the individual RTP stre= ams.
>>> =A0 =A0 In some cases (e.g., a=3Dssrc) the same info that clas= sifies to
>>> =A0 =A0 an m-line may also specify the role of each stream. Th= at case
>>> =A0 =A0 also leads to an O/A for each stream add.
>>>
>>> =A0 =A0 If you have a non-SDP way to discover the role/intent = of each
>>> =A0 =A0 RTP stream, and you use a way of classifying to one of= the
>>> =A0 =A0 bundled m-lines *without* enumerating every RTP stream= , then
>>> =A0 =A0 you can perhaps avoid an O/A for each stream add. E.g.= , if you
>>> =A0 =A0 just bundle one audio and one video m-line, and use PT= to
>>> =A0 =A0 distinguish those.
>>>
>>> Note: in above I said Plan A uses an m-line for each RTP strea= m. That
>>> isn't always the case. There are some cases (at least in c= lue) where
>>> each m-line is intended to describe a "flow" (clue c= apture) that may
>>> correspond to different RTP streams over time, or that might i= nclude
>>> supporting FEC streams, etc. Depending on your assumptions abo= ut this
>>> case it may start to take on some of the characteristics of Pl= an B.
>>>
>>> =A0 =A0 =A0 Thanks,
>>> =A0 =A0 =A0 Paul
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> 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


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


--001a11c34f405ace8c04dd5ea280-- From suhasietf@gmail.com Thu May 23 02:40:03 2013 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 0735921F8BC5 for ; Thu, 23 May 2013 02:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zawg9t11c23d for ; Thu, 23 May 2013 02:40:01 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4093121F8BBC for ; Thu, 23 May 2013 02:40:01 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bn16so3296170qab.14 for ; Thu, 23 May 2013 02:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K1h2dhSs8x4OiS7zbJ09uXx9FivaDH9mSpRnxnLo0+Y=; b=AJDmsGlGgq9yqy5sR/jY+MXjkpYxXOoEH6stKAL+TBsbc1PwzlfvsOn9ZkDTzIdysp ZXZEinXDiCMfntnKe1LYxZ8mO0bXn6O6Sfc/V31/5bPxc6vL4yOEse/lCPzMQZE0gc9v 8zGoHs6iqxkFZjsEMAWeC5OGBovqlKc6dMLBHphy358JwqEI1yM7pRLsxysW8SPXAXfp PQ2+fQ0JO2tYv7lTCo/IlXaTGQEYVUBhpQuUcuzN6nOZxUAGGmQ5YuEI6waCRMD1WH1H FtVDoiLefNtoeqgA73Jw0bYGDCW0ErOzdCkd4kRxaPiOnfiSgPm9qB02ZoxM5AZ/HC0Q 1hXQ== MIME-Version: 1.0 X-Received: by 10.49.85.131 with SMTP id h3mr12292349qez.42.1369302000462; Thu, 23 May 2013 02:40:00 -0700 (PDT) Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 02:40:00 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> Date: Thu, 23 May 2013 02:40:00 -0700 Message-ID: From: Suhas Nandakumar To: Kevin Dempsey Content-Type: multipart/alternative; boundary=047d7bd7566a54244a04dd5f7781 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 09:40:03 -0000 --047d7bd7566a54244a04dd5f7781 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Kevin, On Thu, May 23, 2013 at 1:40 AM, Kevin Dempsey wr= ote: > Adding or removing a source generally doesn't need a SDP O/A. The offerer > has indicated where media of a given type should be sent. The answerer ca= n > arrange for any source it wants to send to that destination. It is unusua= l > for an answerer to send more that one SSRC at a time, but changing the > source (and SSRC) is not uncommon > %Suhas% True in some cases and False in some. What if the new source produces pre-encoded stream that is not been negotiated within the current session ? example: video m=3Dline with VP8 is setup and H.264 encoded camera is added as new source. This needs a O/A negotiation for the appropriate decoder context to be setup on the receiver side OR similarly a high resolution video layer/feed or a different ptime based audio source is added or a sendonly source is added. How the offerer handles the change of SSRC, or receiving multiple SSRCs is > application specific. I believe most SIP endpoints I have used render onl= y > one SSRC per m=3D line at a time and have some mechanism to switch SSRC w= hen > the one they were rendering stops. > %Suhas% Agreed. A change in SSRC or totally new SSRC(s) seen at the end-point can be handled in a App Specific way. Thanks Suhas > On 23 May 2013 09:03, Suhas Nandakumar wrote: > >> Great Summarization Paul. >> >> My 2 cents >> >> SDP O/A enables parties in a session to decide on a compatible view of >> the session. This implies setting up appropriate transport , media stac= k >> (encoders, decoders) context and alike in a way that the parties involve= d >> can have a successful session. >> >> Regardless of Plan A or Plan B , any modifications to session parameters >> ( adding new source, removing a source, modifying existing parameters) t= hat >> impacts resources managed, needs to be negotiated and O/A helps in this >> regard. >> >> Thanks >> Suhas >> >> >> On Wed, May 22, 2013 at 9:08 AM, Stefan H=E5kansson LK < >> stefan.lk.hakansson@ericsson.com> wrote: >> >>> On 5/22/13 5:41 PM, Paul Kyzivat wrote: >>> > On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote: >>> >> I think this was a good summary. >>> >> >>> >> But regarding "a mechanism for describing the role and intent of eac= h >>> >> RTP stream in the RTP session.", do we really need that? Isn't the >>> >> combination of ssrc and the msid draft sufficient? >>> >> >>> >> Together the clearly identify how ssrc's map into PC-streams and >>> >> PC-tracks, and the application can convey the remaining info (e.g. >>> >> PC-stream xx represents the speaker audio+video, yy the room video >>> etc.) >>> >> needed in any way it likes . >>> > >>> > My statements were not intended to be rtcweb-specific. The bundling >>> > stuff is going to be a more general SDP extension. IMO the problems >>> that >>> > rtcweb and clue have encountered that need this are just the tip of t= he >>> > iceberg. >>> >>> You're probably right in this (and I have to admit my comments are >>> usually quite rtcweb centric). >>> >>> > >>> > My point about the role/intent is that the application must have some >>> > means to determine this. It doesn't always need to be in SDP. But the >>> > old approach that is mostly based on the cases being so simple that i= t >>> > is always obvious without signaling are now breaking down. And in the >>> > case of SIP apps there are few mechanisms to build on other than SDP. >>> >>> I agree to the above. >>> >>> But taking my usual rtcweb shortcut, could we imagine that rtcweb solve= s >>> this with something like msid (i.e. you just provide the identity of >>> each stream, and leave it up to the app to exchange what content it >>> represents)? >>> >>> Once we have something that is usable in a SIP world (an agreed way to >>> signal this in SDP), perhaps the web app could add that to the SDP. (No= t >>> that clean, but could work). >>> >>> > >>> > Thanks, >>> > Paul >>> > >>> >> Stefan >>> >> >>> >> On 2013-05-21 22:13, Paul Kyzivat wrote: >>> >>> On 5/21/13 3:20 AM, Christer Holmberg wrote: >>> >>>> Hi, >>> >>>> >>> >>>>>> I don't think it's a BUNDLE issue whether adding/removing of >>> streams >>> >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue. >>> >>>>>> >>> >>>>>> BUNDLE is about sharing a 5-tuple. >>> >>>>> >>> >>>>> I don't agree. >>> >>>>> >>> >>>>> RTP is already able to support multiple RTP streams sharing an RT= P >>> >>>>> session (and 5-tuple). >>> >>>>> >>> >>>>> What BUNDLE is about is describing that in SDP. >>> >>>>> And that includes how SDP O/A works. >>> >>>> >>> >>>> Multiple RTP streams can already share an RTP session today, using >>> >>>> multiple SSRCs per m- line :) >>> >>>> >>> >>>> If adding a new stream means adding a new m- line, then an SDP O/A >>> is >>> >>>> obviously needed - bundle or no bundle. >>> >>>> >>> >>>> If adding a new stream means adding a new SSRC, within an existing >>> m-, >>> >>>> then it is also an SDP O/A issue - bundle or no bundle. >>> >>> >>> >>> AFAIK there is wide agreement that an RTP *session* can carry >>> multiple >>> >>> RTP streams. >>> >>> >>> >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an R= TP >>> >>> session. There is disagreement whether it is permissible for the >>> >>> resulting RTP session to carry multiple RTP streams. The specs are >>> >>> ambiguous on this point. Clearly there are well identified cases >>> where >>> >>> they do, and we aren't likely to rule those incorrect. Its also cle= ar >>> >>> that some of these cases start out sending a single SSRC, and then >>> later >>> >>> "add" another. (It may actually be a substitution.) >>> >>> >>> >>> So it seems clear to me that you may add an RTP stream to an RTP >>> session >>> >>> described by an m-line without doing another O/A exchange. >>> >>> >>> >>> What is lacking in such cases is a mechanism for describing the rol= e >>> and >>> >>> intent of each RTP stream in the RTP session. In some cases it is >>> >>> possible to get by without this, by assuming that the two ends have >>> >>> consistent *assumptions* about how to infer the role/intent. But >>> there >>> >>> are many cases where this isn't enough. >>> >>> >>> >>> Extra SDP syntax has been defined in an ad hoc way to get at bits a= nd >>> >>> pieces of this problem. E.g., the a=3Dssrc attribute. What has alre= ady >>> >>> been defined doesn't seem suficient for all the new cases we are no >>> >>> discussing. >>> >>> >>> >>> BUNDLE is *another* proposal for addressing part or all of this >>> problem. >>> >>> But BUNDLE brings along another problem: for BUNDLE to be useful, i= t >>> >>> must be possible to associate each RTP packet with one of the bundl= ed >>> >>> m-lines. Without BUNDLE we don't have that problem. >>> >>> >>> >>> To summarize: >>> >>> >>> >>> - without bundle, we need a mechanism for describing the role/inten= t >>> >>> of each RTP stream in the RTP session. *If* we choose to descri= be >>> >>> that with SDP, then we need an O/A exchange each time we add >>> >>> an RTP stream. >>> >>> >>> >>> - with BUNDLE and Plan A, the assumption is that each m-line in the >>> >>> bundle describes a single RTP stream, and so the other SDP stuf= f >>> >>> in that media section can be used to describe the role/intent o= f >>> >>> that RTP stream. By design this requires a new m-line for each >>> >>> RTP stream, so adding one requires an O/A. We then assume that >>> there >>> >>> is enough stuff in each media section to decide which m-line ea= ch >>> >>> packet should be associated with. >>> >>> >>> >>> - with BUNDLE and Plan B, there may be multiple RTP streams per >>> >>> m-line. As in Plan A we need to associate each packet with one = of >>> >>> the m-lines. Like the no-bundle case we still need some mechani= sm >>> >>> to describe the role/intent if the individual RTP streams. >>> >>> In some cases (e.g., a=3Dssrc) the same info that classifies to >>> >>> an m-line may also specify the role of each stream. That case >>> >>> also leads to an O/A for each stream add. >>> >>> >>> >>> If you have a non-SDP way to discover the role/intent of each >>> >>> RTP stream, and you use a way of classifying to one of the >>> >>> bundled m-lines *without* enumerating every RTP stream, then >>> >>> you can perhaps avoid an O/A for each stream add. E.g., if you >>> >>> just bundle one audio and one video m-line, and use PT to >>> >>> distinguish those. >>> >>> >>> >>> Note: in above I said Plan A uses an m-line for each RTP stream. Th= at >>> >>> isn't always the case. There are some cases (at least in clue) wher= e >>> >>> each m-line is intended to describe a "flow" (clue capture) that ma= y >>> >>> correspond to different RTP streams over time, or that might includ= e >>> >>> supporting FEC streams, etc. Depending on your assumptions about th= is >>> >>> case it may start to take on some of the characteristics of Plan B. >>> >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >> >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --047d7bd7566a54244a04dd5f7781 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Kevin,=A0

On Thu, May 23, 2013 at 1:4= 0 AM, Kevin Dempsey <kevindempsey70@gmail.com> wrote:=
Adding or removing a source generally doesn't need a S= DP O/A. The offerer has indicated where media of a given type should be sen= t. The answerer can arrange for any source it wants to send to that destina= tion. It is unusual for an answerer to send more that one SSRC at a time, b= ut changing =A0the source (and SSRC) is not uncommon

%Suhas% True in some cases and False in so= me.

What if the new source produces pre-encoded st= ream that is not been negotiated within the current session ?=A0
example: video m=3Dline with VP8 is setup and H.264 encoded camera is added= as new source. This needs a O/A negotiation for the appropriate decoder co= ntext to be setup on the receiver side
OR similarly
a h= igh resolution video layer/feed or =A0a different ptime based audio source = is added or a sendonly source is added.



How the offerer handles the change of SSRC, or recei= ving multiple SSRCs is application specific. I believe most SIP endpoints I= have used render only one SSRC per m=3D line at a time and have some mecha= nism to switch SSRC when the one they were rendering stops.

%Suhas% Agreed. A change in SSRC or = totally new SSRC(s) seen at the end-point can be handled in a App Specific = way.

Thanks
Suhas
On 23 May 2013 09:03, Suhas Nandakumar <suhasietf@gma= il.com> wrote:
Great Summarization Paul.
My 2 cents

SDP O/A enables parti= es in a session to decide on a compatible view of the session. This implies= setting up appropriate transport =A0, media stack (encoders, decoders)=A0c= ontext and alike=A0in a way that the parties involved can have a successful= session.

Regardless of Plan A or Plan B , any modifications to s= ession parameters ( adding new source, removing a source, modifying existin= g parameters) that impacts resources managed, needs to be negotiated and O/= A helps in this regard.

Thanks
Suhas


On Wed, May 22, 2013 at 9:08 AM, Stefan H=E5kansson LK = <stefan.lk.hakansson@ericsson.com> wrote:
On 5/22/13 5:41 PM, Paul Kyzivat wrote:=
> On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote:
>> I think this was a good summary.
>>
>> But regarding "a mechanism for describing the role and intent= of each
>> RTP stream in the RTP session.", do we really need that? Isn&= #39;t the
>> combination of ssrc and the msid draft sufficient?
>>
>> Together the clearly identify how ssrc's map into PC-streams a= nd
>> PC-tracks, and the application can convey the remaining info (e.g.=
>> PC-stream xx represents the speaker audio+video, yy the room video= etc.)
>> needed in any way it likes .
>
> My statements were not intended to be rtcweb-specific. The bundling > stuff is going to be a more general SDP extension. IMO the problems th= at
> rtcweb and clue have encountered that need this are just the tip of th= e
> iceberg.

You're probably right in this (and I have to admit my comments ar= e
usually quite rtcweb centric).

>
> My point about the role/intent is that the application must have some<= br> > means to determine this. It doesn't always need to be in SDP. But = the
> old approach that is mostly based on the cases being so simple that it=
> is always obvious without signaling are now breaking down. And in the<= br> > case of SIP apps there are few mechanisms to build on other than SDP.<= br>
I agree to the above.

But taking my usual rtcweb shortcut, could we imagine that rtcweb solves this with something like msid (i.e. you just provide the identity of
each stream, and leave it up to the app to exchange what content it
represents)?

Once we have something that is usable in a SIP world (an agreed way to
signal this in SDP), perhaps the web app could add that to the SDP. (Not that clean, but could work).

>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Stefan
>>
>> On 2013-05-21 22:13, Paul Kyzivat wrote:
>>> On 5/21/13 3:20 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>>>> I don't think it's a BUNDLE issue whether = adding/removing of streams
>>>>>> require an O/A exchange or not. It's an SDP, a= nd SDP O/A, issue.
>>>>>>
>>>>>> BUNDLE is about sharing a 5-tuple.
>>>>>
>>>>> I don't agree.
>>>>>
>>>>> RTP is already able to support multiple RTP streams sh= aring an RTP
>>>>> session (and 5-tuple).
>>>>>
>>>>> What BUNDLE is about is describing that in SDP.
>>>>> And that includes how SDP O/A works.
>>>>
>>>> Multiple RTP streams can already share an RTP session toda= y, using
>>>> multiple SSRCs per m- line :)
>>>>
>>>> If adding a new stream means adding a new m- line, then an= SDP O/A is
>>>> obviously needed - bundle or no bundle.
>>>>
>>>> If adding a new stream means adding a new SSRC, within an = existing m-,
>>>> then it is also an SDP O/A issue - bundle or no bundle. >>>
>>> AFAIK there is wide agreement that an RTP *session* can carry = multiple
>>> RTP streams.
>>>
>>> An SDP O/A exchange negotiating an RTP m-line pair establishes= an RTP
>>> session. There is disagreement whether it is permissible for t= he
>>> resulting RTP session to carry multiple RTP streams. The specs= are
>>> ambiguous on this point. Clearly there are well identified cas= es where
>>> they do, and we aren't likely to rule those incorrect. Its= also clear
>>> that some of these cases start out sending a single SSRC, and = then later
>>> "add" another. (It may actually be a substitution.)<= br> >>>
>>> So it seems clear to me that you may add an RTP stream to an R= TP session
>>> described by an m-line without doing another O/A exchange.
>>>
>>> What is lacking in such cases is a mechanism for describing th= e role and
>>> intent of each RTP stream in the RTP session. In some cases it= is
>>> possible to get by without this, by assuming that the two ends= have
>>> consistent *assumptions* about how to infer the role/intent. B= ut there
>>> are many cases where this isn't enough.
>>>
>>> Extra SDP syntax has been defined in an ad hoc way to get at b= its and
>>> pieces of this problem. E.g., the a=3Dssrc attribute. What has= already
>>> been defined doesn't seem suficient for all the new cases = we are no
>>> discussing.
>>>
>>> BUNDLE is *another* proposal for addressing part or all of thi= s problem.
>>> But BUNDLE brings along another problem: for BUNDLE to be usef= ul, it
>>> must be possible to associate each RTP packet with one of the = bundled
>>> m-lines. Without BUNDLE we don't have that problem.
>>>
>>> To summarize:
>>>
>>> - without bundle, we need a mechanism for describing the role/= intent
>>> =A0 =A0 of each RTP stream in the RTP session. *If* we choose = to describe
>>> =A0 =A0 that with SDP, then we need an O/A exchange each time = we add
>>> =A0 =A0 an RTP stream.
>>>
>>> - with BUNDLE and Plan A, the assumption is that each m-line i= n the
>>> =A0 =A0 bundle describes a single RTP stream, and so the other= SDP stuff
>>> =A0 =A0 in that media section can be used to describe the role= /intent of
>>> =A0 =A0 that RTP stream. By design this requires a new m-line = for each
>>> =A0 =A0 RTP stream, so adding one requires an O/A. We then ass= ume that there
>>> =A0 =A0 is enough stuff in each media section to decide which = m-line each
>>> =A0 =A0 packet should be associated with.
>>>
>>> - with BUNDLE and Plan B, there may be multiple RTP streams pe= r
>>> =A0 =A0 m-line. As in Plan A we need to associate each packet = with one of
>>> =A0 =A0 the m-lines. Like the no-bundle case we still need som= e mechanism
>>> =A0 =A0 to describe the role/intent if the individual RTP stre= ams.
>>> =A0 =A0 In some cases (e.g., a=3Dssrc) the same info that clas= sifies to
>>> =A0 =A0 an m-line may also specify the role of each stream. Th= at case
>>> =A0 =A0 also leads to an O/A for each stream add.
>>>
>>> =A0 =A0 If you have a non-SDP way to discover the role/intent = of each
>>> =A0 =A0 RTP stream, and you use a way of classifying to one of= the
>>> =A0 =A0 bundled m-lines *without* enumerating every RTP stream= , then
>>> =A0 =A0 you can perhaps avoid an O/A for each stream add. E.g.= , if you
>>> =A0 =A0 just bundle one audio and one video m-line, and use PT= to
>>> =A0 =A0 distinguish those.
>>>
>>> Note: in above I said Plan A uses an m-line for each RTP strea= m. That
>>> isn't always the case. There are some cases (at least in c= lue) where
>>> each m-line is intended to describe a "flow" (clue c= apture) that may
>>> correspond to different RTP streams over time, or that might i= nclude
>>> supporting FEC streams, etc. Depending on your assumptions abo= ut this
>>> case it may start to take on some of the characteristics of Pl= an B.
>>>
>>> =A0 =A0 =A0 Thanks,
>>> =A0 =A0 =A0 Paul
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> 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


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



--047d7bd7566a54244a04dd5f7781-- From emil@sip-communicator.org Thu May 23 02:44:34 2013 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 CE18521F9633 for ; Thu, 23 May 2013 02:44:34 -0700 (PDT) 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=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvXmLmSW4lWf for ; Thu, 23 May 2013 02:44:34 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5121F964A for ; Thu, 23 May 2013 02:44:29 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg1so1682942bkc.34 for ; Thu, 23 May 2013 02:44:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=EHMNoUQ6ZimfVlWwX4FTqh+e1wHK11XPIal71OU0mR0=; b=FUn6xHrM1qapT+CxSZ6jzjYjBDijC1ew5dfufdmYUFGj/zHiVvMRwaOkg6q4BsSLQl jRfmncqbtrzzv+kzRqU/vnbyIIkh8HFOXBPG6Fnsfw7HxVep+EfO0MgcaX4wl9Dv01A5 LUhnL7he/k+IxA+YpRchUt1BDqWYPsBkqg3a7IejxEtg4AHl3v+fSI4ZZ6Iuwy1YUYed p6C2+rHhdXq5I//ZPf3qJT0xjhmIyNstTs+pdI3R+NnSVp3PCMgRiJ8acxqlEYMpZxGk anOdms+tnp+cXmZ4dH2pFjJUrF40iedktgGCiJZIh91IpAz4Ckw1QDFv1t6TrHjpQZoL RCvQ== X-Received: by 10.205.76.129 with SMTP id ze1mr6160289bkb.12.1369302265452; Thu, 23 May 2013 02:44:25 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.4]) by mx.google.com with ESMTPSA id fh8sm2993298bkc.10.2013.05.23.02.44.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 02:44:24 -0700 (PDT) Message-ID: <519DE4DE.8070508@jitsi.org> Date: Thu, 23 May 2013 12:43:58 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Suhas Nandakumar References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmDxky7BPi3ZyEQ0/dfghishnNk+umzqmcp8cGUl/M7OyIFy4b+B4kYJhAIsOGIGz6dmLXc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 09:44:34 -0000 On 23.05.13, 12:40, Suhas Nandakumar wrote: > What if the new source produces pre-encoded stream that is not been > negotiated within the current session ? > example: video m=line with VP8 is setup and H.264 encoded camera is > added as new source. This needs a O/A negotiation for the appropriate > decoder context to be setup on the receiver side Obviously this does require a new O/A but I don't see how that case is related to adding and removing SSRCs which do not require O/A exchanges. Emil -- https://jitsi.org From christer.holmberg@ericsson.com Thu May 23 02:49:17 2013 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 0746421F958B for ; Thu, 23 May 2013 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWn8IEHIZMfX for ; Thu, 23 May 2013 02:49:11 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 81A7521F960E for ; Thu, 23 May 2013 02:49:09 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-8c-519de613e957 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D1.93.06701.316ED915; Thu, 23 May 2013 11:49:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Thu, 23 May 2013 11:49:07 +0200 From: Christer Holmberg To: Kevin Dempsey , Suhas Nandakumar Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkSUCmAgAAKMICAADOSwA== Date: Thu, 23 May 2013 09:49:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376A41@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@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.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvra7ws7mBBieOmFvcnP+WxWLtv3Z2 i51zO5gdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsEroyF11UL9rpVXNo3kbmBcaFFFyMn h4SAicSOzo2sELaYxIV769m6GLk4hAQOM0psPrOTBcJZwijxqfUqUIaDg03AQqL7nzZIg4hA mMSzq6vZQGxmAXWJO4vPsYPYwgKGEr8vnGKGqDGSuLZ+PwuE7SRxZMYMMJtFQFXiSc9+VpCR vAK+Emv21EOseswi8fXAVUaQGk6BQIm/x5vBjmMEOu77qTVMELvEJW49mc8EcbSAxJI955kh bFGJl4//gc2UEFCUWN4vB1GuJ3Fj6hSoM7Ulli18DVbOKyAocXLmE5YJjGKzkEydhaRlFpKW WUhaFjCyrGJkz03MzEkvN9/ECIyUg1t+G+xg3HRf7BCjNAeLkjhvn/bUQCGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2Mwh+CNjntzb67fpHf0jVKyZ9//J1x4MrR2zpfdZdNnXDDKChhhcL3 161862xCd724paQ6v2UbP9OPyFXz5zX23ersN17QrL560vn6rO4bnIXa06u/84nX9B7/zfe1 wFHvstIsk6bcrNC61rSAqpTFrectvJd777hUZ3qz2pv7Z8DvLw8F7RseK7EUZyQaajEXFScC AORDOktiAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 09:49:17 -0000 Hi, >Adding or removing a source generally doesn't need a SDP O/A. The offerer = has indicated where media of a given type should be sent.=20 >The answerer can arrange for any source it wants to send to that destinati= on. It is unusual for an answerer to send more that one SSRC at a time, You can have multiple simultaneously sent media streams, each with its own = SSRC. > How the offerer handles the change of SSRC, or receiving multiple SSRCs i= s application specific. I believe most SIP endpoints I have used render onl= y one SSRC > per m=3D line at a time and have some mechanism to switch SSRC when the o= ne they were rendering stops. SIP endpoints today can map the media to the associated m- line because a u= nique port is used. With BUNDLE, even if you only use one SSRC per m- line, you still need to b= e able to associate it with an m- line. Regards, Christer On 23 May 2013 09:03, Suhas Nandakumar wrote: Great Summarization Paul. My 2 cents SDP O/A enables parties in a session to decide on a compatible view of the = session. This implies setting up appropriate transport =A0, media stack (en= coders, decoders)=A0context and alike=A0in a way that the parties involved = can have a successful session. Regardless of Plan A or Plan B , any modifications to session parameters ( = adding new source, removing a source, modifying existing parameters) that i= mpacts resources managed, needs to be negotiated and O/A helps in this rega= rd. Thanks Suhas On Wed, May 22, 2013 at 9:08 AM, Stefan H=E5kansson LK wrote: On 5/22/13 5:41 PM, Paul Kyzivat wrote: > On 5/22/13 4:50 AM, Stefan H=E5kansson LK wrote: >> I think this was a good summary. >> >> But regarding "a mechanism for describing the role and intent of each >> RTP stream in the RTP session.", do we really need that? Isn't the >> combination of ssrc and the msid draft sufficient? >> >> Together the clearly identify how ssrc's map into PC-streams and >> PC-tracks, and the application can convey the remaining info (e.g. >> PC-stream xx represents the speaker audio+video, yy the room video etc.) >> needed in any way it likes . > > My statements were not intended to be rtcweb-specific. The bundling > stuff is going to be a more general SDP extension. IMO the problems that > rtcweb and clue have encountered that need this are just the tip of the > iceberg. You're probably right in this (and I have to admit my comments are usually quite rtcweb centric). > > My point about the role/intent is that the application must have some > means to determine this. It doesn't always need to be in SDP. But the > old approach that is mostly based on the cases being so simple that it > is always obvious without signaling are now breaking down. And in the > case of SIP apps there are few mechanisms to build on other than SDP. I agree to the above. But taking my usual rtcweb shortcut, could we imagine that rtcweb solves this with something like msid (i.e. you just provide the identity of each stream, and leave it up to the app to exchange what content it represents)? Once we have something that is usable in a SIP world (an agreed way to signal this in SDP), perhaps the web app could add that to the SDP. (Not that clean, but could work). > > =A0 =A0 =A0 Thanks, > =A0 =A0 =A0 Paul > >> Stefan >> >> On 2013-05-21 22:13, Paul Kyzivat wrote: >>> On 5/21/13 3:20 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>>>> I don't think it's a BUNDLE issue whether adding/removing of streams >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue. >>>>>> >>>>>> BUNDLE is about sharing a 5-tuple. >>>>> >>>>> I don't agree. >>>>> >>>>> RTP is already able to support multiple RTP streams sharing an RTP >>>>> session (and 5-tuple). >>>>> >>>>> What BUNDLE is about is describing that in SDP. >>>>> And that includes how SDP O/A works. >>>> >>>> Multiple RTP streams can already share an RTP session today, using >>>> multiple SSRCs per m- line :) >>>> >>>> If adding a new stream means adding a new m- line, then an SDP O/A is >>>> obviously needed - bundle or no bundle. >>>> >>>> If adding a new stream means adding a new SSRC, within an existing m-, >>>> then it is also an SDP O/A issue - bundle or no bundle. >>> >>> AFAIK there is wide agreement that an RTP *session* can carry multiple >>> RTP streams. >>> >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP >>> session. There is disagreement whether it is permissible for the >>> resulting RTP session to carry multiple RTP streams. The specs are >>> ambiguous on this point. Clearly there are well identified cases where >>> they do, and we aren't likely to rule those incorrect. Its also clear >>> that some of these cases start out sending a single SSRC, and then late= r >>> "add" another. (It may actually be a substitution.) >>> >>> So it seems clear to me that you may add an RTP stream to an RTP sessio= n >>> described by an m-line without doing another O/A exchange. >>> >>> What is lacking in such cases is a mechanism for describing the role an= d >>> intent of each RTP stream in the RTP session. In some cases it is >>> possible to get by without this, by assuming that the two ends have >>> consistent *assumptions* about how to infer the role/intent. But there >>> are many cases where this isn't enough. >>> >>> Extra SDP syntax has been defined in an ad hoc way to get at bits and >>> pieces of this problem. E.g., the a=3Dssrc attribute. What has already >>> been defined doesn't seem suficient for all the new cases we are no >>> discussing. >>> >>> BUNDLE is *another* proposal for addressing part or all of this problem= . >>> But BUNDLE brings along another problem: for BUNDLE to be useful, it >>> must be possible to associate each RTP packet with one of the bundled >>> m-lines. Without BUNDLE we don't have that problem. >>> >>> To summarize: >>> >>> - without bundle, we need a mechanism for describing the role/intent >>> =A0 =A0 of each RTP stream in the RTP session. *If* we choose to descri= be >>> =A0 =A0 that with SDP, then we need an O/A exchange each time we add >>> =A0 =A0 an RTP stream. >>> >>> - with BUNDLE and Plan A, the assumption is that each m-line in the >>> =A0 =A0 bundle describes a single RTP stream, and so the other SDP stuf= f >>> =A0 =A0 in that media section can be used to describe the role/intent o= f >>> =A0 =A0 that RTP stream. By design this requires a new m-line for each >>> =A0 =A0 RTP stream, so adding one requires an O/A. We then assume that = there >>> =A0 =A0 is enough stuff in each media section to decide which m-line ea= ch >>> =A0 =A0 packet should be associated with. >>> >>> - with BUNDLE and Plan B, there may be multiple RTP streams per >>> =A0 =A0 m-line. As in Plan A we need to associate each packet with one = of >>> =A0 =A0 the m-lines. Like the no-bundle case we still need some mechani= sm >>> =A0 =A0 to describe the role/intent if the individual RTP streams. >>> =A0 =A0 In some cases (e.g., a=3Dssrc) the same info that classifies to >>> =A0 =A0 an m-line may also specify the role of each stream. That case >>> =A0 =A0 also leads to an O/A for each stream add. >>> >>> =A0 =A0 If you have a non-SDP way to discover the role/intent of each >>> =A0 =A0 RTP stream, and you use a way of classifying to one of the >>> =A0 =A0 bundled m-lines *without* enumerating every RTP stream, then >>> =A0 =A0 you can perhaps avoid an O/A for each stream add. E.g., if you >>> =A0 =A0 just bundle one audio and one video m-line, and use PT to >>> =A0 =A0 distinguish those. >>> >>> Note: in above I said Plan A uses an m-line for each RTP stream. That >>> isn't always the case. There are some cases (at least in clue) where >>> each m-line is intended to describe a "flow" (clue capture) that may >>> correspond to different RTP streams over time, or that might include >>> supporting FEC streams, etc. Depending on your assumptions about this >>> case it may start to take on some of the characteristics of Plan B. >>> >>> =A0 =A0 =A0 Thanks, >>> =A0 =A0 =A0 Paul >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Thu May 23 02:51:21 2013 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 7C91121F96B4 for ; Thu, 23 May 2013 02:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Eqa1mI2LaD for ; Thu, 23 May 2013 02:51:15 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2221F96D2 for ; Thu, 23 May 2013 02:51:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-14-519de69176fa Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 34.72.28930.196ED915; Thu, 23 May 2013 11:51:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 23 May 2013 11:51:13 +0200 From: Christer Holmberg To: Emil Ivov , Suhas Nandakumar Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkSUCmAgAAKMICAABCkAIAAARsAgAAjHBA= Date: Thu, 23 May 2013 09:51:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> In-Reply-To: <519DE4DE.8070508@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre7EZ3MDDe5usLRYs3MCi8Xaf+3s FjvndjA7MHvsnHWX3WPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlzNlwma3gEUvFueaZrA2M D5i7GDk5JARMJH6v3sAOYYtJXLi3nq2LkYtDSOAwo8T8FW9ZIJwljBItmyYBORwcbAIWEt3/ tEEaRATcJX5su8kIYjMLqEvcWXwObJCwgKHE7wunmCFqjCSurd/PAmH7STzb/4sJxGYRUJX4 9a8NzOYV8JV4cucFM8Suk6wS26+2gjVzCmhKzF5/FmwBI9B130+tYYJYJi5x68l8JoirBSSW 7DkP9Y2oxMvH/1hB7pQQUJRY3i8HUa4jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRbBaSqbOQ tMxC0jILScsCRpZVjOy5iZk56eWGmxiBUXNwy2/dHYynzokcYpTmYFES5+3VnhooJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgVFC4mbdqr61P4UN/mU5Vu9wunQk682nmfwCOVOO+X3JuMW7 xUe77ryx9YKM9EtVQRzes08fztqsG/Jdr624NuU+371r0zJ3fXWR3bHApjknOI7tcJ5sjtyX SSZlkrE7tA/Z8zydWSz3ZNOJ/6fmaXutVZHtWH/mTMf5zlf+C9x/3W1uzZlhuE+JpTgj0VCL uag4EQA6YMxTaAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 09:51:21 -0000 Hi, >> What if the new source produces pre-encoded stream that is not been=20 >> negotiated within the current session ? >> example: video m=3Dline with VP8 is setup and H.264 encoded camera is=20 >> added as new source. This needs a O/A negotiation for the appropriate=20 >> decoder context to be setup on the receiver side > > Obviously this does require a new O/A but I don't see how that case is re= lated to adding and removing SSRCs which do not require O/A exchanges. It depends on whether you need to signal the SSRC to the remote endpoint fo= r demux purpose. Regards, Christer From emil@sip-communicator.org Thu May 23 03:44:31 2013 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 71F0921F9691 for ; Thu, 23 May 2013 03:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFPndAJX-0xy for ; Thu, 23 May 2013 03:44:30 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 45A2D21F8E93 for ; Thu, 23 May 2013 03:44:30 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so1087529bkc.4 for ; Thu, 23 May 2013 03:44:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=temoxN3dxEeBAYiZrFKH5Dr7K6p9yCf7Ef6zD/BVus0=; b=N9ItUmLkXtgSFZm6pil1fZy7edFaa7zN9kvBlJ9FQDPMsylYVa9a9jxXnBJAAj6L14 mOGD7LswqamMdt41Cl6LQH4/R8c5aLq2pNlJ0X5XbLADoUyDXBbUjYyp8SoNYT8PJg0J lapPJ+cib1f2jG5K08Gugnuvz/4fCf+d/RWBwIjNYmt74yyfapTKYijIe6Zv7U44PoDb e0eGph2PG49Q6lYtyvypB/7p44EhNuewz5Y0RrOUtfOnLe4PgW4DtkppmJsmGWm48R4B TwJbt5+CSgNJCGJNQQ1TkUpZanlxlIKvLOvtg022XBE7WtcAFczStl1UY02WSU/51Uae W8DA== X-Received: by 10.205.44.193 with SMTP id uh1mr5069640bkb.14.1369305869037; Thu, 23 May 2013 03:44:29 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.4]) by mx.google.com with ESMTPSA id rj5sm2269061bkb.1.2013.05.23.03.44.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 03:44:28 -0700 (PDT) Message-ID: <519DF308.6050203@jitsi.org> Date: Thu, 23 May 2013 13:44:24 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn+1uy21gxMP/rfS+1WRoJPZk/+J79D0MRuQFu0FDjiuOlxh/EKfPluaUB/cZLdFwYscw5j Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 10:44:31 -0000 On 23.05.13, 12:51, Christer Holmberg wrote: > Hi, > >>> What if the new source produces pre-encoded stream that is not been >>> negotiated within the current session ? >>> example: video m=line with VP8 is setup and H.264 encoded camera is >>> added as new source. This needs a O/A negotiation for the appropriate >>> decoder context to be setup on the receiver side >> >> Obviously this does require a new O/A but I don't see how that case is related to adding and removing SSRCs which do not require O/A exchanges. > > It depends on whether you need to signal the SSRC to the remote endpoint for demux purpose. Exactly, and since I've been arguing that you don't ... :) Emil -- https://jitsi.org From christer.holmberg@ericsson.com Thu May 23 04:04:16 2013 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 D6B6321F96C1 for ; Thu, 23 May 2013 04:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfdljIbWBAXV for ; Thu, 23 May 2013 04:04:09 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED321F9633 for ; Thu, 23 May 2013 04:04:08 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-de-519df7a7c1b9 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 71.51.06701.7A7FD915; Thu, 23 May 2013 13:04:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 23 May 2013 13:04:07 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkSUCmAgAAKMICAABCkAIAAARsAgAAjHBD//+3HAIAAJp6A Date: Thu, 23 May 2013 11:04:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376B8B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> <519DF308.6050203@jitsi.org> In-Reply-To: <519DF308.6050203@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre6K73MDDZ63sFis2TmBxWLtv3Z2 i51zO5gdmD12zrrL7rFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgy/uzuZC3Yx1Zx6vdZtgbG btYuRk4OCQETifVLupkgbDGJC/fWs3UxcnEICRxmlLgzZR8zSEJIYAmjRPMq+S5GDg42AQuJ 7n/aIGERAXmJ7rZFYL3MAoES7f1vWUBsYQFDid8XTjFD1BhJXFu/nwXCjpLoWDuLEcRmEVCV uPh5FzuIzSvgK9Het5UVYu8aNomPd8+BHccpoClxYPttNhCbEei476fWQC0Tl7j1ZD7U0QIS S/acZ4awRSVePv7HCnKnhICixPJ+OYhyHYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjGKzkEyd haRlFpKWWUhaFjCyrGJkz03MzEkvN9/ECIyZg1t+G+xg3HRf7BCjNAeLkjhvn/bUQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2M/aY/rycfmbYie/80D4Wq+XrhMYJH5M0z/15Lu7PA6qbK 8SiJ6IBY+0tOnNJaty/8C7f6X/O2Iv/MLo23h/krts4/fUs0PkJSe5H1crmQO9m7/J5V5S87 Pr8he5Wu5QYt1tkTEv14dtvf+qHPuWjurdDyg3fbT/9zDROc4qf/59mqRe8sTy0/rMRSnJFo qMVcVJwIAOzBaLhnAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:04:16 -0000 Hi, >>>> What if the new source produces pre-encoded stream that is not been=20 >>>> negotiated within the current session ? >>>> example: video m=3Dline with VP8 is setup and H.264 encoded camera is= =20 >>>> added as new source. This needs a O/A negotiation for the=20 >>>> appropriate decoder context to be setup on the receiver side >>> >>> Obviously this does require a new O/A but I don't see how that case is = related to adding and removing SSRCs which do not require O/A exchanges. >>=20 >> It depends on whether you need to signal the SSRC to the remote endpoint= for demux purpose. > > Exactly, and since I've been arguing that you don't ... :) Ok. So, maybe I've missed it, but how do you suggest the received media is: 1. associated with the m- line; and 2. demuxed Regards, Christer From emcho@sip-communicator.org Thu May 23 04:09:16 2013 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 CE43D21F96E5 for ; Thu, 23 May 2013 04:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGXdPgAWN1gW for ; Thu, 23 May 2013 04:09:11 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF221F96D6 for ; Thu, 23 May 2013 04:09:11 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa10so2850075pad.19 for ; Thu, 23 May 2013 04:09:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9Pah7iUN2BGfvpoYQHdM5u+cY/AkbWgeM6im/7yNoH0=; b=SxaZ8v60pUVkjLSbObMKLikp4byIKbmUR9x1aoYVQkZr7APg84g7N6FDRSz4/Qfn+O j+6a9WkVnvUpGuJ/UzSkKqH9rti7MOxz/rdkQ9BxYLkLiNDPze26tQvcaWyDrk352HaY 6Judtf8oWvxP/pm22kJUZDVUR6COPszW18kjKN04uaha4wmsNL6N56CMV5t/0wr3dJXS j/lW8hOWHoZZwPh+lRlO0JergDTxWWWAwQnSdF5YGDUETRBpV+xLpb8AKhwgQsm+zGva EOrdJQnxRNmBheSwg2W8FDGWk+Tv0Enloc648WvJAHg486XAivL04e8dO37cR7sDBr5j 9Jdg== X-Received: by 10.68.103.194 with SMTP id fy2mr12225840pbb.158.1369307347014; Thu, 23 May 2013 04:09:07 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [2607:f8b0:400e:c01::229]) by mx.google.com with ESMTPSA id gh9sm11308740pbc.37.2013.05.23.04.09.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 04:09:06 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id xb12so2762960pbc.0 for ; Thu, 23 May 2013 04:09:06 -0700 (PDT) X-Received: by 10.66.216.198 with SMTP id os6mr12539778pac.145.1369307346075; Thu, 23 May 2013 04:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.89.234 with HTTP; Thu, 23 May 2013 04:08:45 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C376B8B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> <519DF308.6050203@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376B8B@ESESSMB209.ericsson.se> From: Emil Ivov Date: Thu, 23 May 2013 14:08:45 +0300 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl/xZ1t5bqd23wEe022o1+SftUCbhUqgf/vYtuH/c4CL0tQgtp05j3z6WyD6+L8VNckbLgU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:09:16 -0000 On Thu, May 23, 2013 at 2:04 PM, Christer Holmberg wrote: > Hi, > >>>>> What if the new source produces pre-encoded stream that is not been >>>>> negotiated within the current session ? >>>>> example: video m=line with VP8 is setup and H.264 encoded camera is >>>>> added as new source. This needs a O/A negotiation for the >>>>> appropriate decoder context to be setup on the receiver side >>>> >>>> Obviously this does require a new O/A but I don't see how that case is related to adding and removing SSRCs which do not require O/A exchanges. >>> >>> It depends on whether you need to signal the SSRC to the remote endpoint for demux purpose. >> >> Exactly, and since I've been arguing that you don't ... :) > > Ok. So, maybe I've missed it, but how do you suggest the received media is: > > 1. associated with the m- line; and Payload type. (And you either drop bundle when you run out of those > 2. demuxed Based on SSRC and application specific signalling. (Presuming that by demuxed you mean identified) Emil From christer.holmberg@ericsson.com Thu May 23 04:20:36 2013 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 D514721F9121 for ; Thu, 23 May 2013 04:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.806 X-Spam-Level: X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eGldmuyuC3Y for ; Thu, 23 May 2013 04:20:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30C2221F9609 for ; Thu, 23 May 2013 04:20:29 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-8e-519dfb7ca529 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6E.42.28930.C7BFD915; Thu, 23 May 2013 13:20:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Thu, 23 May 2013 13:20:28 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkSUCmAgAAKMICAABCkAIAAARsAgAAjHBD//+3HAIAAJp6A///gMICAACOogA== Date: Thu, 23 May 2013 11:20:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376BBA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> <519DF308.6050203@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376B8B@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrW7N77mBBk3HVCzW7JzAYrH2Xzu7 xc65HcwOzB47Z91l91iy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZx65eYCx4w1XRtvwlcwPj fo4uRk4OCQETif8fmtkgbDGJC/fWA9lcHEIChxkl7p9dywqSEBJYwiixe5FRFyMHB5uAhUT3 P22QsIiAvER32yImEJtZIFCivf8tC4gtLGAo8fvCKWaIGiOJa+v3s0DYWRLfl19gBLFZBFQl HvQdBLN5BXwlGu60skDs3c4ucXzidbCDOIGGPrk5C2wQI9Bx30+tgVomLnHryXwmiKMFJJbs Oc8MYYtKvHz8jxXkTgkBRYnl/XIQ5ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiGZOgtJ yywkLbOQtCxgZFnFyJ6bmJmTXm64iREYMwe3/NbdwXjqnMghRmkOFiVx3l7tqYFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGAO/Mom7S1yXOVxY/Kmm0OhhtmvItczT+/Us/+y8V8QZuvDV R+Xjb17zC35SnpYv+6iJueznggeBbNcUhTZfLVe5xf287se38LrfF/Wdehqc82NfrsvjmRka t+k+39fzIkwfVe/vXazh/NCg2v+p5JXS5T/q5hg/VRRIvltrVJSZvN+6s/ntTSWW4oxEQy3m ouJEAKTyIHFnAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:20:37 -0000 Hi, >>>>>> What if the new source produces pre-encoded stream that is not=20 >>>>>> been negotiated within the current session ? >>>>>> example: video m=3Dline with VP8 is setup and H.264 encoded camera=20 >>>>>> is added as new source. This needs a O/A negotiation for the=20 >>>>>> appropriate decoder context to be setup on the receiver side >>>>> >>>>> Obviously this does require a new O/A but I don't see how that case i= s related to adding and removing SSRCs which do not require O/A exchanges. >>>> >>>> It depends on whether you need to signal the SSRC to the remote endpoi= nt for demux purpose. >>> >>> Exactly, and since I've been arguing that you don't ... :) >> >> Ok. So, maybe I've missed it, but how do you suggest the received media = is: >> >> 1. associated with the m- line; and > > Payload type. (And you either drop bundle when you run out of those My understanding is that people have indicated that the payload type value = space is too small.=20 Or, did we agree it isn't? :) >> 2. demuxed > > Based on SSRC and application specific signalling. (Presuming that by dem= uxed you mean identified) Yes. I am not sure what you mean by application specific signaling, but for SDP = we do need to describe in BUNDLE how it is done. Or, do you assume, at any given point, a single SSRC per m- line? Regards, Christer From sergio.garcia.murillo@gmail.com Thu May 23 04:34:24 2013 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 17B0721F9615 for ; Thu, 23 May 2013 04:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMES9IJBgAZG for ; Thu, 23 May 2013 04:34:23 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B585D21F9601 for ; Thu, 23 May 2013 04:34:21 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id my13so1760974bkb.5 for ; Thu, 23 May 2013 04:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Qe95q0T714kYXmbPgU6Q6V3gRRwScWFLH1w/c7YnlR8=; b=sioFJ2BEYti7sMzTJRhsRpphgiiJ9FgNXwP6optFZ1VFJVBjek9BM/N2p884KLzlda LLsgJBFiCqnvVFrt8GOX0ThUENE25ZVGavoBiENo7pqAI2b1algiHdPRhi73hvqldTda Yv0qB8XitzvuNsoztOXCm7En8qEWAKC7vTet8xMyXKkqPB7vuJDbLh+I+ieeaWLRsWU8 dl2MTJMifdq34jIgxZEAopHhpSg/LFtKWnlKL99qIJcUy9+n8C83axsvagHMwPG+9NsK n22Pqo8afRsO3prciK/v8j8/tmU3PBcsLhmo4SukN9uwYFyBRyqDcJjLfghqZ8BdfhGw /7eQ== X-Received: by 10.205.42.194 with SMTP id tz2mr6321089bkb.129.1369308860782; Thu, 23 May 2013 04:34:20 -0700 (PDT) Received: from [192.168.1.50] (105.Red-95-122-160.staticIP.rima-tde.net. [95.122.160.105]) by mx.google.com with ESMTPSA id iy11sm3152138bkb.11.2013.05.23.04.34.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 04:34:19 -0700 (PDT) Message-ID: <519F5037.90004@gmail.com> Date: Fri, 24 May 2013 13:34:15 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> <519DF308.6050203@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376B8B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C376BBA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C376BBA@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------000207080309000705070905" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:34:24 -0000 This is a multi-part message in MIME format. --------------000207080309000705070905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 23/05/2013 13:20, Christer Holmberg escribió: >> Based on SSRC and application specific signalling. (Presuming that by demuxed you mean identified) > Yes. > > I am not sure what you mean by application specific signaling, but for SDP we do need to describe in BUNDLE how it is done. > > Or, do you assume, at any given point, a single SSRC per m- line? Application specific signaling like RFC 4575 - A Session Initiation Protocol (SIP) Event Package for Conference State: 5.8.4 . The element, if applicable, carries the information about the actual source of the media. For example, for Real-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) [13 ] media streams, the value MUST contain the synchronization source (SSRC) identifier value generated by the endpoint for the stream it sends. Best regards Sergio --------------000207080309000705070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 23/05/2013 13:20, Christer Holmberg escribió: 
Based on SSRC and application specific signalling. (Presuming that by demuxed you mean identified)

Yes.

I am not sure what you mean by application specific signaling, but for SDP we do need to describe in BUNDLE how it is done.

Or, do you assume, at any given point, a single SSRC per m- line?

Application specific signaling like RFC 4575 - A Session Initiation Protocol (SIP) Event Package for Conference State:

5.8.4.  <src-id>


   The <src-id> element, if applicable, carries the information about
   the actual source of the media.  For example, for Real-time Transport
   Protocol (RTP) / RTP Control Protocol (RTCP) [13] media streams, the
   value MUST contain the synchronization source (SSRC) identifier value
   generated by the endpoint for the stream it sends.

 
Best regards
Sergio

--------------000207080309000705070905-- From emil@sip-communicator.org Thu May 23 04:35:45 2013 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 0D03021F9601 for ; Thu, 23 May 2013 04:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy0Tlftv-YwV for ; Thu, 23 May 2013 04:35:44 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1354121F960D for ; Thu, 23 May 2013 04:35:39 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji2so1781457bkc.38 for ; Thu, 23 May 2013 04:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=XF0HEfXyKDAqa0JEqseVtw0aEPxwFZWRig31qzOIgLo=; b=hAYBnxW9DeWBDvCTkY8afTn/x+Cnml71WvWMwoNNA8nUDC9K2hg8Sal7SqBZ1KeH1M +DnDFPMY4kpGSBq74/Ap2QqvvkovTTeYZC93a6/H9isUseE+FS13nfROKiCSCSdBOIup hHfDjeoUJL6AzSqP0rgFL7N+BJ03oaZdAYiqo2+v6xNDPGBk9MyXj6p73WI6e7yOk1XJ AoliHb6i+boOHUuOesGqEOG1vyOypNnDd/zejQpBl88Rt8JA1hM6X9m+VjjfckKzzMCi GFdn4RgO9f90+e8GCeKrfeQ6Ht9TYzclkJEhhBCDC6NtyPCV59gHn86wOAWFjLKBBFDt Ofpw== X-Received: by 10.204.166.206 with SMTP id n14mr6348074bky.138.1369308937875; Thu, 23 May 2013 04:35:37 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.4]) by mx.google.com with ESMTPSA id iy11sm3153789bkb.11.2013.05.23.04.35.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 04:35:37 -0700 (PDT) Message-ID: <519DFF04.3040108@jitsi.org> Date: Thu, 23 May 2013 14:35:32 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> <519DF308.6050203@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376B8B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C376BBA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C376BBA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm6a0BKCruoviq3HXpSKOgFiuUbn4rt/Xk/oW7Zqbq3xxPQuW0b+GSWeuJGqaX6Okqa43rv Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:35:45 -0000 On 23.05.13, 14:20, Christer Holmberg wrote: > Hi, > >>>>>>> What if the new source produces pre-encoded stream that is not >>>>>>> been negotiated within the current session ? >>>>>>> example: video m=line with VP8 is setup and H.264 encoded camera >>>>>>> is added as new source. This needs a O/A negotiation for the >>>>>>> appropriate decoder context to be setup on the receiver side >>>>>> >>>>>> Obviously this does require a new O/A but I don't see how that case is related to adding and removing SSRCs which do not require O/A exchanges. >>>>> >>>>> It depends on whether you need to signal the SSRC to the remote endpoint for demux purpose. >>>> >>>> Exactly, and since I've been arguing that you don't ... :) >>> >>> Ok. So, maybe I've missed it, but how do you suggest the received media is: >>> >>> 1. associated with the m- line; and >> >> Payload type. (And you either drop bundle when you run out of those > > My understanding is that people have indicated that the payload type value space is too small. > > Or, did we agree it isn't? :) This would be a problem if it meant that exhausting it would prevent you from using any more more formats. This is not the case. Exhausting the PT value space only means that you have to start a second bundle (or stop using bundle). Note that depending on how big you are willing to accept the PT space is this would either be relatively rare case (if you only want to use 32 values) or a quite unlikely one (if you are brave enough to allocate all 96). Also note that dropping bundle in such cases would only mean a slightly higher connection establishment time (we still have trickle ICE) and a negligibly higher overall use of port numbers, so I don't think we should consider this a big deal. >>> 2. demuxed >> >> Based on SSRC and application specific signalling. (Presuming that by demuxed you mean identified) > > Yes. > > I am not sure what you mean by application specific signaling, but for SDP we do need to describe in BUNDLE how it is done. Why do you need to describe this? Applications could be sending such info through SIP and RRC 4575, or XMPP and XEP-0298 or some completely different signalling mechanism. > Or, do you assume, at any given point, a single SSRC per m- line? No. I assume no such thing. I am actually insisting on the opposite! :) Cheers, Emil -- https://jitsi.org From christer.holmberg@ericsson.com Thu May 23 04:44:55 2013 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 891E221F8CF4 for ; Thu, 23 May 2013 04:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8qowCe6TXd8 for ; Thu, 23 May 2013 04:44:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30921F8B98 for ; Thu, 23 May 2013 04:44:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-b8-519e01297d15 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DD.38.06701.9210E915; Thu, 23 May 2013 13:44:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 23 May 2013 13:44:41 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOUzwnCrd1S7QwyEqM9DOrRHv1xJkSUCmAgAAKMICAABCkAIAAARsAgAAjHBD//+3HAIAAJp6A///gMICAACOogP//49MAAARLWVA= Date: Thu, 23 May 2013 11:44:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376C61@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <519DE4DE.8070508@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376A54@ESESSMB209.ericsson.se> <519DF308.6050203@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C376B8B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C376BBA@ESESSMB209.ericsson.se> <519DFF04.3040108@jitsi.org> In-Reply-To: <519DFF04.3040108@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvra4m47xAg0UvtSzW7JzAYrH2Xzu7 xc65HcwOzB47Z91l91iy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZm2+8YCxYJF5xqfscewPj RqEuRk4OCQETicWL9rBA2GISF+6tZwOxhQQOM0o8X10CYS9hlDi0K72LkYODTcBCovufNkhY REBeorttEROIzSwQKNHe/xZsjLCAocTvC6eYIWqMJK6t388CYZdJXN36kBHEZhFQlTi8fS87 iM0r4Csx/cYBRohVszgkrpzWB7E5BTQlpk85DjaHEei076fWQO0Sl7j1ZD4TxMkCEkv2nGeG sEUlXj7+xwpypoSAosTyfjmIch2JBbs/sUHY2hLLFr5mhlgrKHFy5hOWCYxis5BMnYWkZRaS lllIWhYwsqxiZM9NzMxJLzffxAiMl4NbfhvsYNx0X+wQozQHi5I4b5/21EAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjAVvBFaXMKjfK/YtPehV9z/v94on7dOW71iq0LJ7i97VJodZG9Zz ef123Jzl/LF3RuZzc79Sq++3k4+7HzLxf5z1ZenC753pLs+2Pp+3f5L7D/WOjZ1fORPC7vct kA1992lxWvFd9gx5y6cC6qqsDqE5zj7/ZTZy6YXMWytn8odt0fknzx3LbimxFGckGmoxFxUn AgCEFLuTZQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:44:55 -0000 Hi, >>>>>>>> What if the new source produces pre-encoded stream that is not=20 >>>>>>>> been negotiated within the current session ? >>>>>>>> example: video m=3Dline with VP8 is setup and H.264 encoded camera= =20 >>>>>>>> is added as new source. This needs a O/A negotiation for the=20 >>>>>>>> appropriate decoder context to be setup on the receiver side >>>>>>> >>>>>>> Obviously this does require a new O/A but I don't see how that case= is related to adding and removing SSRCs which do not require O/A exchanges= . >>>>>> >>>>>> It depends on whether you need to signal the SSRC to the remote endp= oint for demux purpose. >>>>> >>>>> Exactly, and since I've been arguing that you don't ... :) >>>> >>>> Ok. So, maybe I've missed it, but how do you suggest the received medi= a is: >>>> >>>> 1. associated with the m- line; and >>> >>> Payload type. (And you either drop bundle when you run out of those >>=20 >> My understanding is that people have indicated that the payload type val= ue space is too small.=20 >>=20 >> Or, did we agree it isn't? :) > > This would be a problem if it meant that exhausting it would prevent you = from using any more more formats. This is not the case.=20 > Exhausting the PT value space only means that you have to start a second = bundle (or stop using bundle). > > Note that depending on how big you are willing to accept the PT space is = this would either be relatively rare case (if you only want to use 32 > values) or a quite unlikely one (if you are brave enough to allocate all = 96). > > Also note that dropping bundle in such cases would only mean a slightly h= igher connection establishment time (we still have trickle ICE) and a=20 > negligibly higher overall use of port numbers, so I don't think we should= consider this a big deal. If the community can agree on PT usage, fine. My understanding is that we c= urrently do not have such agreement :) >>>> 2. demuxed >>> >>> Based on SSRC and application specific signalling. (Presuming that by=20 >>> demuxed you mean identified) >>=20 >> Yes. >>=20 >> I am not sure what you mean by application specific signaling, but for S= DP we do need to describe in BUNDLE how it is done. > > Why do you need to describe this? Applications could be sending such info= through SIP and RRC 4575, or XMPP and XEP-0298 or some completely differen= t signalling mechanism. > >> Or, do you assume, at any given point, a single SSRC per m- line? > > No. I assume no such thing. I am actually insisting on the opposite! :) If the community can agree that, from a BUNDLE perspective, we don't need t= o care about SSRC values, fine :) However, from a more general SDP perspective, it is possible to indicate SS= RC specific values, using the SDP ssrc attribute. Now, that assumes that th= ose SSRCs will actually be used, and not changed (at least not without asso= ciated signaling). Regards, Christer From harald@alvestrand.no Thu May 23 04:48:09 2013 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 BE94421F9260 for ; Thu, 23 May 2013 04:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.649 X-Spam-Level: X-Spam-Status: No, score=-108.649 tagged_above=-999 required=5 tests=[AWL=-1.949, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0LmcyOhM222 for ; Thu, 23 May 2013 04:47:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B739821F9234 for ; Thu, 23 May 2013 04:47:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63B1C39E176; Thu, 23 May 2013 13:47:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJonUH8CJNgV; Thu, 23 May 2013 13:47:54 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6461939E070; Thu, 23 May 2013 13:47:53 +0200 (CEST) Message-ID: <519E01E8.2090403@alvestrand.no> Date: Thu, 23 May 2013 13:47:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> <51922959.3070708@alvestrand.no> <51931EF3.7080108@jitsi.org> <51932A2B.1080700@alvestrand.no> <5193B285.8090604@jitsi.org> In-Reply-To: <5193B285.8090604@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 11:48:10 -0000 Apologies for being late in the response.... On 05/15/2013 06:06 PM, Emil Ivov wrote: > On 15.05.13, 09:24, Harald Alvestrand wrote: >> >> Exactly - IF the party sending the SSRC is able to see when the >> offer/answer completes. >> The offerer is the only party that can actually know if the offer/answer >> exchange is complete. > OK, got it. > > Then, going back to your second bullet, we could apply the same > buffering as the one you currently describe there. Only this time, once > we are done with the offer/answer things could go either way: we could > end up either signalling a new track or determining that packets > actually belong to some specific stream. Hm. Declaring a moratorium on "onaddstream" events while a negotiation is in progress actually solves the problem - I think! In the case where signalling takes a while to complete (response got lost, signalling relay server is overloaded, or something else weird happens) we do have a problem with buffering - we have to be able to throw away some data at some point, or we require infinite buffers. But throwing away RTP data is something we have to deal with anyway - recovery should not be much worse than after a temporary transmission glitch. > > If this makes sense, I'd be happy to propose text if it helps. > >> So the ambiguity only applies if the answerer is able to announce new >> SSRCs in an answer. >> Is it reasonable to remove this functionality (and thereby mandating >> Plan B's double offer/answer) in order to achieve this functionality? >> >>> This way one would be able to only announce SSRCs for things such as FEC >>> and simulcasting (where available) while simple streams could be >>> delivered immediately. >> As long as you don't need any information not carried in the RTP packet >> in order to announce the stream correctly, this would work. > I suppose we'll get there eventually. RTCP is one option here but what I > am personally hoping is that we'll agree that the APIs can also start > providing that information so that web apps can exchange it any way they > wish. Before, with, or after the SDP O/A has taken place. If we're depending on RTCP, we have to wait until the first RTCP packet arrives, of course. > > Cheers, > Emil > > From andrew.hutton@siemens-enterprise.com Thu May 23 06:09:01 2013 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 2298421F93B1; Thu, 23 May 2013 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuWam1ftClVd; Thu, 23 May 2013 06:08:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 421F121F93BC; Thu, 23 May 2013 06:08:55 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 481C41EB8648; Thu, 23 May 2013 15:08:54 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 23 May 2013 15:08:54 +0200 From: "Hutton, Andrew" To: Simon Perreault , Karl Stahl Thread-Topic: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVs8PvK/QKOM3AUmVgv4HMJ4KjZkSvTfQ Date: Thu, 23 May 2013 13:08:53 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> In-Reply-To: <519C904B.2040305@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 13:09:01 -0000 At least with regard to draft-hutton-rtcweb-nat-firewall-considerations we = are not attempting to enter or add to any existing arms race between client= s and firewalls. We are only describing how to use existing IETF protocols which already ext= ensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet the RTCW= EB requirements in this area which have existed in http://tools.ietf.org/ht= ml/draft-ietf-rtcweb-use-cases-and-requirements-10 for almost two years now= . Of course if a network administer wants to block RTCWEB media they should b= e able to so and nobody is I believe suggesting that we try to prevent this= . Regards Andy > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: 22 May 2013 10:31 > To: Karl Stahl > Cc: rtcweb@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification > for draft-chenxin-behave-turn-websocket-00.txt >=20 > Le 2013-05-22 11:04, Karl Stahl a =E9crit : > >> Firewall traversal is a completely different beast. > > > > Not really. There are always firewall functions included in "a NAT" > (e.g. > > open for traffic from inside to outside and you can then get traffic > back > > the same path - with some timeout), even if the RFCs only call the > box "a > > NAT". I prefer to say NAT/Firewall. >=20 > You're focusing on the technical aspect. The difference I'm considering > is not technical. >=20 > NAT traversal is performed with the agreement of everyone involved, > whereas firewall traversal is a battle between the client implementer > and the firewall administrator. There's also a potential arms race: > firewalls will evolve with the ability to block whatever we > standardize, > so we will need a newer traversal method, which firewalls will end up > blocking as well, etc. etc. etc. We don't want to play that game. >=20 > NAT traversal: ok > Firewall traversal: not for the IETF >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From hangzhou.chenxin@huawei.com Thu May 23 19:26:38 2013 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 35EB721F93E9; Thu, 23 May 2013 19:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.027 X-Spam-Level: X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[AWL=-1.571, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv45bbbPSdx2; Thu, 23 May 2013 19:26:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B36A321F93ED; Thu, 23 May 2013 19:26:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATC27475; Fri, 24 May 2013 02:26:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 03:26:12 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 03:26:25 +0100 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.68]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Fri, 24 May 2013 10:26:22 +0800 From: "Chenxin (Xin)" To: Simon Perreault , Karl Stahl Thread-Topic: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVs8m6PhKpPzBWESvuGMiUrIKUZkTliFQ Date: Fri, 24 May 2013 02:26:22 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> In-Reply-To: <519C904B.2040305@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 02:26:38 -0000 ICAgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgdHJ5IHRvIGJhdHRsZSB3aXRoIG5ldHdvcmsg YWRtaW5pc3RyYXRvciwgYW5kIHdlIGFyZSBub3QgZG9pbmcgdGhhdC4gV2UganVzdCBzdXBwbHkg c29tZSB0ZWNobmljYWwgdG9vbHMgdG8gcnRjd2ViIGltcGxlbWVudGVyLCB0byBtYWtlIHRoZSB1 c2VycyBjb3VsZCBnZXQgYmVuZWZpdCBhbmQgY29udmVuaWVuY2Ugd2hlbiB1c2luZyBydGN3ZWIu IEZhbGxiYWNrIG1ldGhvZHMgYW5kIHByb3Bvc2FscyBhcmUgZm9yIHRoaXMgcHVycG9zZS4gIFdl IGNvdWxkIG5vdCBkZWNpZGUgdGhhdCBob3cgd2lsbCBhIGtpbmQgb2YgdGVjaG5pcXVlIGJlIHVz ZWQuIEV2ZXJ5IHRlY2huaXF1ZSBjb3VsZCBiZSB1c2VkIGluIGEgZ29vZCB3YXkgYW5kIGEgYmFk IHdheS4gIEkgYmVsaWV2ZSB0aGF0IHJ0Y3dlYiBpcyBhIGdvb2QgYW5kIHRydXN0d29ydGh5IHRl Y2huaXF1ZSB3aGljaCBpcyBkaWZmZXJlbnQgd2l0aCB0aGUgc29tZSBoYXJtZnVsIHRoaW5ncyB3 aGljaCBzaG91bGQgYmUgYmxvY2tlZCBieSB0aGUgYWRtaW5pc3RlcnMuIFNvIGxldCB1cyBiYWNr IHRvIHRoZSB0ZWNobmljYWwgYXNwZWN0OiBzaG91bGQgd2UgbmVlZCB0byBzdXBwb3J0IGEgZmFs bGJhY2sgbWV0aG9kIGluIHJ0Y3dlYiBub3c/IFdoaWNoIG9uZSBzaG91bGQgd2Ugc3VwcG9ydCB0 byBNVEk/IFdoaWNoIG9uZSBzaG91bGQgd2Ugc3VwcG9ydCB0byBiZSBhIG9wdGlvbj8gSSB0aGlu ayBub3cgdGhlcmUgaXMgdGhyZWUgbWV0aG9kIHRvIHNvbHZlIHRoZSBmYWxsYmFjayByZXF1aXJl bWVudKO6VFVSTi9UTFMsIEhUVFAgY2hhbm5lbCAsIFRVUk4vV1Mgb3IgSFRUUC4gSSBhbSB3aWxs aW5nIHRvIHdyaXRlIGEgbWFpbCB0aGVzZSBkYXlzIHRvIG1ha2UgYSBzaW1wbGUgY29uY2x1c2lv biBhbmQgY29tcGFyaXNvbiBiZXR3ZWVuIHRoZXNlIG1ldGhvZHMsIHdoaWNoIHdpbGwgcHJvdmlk ZSBhIG1hdGVyaWFsIHRvIFdHIGZvciBmdXR1cmUgZGlzY3Vzc2lvbiBhbmQgZGVjaXNpb24uDQoN CkJlc3QgUmVnYXJkcywNCiAgICAgWGluIA0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPlNpbW9uIFBlcnJlYXVsdA0KPlNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDIyLCAyMDEzIDU6MzEgUE0NCj5UbzogS2FybCBTdGFobA0KPkNjOiBydGN3ZWJAaWV0 Zi5vcmc7IGJlaGF2ZUBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbQkVIQVZFXSBX aHk/IFF1YWxpdHkhIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1jaGVueGlu LWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQNCj4NCj5MZSAyMDEzLTA1LTIyIDExOjA0LCBL YXJsIFN0YWhsIGEgqKZjcml0IDoNCj4+PiBGaXJld2FsbCB0cmF2ZXJzYWwgaXMgYSBjb21wbGV0 ZWx5IGRpZmZlcmVudCBiZWFzdC4NCj4+DQo+PiBOb3QgcmVhbGx5LiBUaGVyZSBhcmUgYWx3YXlz IGZpcmV3YWxsIGZ1bmN0aW9ucyBpbmNsdWRlZCBpbiAiYSBOQVQiIChlLmcuDQo+PiBvcGVuIGZv ciB0cmFmZmljIGZyb20gaW5zaWRlIHRvIG91dHNpZGUgYW5kIHlvdSBjYW4gdGhlbiBnZXQgdHJh ZmZpYyBiYWNrDQo+PiB0aGUgc2FtZSBwYXRoIC0gd2l0aCBzb21lIHRpbWVvdXQpLCBldmVuIGlm IHRoZSBSRkNzIG9ubHkgY2FsbCB0aGUgYm94ICJhDQo+PiBOQVQiLiBJIHByZWZlciB0byBzYXkg TkFUL0ZpcmV3YWxsLg0KPg0KPllvdSdyZSBmb2N1c2luZyBvbiB0aGUgdGVjaG5pY2FsIGFzcGVj dC4gVGhlIGRpZmZlcmVuY2UgSSdtIGNvbnNpZGVyaW5nDQo+aXMgbm90IHRlY2huaWNhbC4NCj4N Cj5OQVQgdHJhdmVyc2FsIGlzIHBlcmZvcm1lZCB3aXRoIHRoZSBhZ3JlZW1lbnQgb2YgZXZlcnlv bmUgaW52b2x2ZWQsDQo+d2hlcmVhcyBmaXJld2FsbCB0cmF2ZXJzYWwgaXMgYSBiYXR0bGUgYmV0 d2VlbiB0aGUgY2xpZW50IGltcGxlbWVudGVyDQo+YW5kIHRoZSBmaXJld2FsbCBhZG1pbmlzdHJh dG9yLiBUaGVyZSdzIGFsc28gYSBwb3RlbnRpYWwgYXJtcyByYWNlOg0KPmZpcmV3YWxscyB3aWxs IGV2b2x2ZSB3aXRoIHRoZSBhYmlsaXR5IHRvIGJsb2NrIHdoYXRldmVyIHdlIHN0YW5kYXJkaXpl LA0KPnNvIHdlIHdpbGwgbmVlZCBhIG5ld2VyIHRyYXZlcnNhbCBtZXRob2QsIHdoaWNoIGZpcmV3 YWxscyB3aWxsIGVuZCB1cA0KPmJsb2NraW5nIGFzIHdlbGwsIGV0Yy4gZXRjLiBldGMuIFdlIGRv bid0IHdhbnQgdG8gcGxheSB0aGF0IGdhbWUuDQo+DQo+TkFUIHRyYXZlcnNhbDogb2sNCj5GaXJl d2FsbCB0cmF2ZXJzYWw6IG5vdCBmb3IgdGhlIElFVEYNCj4NCj5TaW1vbg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlz dA0KPnJ0Y3dlYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQo= From bernard_aboba@hotmail.com Thu May 23 23:36:49 2013 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 16F9621F8F83; Thu, 23 May 2013 23:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.743 X-Spam-Level: X-Spam-Status: No, score=-101.743 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, PLING_QUERY=1.39, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-BXT7VBNv11; Thu, 23 May 2013 23:36:44 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 489B621F8C23; Thu, 23 May 2013 23:36:44 -0700 (PDT) Received: from BLU405-EAS59 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 May 2013 23:36:43 -0700 X-EIP: [OhkgpYU1LN0YWREBbomot1FY+n/nOFNd] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> Date: Fri, 24 May 2013 07:36:41 +0100 To: X-OriginalArrivalTime: 24 May 2013 06:36:43.0099 (UTC) FILETIME=[0DFEEAB0:01CE5849] Cc: "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 06:36:49 -0000 SSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBsdW1wIFRVUk4gZnVuY3Rpb25hbGl0eSAo ZS5nLiBUVVJOIG92ZXIgVENQLCBUTFMgb3IgV1MpIGluIHRoZSBzYW1lIGJ1Y2tldCBhcyB0cmFu c3BvcnQgb3ZlciBIVFRQL0hUVFBTIG9yIFdTLCBzaW5jZSB0aGUgZm9ybWVyIGludm9sdmVzIHRo ZSBQZWVyQ29ubmVjdGlvbiBBUEkgYnV0IHRoZSBsYXR0ZXIgbmVlZCBub3QuIA0KDQpJZiBJQ0Ug ZmFpbHMsIGFuIGFwcGxpY2F0aW9uIGNhbiB0cnkgYWx0ZXJuYXRpdmVzLiBBcyBsb25nIGFzIHRo b3NlIGFsdGVybmF0aXZlcyBkb24ndCBpbnZvbHZlIHBlZXIgdG8gcGVlciB0cmFuc3BvcnQgb2Yg bWVkaWEgb3ZlciBodHRwL2h0dHBzIG9yIFdTLCBpdCBpc24ndCBjbGVhciB0byBtZSB0aGF0IHdl IG5lZWQgYSBzdGFuZGFyZCBlbmNhcHN1bGF0aW9uLiBBbmQgaWYgd2UgYXJlIHRhbGtpbmcgYWJv dXQgcGVlci10by1wZWVyIHRoZW4gdGhpcyBpbXBsaWVzIGFuIGh0dHAvaHR0cHMgb3IgV1Mgc2Vy dmVyIGluIHRoZSBicm93c2VyLCB3aGljaCBzZWVtcyBsaWtlIGl0IGlzIG91dCBvZiBzY29wZSwg YXQgbGVhc3QgaW4gdGhpcyBkaXNjdXNzaW9uLg0KDQpPbiBNYXkgMjQsIDIwMTMsIGF0IDM6MjYs ICJDaGVueGluIChYaW4pIiA8aGFuZ3pob3UuY2hlbnhpbkBodWF3ZWkuY29tPiB3cm90ZToNCg0K PiAgIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IHRyeSB0byBiYXR0bGUgd2l0aCBuZXR3b3Jr IGFkbWluaXN0cmF0b3IsIGFuZCB3ZSBhcmUgbm90IGRvaW5nIHRoYXQuIFdlIGp1c3Qgc3VwcGx5 IHNvbWUgdGVjaG5pY2FsIHRvb2xzIHRvIHJ0Y3dlYiBpbXBsZW1lbnRlciwgdG8gbWFrZSB0aGUg dXNlcnMgY291bGQgZ2V0IGJlbmVmaXQgYW5kIGNvbnZlbmllbmNlIHdoZW4gdXNpbmcgcnRjd2Vi LiBGYWxsYmFjayBtZXRob2RzIGFuZCBwcm9wb3NhbHMgYXJlIGZvciB0aGlzIHB1cnBvc2UuICBX ZSBjb3VsZCBub3QgZGVjaWRlIHRoYXQgaG93IHdpbGwgYSBraW5kIG9mIHRlY2huaXF1ZSBiZSB1 c2VkLiBFdmVyeSB0ZWNobmlxdWUgY291bGQgYmUgdXNlZCBpbiBhIGdvb2Qgd2F5IGFuZCBhIGJh ZCB3YXkuICBJIGJlbGlldmUgdGhhdCBydGN3ZWIgaXMgYSBnb29kIGFuZCB0cnVzdHdvcnRoeSB0 ZWNobmlxdWUgd2hpY2ggaXMgZGlmZmVyZW50IHdpdGggdGhlIHNvbWUgaGFybWZ1bCB0aGluZ3Mg d2hpY2ggc2hvdWxkIGJlIGJsb2NrZWQgYnkgdGhlIGFkbWluaXN0ZXJzLiBTbyBsZXQgdXMgYmFj ayB0byB0aGUgdGVjaG5pY2FsIGFzcGVjdDogc2hvdWxkIHdlIG5lZWQgdG8gc3VwcG9ydCBhIGZh bGxiYWNrIG1ldGhvZCBpbiBydGN3ZWIgbm93PyBXaGljaCBvbmUgc2hvdWxkIHdlIHN1cHBvcnQg dG8gTVRJPyBXaGljaCBvbmUgc2hvdWxkIHdlIHN1cHBvcnQgdG8gYmUgYSBvcHRpb24/IEkgdGhp bmsgbm93IHRoZXJlIGlzIHRocmVlIG1ldGhvZCB0byBzb2x2ZSB0aGUgZmFsbGJhY2sgcmVxdWly ZW1lbnTvvJpUVVJOL1RMUywgSFRUUCBjaGFubmVsICwgVFVSTi9XUyBvciBIVFRQLiBJIGFtIHdp bGxpbmcgdG8gd3JpdGUgYSBtYWlsIHRoZXNlIGRheXMgdG8gbWFrZSBhIHNpbXBsZSBjb25jbHVz aW9uIGFuZCBjb21wYXJpc29uIGJldHdlZW4gdGhlc2UgbWV0aG9kcywgd2hpY2ggd2lsbCBwcm92 aWRlIGEgbWF0ZXJpYWwgdG8gV0cgZm9yIGZ1dHVyZSBkaXNjdXNzaW9uIGFuZCBkZWNpc2lvbi4N Cj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gICAgIFhpbiANCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gU2ltb24gUGVycmVhdWx0 DQo+PiBTZW50OiBXZWRuZXNkYXksIE1heSAyMiwgMjAxMyA1OjMxIFBNDQo+PiBUbzogS2FybCBT dGFobA0KPj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gW0JFSEFWRV0gV2h5PyBRdWFsaXR5ISBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+PiBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQN Cj4+IA0KPj4gTGUgMjAxMy0wNS0yMiAxMTowNCwgS2FybCBTdGFobCBhIMOpY3JpdCA6DQo+Pj4+ IEZpcmV3YWxsIHRyYXZlcnNhbCBpcyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGJlYXN0Lg0KPj4+ IA0KPj4+IE5vdCByZWFsbHkuIFRoZXJlIGFyZSBhbHdheXMgZmlyZXdhbGwgZnVuY3Rpb25zIGlu Y2x1ZGVkIGluICJhIE5BVCIgKGUuZy4NCj4+PiBvcGVuIGZvciB0cmFmZmljIGZyb20gaW5zaWRl IHRvIG91dHNpZGUgYW5kIHlvdSBjYW4gdGhlbiBnZXQgdHJhZmZpYyBiYWNrDQo+Pj4gdGhlIHNh bWUgcGF0aCAtIHdpdGggc29tZSB0aW1lb3V0KSwgZXZlbiBpZiB0aGUgUkZDcyBvbmx5IGNhbGwg dGhlIGJveCAiYQ0KPj4+IE5BVCIuIEkgcHJlZmVyIHRvIHNheSBOQVQvRmlyZXdhbGwuDQo+PiAN Cj4+IFlvdSdyZSBmb2N1c2luZyBvbiB0aGUgdGVjaG5pY2FsIGFzcGVjdC4gVGhlIGRpZmZlcmVu Y2UgSSdtIGNvbnNpZGVyaW5nDQo+PiBpcyBub3QgdGVjaG5pY2FsLg0KPj4gDQo+PiBOQVQgdHJh dmVyc2FsIGlzIHBlcmZvcm1lZCB3aXRoIHRoZSBhZ3JlZW1lbnQgb2YgZXZlcnlvbmUgaW52b2x2 ZWQsDQo+PiB3aGVyZWFzIGZpcmV3YWxsIHRyYXZlcnNhbCBpcyBhIGJhdHRsZSBiZXR3ZWVuIHRo ZSBjbGllbnQgaW1wbGVtZW50ZXINCj4+IGFuZCB0aGUgZmlyZXdhbGwgYWRtaW5pc3RyYXRvci4g VGhlcmUncyBhbHNvIGEgcG90ZW50aWFsIGFybXMgcmFjZToNCj4+IGZpcmV3YWxscyB3aWxsIGV2 b2x2ZSB3aXRoIHRoZSBhYmlsaXR5IHRvIGJsb2NrIHdoYXRldmVyIHdlIHN0YW5kYXJkaXplLA0K Pj4gc28gd2Ugd2lsbCBuZWVkIGEgbmV3ZXIgdHJhdmVyc2FsIG1ldGhvZCwgd2hpY2ggZmlyZXdh bGxzIHdpbGwgZW5kIHVwDQo+PiBibG9ja2luZyBhcyB3ZWxsLCBldGMuIGV0Yy4gZXRjLiBXZSBk b24ndCB3YW50IHRvIHBsYXkgdGhhdCBnYW1lLg0KPj4gDQo+PiBOQVQgdHJhdmVyc2FsOiBvaw0K Pj4gRmlyZXdhbGwgdHJhdmVyc2FsOiBub3QgZm9yIHRoZSBJRVRGDQo+PiANCj4+IFNpbW9uDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRj d2ViIG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From oej@edvina.net Fri May 24 01:05:10 2013 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 9955921F87D1; Fri, 24 May 2013 01:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUEG0PPw7WmK; Fri, 24 May 2013 01:05:09 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1921F89EB; Fri, 24 May 2013 01:05:06 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4EBD593C2A1; Fri, 24 May 2013 08:05:03 +0000 (UTC) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> Date: Fri, 24 May 2013 10:05:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <152D6DF0-A795-4D83-B35B-9CC2DD2EFEDF@edvina.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> To: "Chenxin (Xin)" X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 08:05:10 -0000 I do agree with SImon here. Firewall traversal in the sense "let's = bypass the firewall admin policys" is not something for the IETF, Why not focus on discussing best behaviour for firewalls, so we don't = end up in the mess we have in SIP with most firewalls breaking communication. We also have huge problems with = firewall/CPE/routers that are starting to implement broken SIP application layer gateways. Maybe "run a TURN server on the firewall" is a good recommendation to = start with. /O 24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" = : > I agree that we should not try to battle with network administrator, = and we are not doing that. We just supply some technical tools to rtcweb = implementer, to make the users could get benefit and convenience when = using rtcweb. Fallback methods and proposals are for this purpose. We = could not decide that how will a kind of technique be used. Every = technique could be used in a good way and a bad way. I believe that = rtcweb is a good and trustworthy technique which is different with the = some harmful things which should be blocked by the administers. So let = us back to the technical aspect: should we need to support a fallback = method in rtcweb now? Which one should we support to MTI? Which one = should we support to be a option? I think now there is three method to = solve the fallback requirement=A3=BATURN/TLS, HTTP channel , TURN/WS or = HTTP. I am willing to write a mail these days to make a simple = conclusion and comparison between these methods, which will provide a = material to WG for future discussion and decision. >=20 > Best Regards, > Xin=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of >> Simon Perreault >> Sent: Wednesday, May 22, 2013 5:31 PM >> To: Karl Stahl >> Cc: rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = for >> draft-chenxin-behave-turn-websocket-00.txt >>=20 >> Le 2013-05-22 11:04, Karl Stahl a =A8=A6crit : >>>> Firewall traversal is a completely different beast. >>>=20 >>> Not really. There are always firewall functions included in "a NAT" = (e.g. >>> open for traffic from inside to outside and you can then get traffic = back >>> the same path - with some timeout), even if the RFCs only call the = box "a >>> NAT". I prefer to say NAT/Firewall. >>=20 >> You're focusing on the technical aspect. The difference I'm = considering >> is not technical. >>=20 >> NAT traversal is performed with the agreement of everyone involved, >> whereas firewall traversal is a battle between the client implementer >> and the firewall administrator. There's also a potential arms race: >> firewalls will evolve with the ability to block whatever we = standardize, >> so we will need a newer traversal method, which firewalls will end up >> blocking as well, etc. etc. etc. We don't want to play that game. >>=20 >> NAT traversal: ok >> Firewall traversal: not for the IETF >>=20 >> Simon >> _______________________________________________ >> 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 karl.stahl@intertex.se Fri May 24 01:51:35 2013 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 E97F221F91B8; Fri, 24 May 2013 01:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXOroNTqMu4u; Fri, 24 May 2013 01:51:30 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 57D4321F93DA; Fri, 24 May 2013 01:51:24 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305241051070962; Fri, 24 May 2013 10:51:07 +0200 From: "Karl Stahl" To: "'Hutton, Andrew'" , "'Simon Perreault'" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net> Date: Fri, 24 May 2013 10:51:05 +0200 Message-ID: <02ca01ce585b$d3eff630$7bcfe290$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOVs8PvK/QKOM3AUmVgv4HMJ4KjZkSvTfQgAEufLA= Content-Language: sv Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 08:51:35 -0000 I read the two drafts referenced. http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 0=20 looks OK both regarding not fighting firewall restrictions, and not introducing quality degradation. The enterprise use case with a restrictive firewall not allowing UDP to = the Internet is described under 4.2.5.1 and suggests the use of a local TURN server on the LAN that "enabling cases where peers are both on the = internal side to connect without the traffic leaving the internal network." I don't = see that it pin points how rtcweb outside LAN - to the Internet - would = happen, but an additional firewall/router could be added between the LAN TURN = server and the Internet to handle that.=20 That would result in a separate pipe for rtcweb media - that the network administer himself arranges! And he has even the possibility to arrange better quality (prioritizing etc.) on that pipe than via the ordinary firewall where rtcweb remains blocked. Both http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-0 0 and=20 http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-00.txt=20 describe ways of tunneling RTP traffic trough HTTP(S) TCP ports 80(443) = that are open in the firewall for surfing usage.=20 Whether that tunneling has an extra framing from TURN/TCP, TURN/TLS or = WS, does not affect the discussion about trying to get rtcweb media through = a firewall that is configured to only allow surfing. All of these fallbacks also results in RTP over TCP (instead of UDP as usual) and therefore degrades quality due to the error correcting retransmission. There is no way around that. (I believe the TURN/TLS is = only TCP half of the way - between the client and TURN server, but the = firewall being penetrated is often also the congestion point - so not much improvement quality wise.)=20 So, even if pushing RTC through the surf ports would not be considered fighting the firewall restriction (How could it?), do we really want a quality degraded fallback channel for rtcweb anyway? I'd say we should encourage better quality networks to really step up from POTS quality = voice now that we have chance. /Karl -----Ursprungligt meddelande----- Fr=E5n: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Skickat: den 23 maj 2013 15:09 Till: Simon Perreault; Karl Stahl Kopia: rtcweb@ietf.org; behave@ietf.org =C4mne: RE: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt At least with regard to draft-hutton-rtcweb-nat-firewall-considerations = we are not attempting to enter or add to any existing arms race between = clients and firewalls. We are only describing how to use existing IETF protocols which already extensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet = the RTCWEB requirements in this area which have existed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 0 for almost two years now. Of course if a network administer wants to block RTCWEB media they = should be able to so and nobody is I believe suggesting that we try to prevent = this. Regards Andy > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 > Behalf Of Simon Perreault > Sent: 22 May 2013 10:31 > To: Karl Stahl > Cc: rtcweb@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification=20 > for draft-chenxin-behave-turn-websocket-00.txt >=20 > Le 2013-05-22 11:04, Karl Stahl a =E9crit : > >> Firewall traversal is a completely different beast. > > > > Not really. There are always firewall functions included in "a NAT" > (e.g. > > open for traffic from inside to outside and you can then get traffic > back > > the same path - with some timeout), even if the RFCs only call the > box "a > > NAT". I prefer to say NAT/Firewall. >=20 > You're focusing on the technical aspect. The difference I'm=20 > considering is not technical. >=20 > NAT traversal is performed with the agreement of everyone involved,=20 > whereas firewall traversal is a battle between the client implementer=20 > and the firewall administrator. There's also a potential arms race: > firewalls will evolve with the ability to block whatever we=20 > standardize, so we will need a newer traversal method, which firewalls = > will end up blocking as well, etc. etc. etc. We don't want to play=20 > that game. >=20 > NAT traversal: ok > Firewall traversal: not for the IETF >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From karl.stahl@intertex.se Fri May 24 01:58:45 2013 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 68C0F21F967F; Fri, 24 May 2013 01:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntDo-g0iolCJ; Fri, 24 May 2013 01:58:40 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24E21F9676; Fri, 24 May 2013 01:58:39 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305241058222555; Fri, 24 May 2013 10:58:22 +0200 From: "Karl Stahl" To: "'Chenxin \(Xin\)'" , "'Simon Perreault'" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> Date: Fri, 24 May 2013 10:58:20 +0200 Message-ID: <02cb01ce585c$d70aae40$85200ac0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOVs8m6PhKpPzBWESvuGMiUrIKUZkTliFQgABzLfA= Content-Language: sv Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 08:58:45 -0000 Leaving my quality concern of a such fallback channel for a moment... How do you mean that tunneling rtcweb media through a firewall that is = configured to only allow surfing is not to "battle with network = administrator"? Isn't it exactly just that, whatever technique we chose to it with? /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]=20 Skickat: den 24 maj 2013 04:26 Till: Simon Perreault; Karl Stahl Kopia: rtcweb@ietf.org; behave@ietf.org =C3=84mne: RE: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = for draft-chenxin-behave-turn-websocket-00.txt I agree that we should not try to battle with network administrator, = and we are not doing that. We just supply some technical tools to rtcweb = implementer, to make the users could get benefit and convenience when = using rtcweb. Fallback methods and proposals are for this purpose. We = could not decide that how will a kind of technique be used. Every = technique could be used in a good way and a bad way. I believe that = rtcweb is a good and trustworthy technique which is different with the = some harmful things which should be blocked by the administers. So let = us back to the technical aspect: should we need to support a fallback = method in rtcweb now? Which one should we support to MTI? Which one = should we support to be a option? I think now there is three method to = solve the fallback requirement=EF=BC=9ATURN/TLS, HTTP channel , TURN/WS = or HTTP. I am willing to write a mail these days to make a simple = conclusion and comparison between these methods, which will provide a = material to WG for future discussion and decision. Best Regards, Xin=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of Simon Perreault >Sent: Wednesday, May 22, 2013 5:31 PM >To: Karl Stahl >Cc: rtcweb@ietf.org; behave@ietf.org >Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification=20 >for draft-chenxin-behave-turn-websocket-00.txt > >Le 2013-05-22 11:04, Karl Stahl a =C3=A9crit : >>> Firewall traversal is a completely different beast. >> >> Not really. There are always firewall functions included in "a NAT" = (e.g. >> open for traffic from inside to outside and you can then get traffic=20 >> back the same path - with some timeout), even if the RFCs only call=20 >> the box "a NAT". I prefer to say NAT/Firewall. > >You're focusing on the technical aspect. The difference I'm considering = >is not technical. > >NAT traversal is performed with the agreement of everyone involved,=20 >whereas firewall traversal is a battle between the client implementer=20 >and the firewall administrator. There's also a potential arms race: >firewalls will evolve with the ability to block whatever we=20 >standardize, so we will need a newer traversal method, which firewalls=20 >will end up blocking as well, etc. etc. etc. We don't want to play that = game. > >NAT traversal: ok >Firewall traversal: not for the IETF > >Simon >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From karl.stahl@intertex.se Fri May 24 02:07:18 2013 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 7BB5421F95E9; Fri, 24 May 2013 02:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igHE1BYhAZ4y; Fri, 24 May 2013 02:07:13 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 280EF21F95A0; Fri, 24 May 2013 02:07:12 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305241106574163; Fri, 24 May 2013 11:06:57 +0200 From: "Karl Stahl" To: "'Olle E. Johansson'" , "'Chenxin \(Xin\)'" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> <152D6DF0-A795-4D83-B35B-9CC2DD2EFEDF@edvina.net> In-Reply-To: <152D6DF0-A795-4D83-B35B-9CC2DD2EFEDF@edvina.net> Date: Fri, 24 May 2013 11:06:56 +0200 Message-ID: <02cc01ce585e$0a778c20$1f66a460$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5YVWbFzUJU+Oo+T5OV79XHpFvSegAB3NOA Content-Language: sv Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 09:07:18 -0000 > Maybe "run a TURN server on the firewall" is a good recommendation to = start with. That would include be the combination of the LAN TURN server and the = additional firewall/router I just mentioned in another response: "http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-= 10 looks OK both regarding not fighting firewall restrictions, and not = introducing quality degradation. The enterprise use case with a restrictive firewall not allowing UDP to = the Internet is described under 4.2.5.1 and suggests the use of a local = TURN server on the LAN that "enabling cases where peers are both on the = internal side to connect without the traffic leaving the internal = network." I don't see that it pin points how rtcweb outside LAN - to the = Internet - would happen, but an additional firewall/router could be = added between the LAN TURN server and the Internet to handle that." And it has the potential to add quality rather than degenerate it. /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: Olle E. Johansson [mailto:oej@edvina.net]=20 Skickat: den 24 maj 2013 10:05 Till: Chenxin (Xin) Kopia: Olle E. Johansson; Simon Perreault; Karl Stahl; behave@ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = for draft-chenxin-behave-turn-websocket-00.txt I do agree with SImon here. Firewall traversal in the sense "let's = bypass the firewall admin policys" is not something for the IETF, Why not focus on discussing best behaviour for firewalls, so we don't = end up in the mess we have in SIP with most firewalls breaking = communication. We also have huge problems with firewall/CPE/routers that = are starting to implement broken SIP application layer gateways. Maybe "run a TURN server on the firewall" is a good recommendation to = start with. /O 24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" = : > I agree that we should not try to battle with network administrator, = and we are not doing that. We just supply some technical tools to rtcweb = implementer, to make the users could get benefit and convenience when = using rtcweb. Fallback methods and proposals are for this purpose. We = could not decide that how will a kind of technique be used. Every = technique could be used in a good way and a bad way. I believe that = rtcweb is a good and trustworthy technique which is different with the = some harmful things which should be blocked by the administers. So let = us back to the technical aspect: should we need to support a fallback = method in rtcweb now? Which one should we support to MTI? Which one = should we support to be a option? I think now there is three method to = solve the fallback requirement=EF=BC=9ATURN/TLS, HTTP channel , TURN/WS = or HTTP. I am willing to write a mail these days to make a simple = conclusion and comparison between these methods, which will provide a = material to WG for future discussion and decision. >=20 > Best Regards, > Xin >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Simon Perreault >> Sent: Wednesday, May 22, 2013 5:31 PM >> To: Karl Stahl >> Cc: rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = >> for draft-chenxin-behave-turn-websocket-00.txt >>=20 >> Le 2013-05-22 11:04, Karl Stahl a =C3=A9crit : >>>> Firewall traversal is a completely different beast. >>>=20 >>> Not really. There are always firewall functions included in "a NAT" = (e.g. >>> open for traffic from inside to outside and you can then get traffic = >>> back the same path - with some timeout), even if the RFCs only call=20 >>> the box "a NAT". I prefer to say NAT/Firewall. >>=20 >> You're focusing on the technical aspect. The difference I'm=20 >> considering is not technical. >>=20 >> NAT traversal is performed with the agreement of everyone involved,=20 >> whereas firewall traversal is a battle between the client implementer = >> and the firewall administrator. There's also a potential arms race: >> firewalls will evolve with the ability to block whatever we=20 >> standardize, so we will need a newer traversal method, which=20 >> firewalls will end up blocking as well, etc. etc. etc. We don't want = to play that game. >>=20 >> NAT traversal: ok >> Firewall traversal: not for the IETF >>=20 >> Simon >> _______________________________________________ >> 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 matthew.kaufman@skype.net Fri May 24 03:20:36 2013 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 AFECD21F962A; Fri, 24 May 2013 03:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr6qEHsq0q0X; Fri, 24 May 2013 03:20:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33C21F9397; Fri, 24 May 2013 03:20:25 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.201) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.698.0; Fri, 24 May 2013 10:20:24 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Fri, 24 May 2013 10:20:23 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.85]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Fri, 24 May 2013 10:19:59 +0000 From: "Matthew Kaufman (SKYPE)" To: Simon Perreault Thread-Topic: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVsJqpl4QZ5A+d0aC0ygnMUkR1pkUIvf7 Date: Fri, 24 May 2013 10:19:58 +0000 Message-ID: <2A495B69-DEFE-4B6B-A80D-9C2263F9106D@skype.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se>, <519C7B17.8070405@viagenie.ca> In-Reply-To: <519C7B17.8070405@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454002)(51704005)(24454002)(377424003)(77982001)(81542001)(47446002)(47976001)(47736001)(56816002)(81342001)(69226001)(49866001)(50466002)(23746002)(33656001)(74706001)(4396001)(16406001)(54356001)(6806003)(54316002)(46102001)(20776003)(47776003)(74502001)(79102001)(36756003)(63696002)(74366001)(59766001)(31966008)(74876001)(80022001)(76482001)(74662001)(44976003)(50986001)(53806001)(65816001)(51856001)(56776001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 085634EFF4 Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 10:20:36 -0000 (Channeling Randy Bush for a moment)... I strongly encourage my competitors= to not engage in this battle. Matthew Kaufman (Sent from my iPhone) On May 22, 2013, at 9:00 AM, "Simon Perreault" wrote: > Le 2013-05-22 01:02, Karl Stahl a =E9crit : >> Doesn=92t the network administrator that configured the firewall have >> a legitimate right to decide what traffic should be on his network? >=20 > IMHO this is the strongest argument. >=20 > STUN/TURN/ICE have always been about NAT traversal. Firewall traversal > is a completely different beast. It implies a kind of battle between the > client and the firewall, where the client implementer is trying to be > smarter than the firewall administrator. This is a battle the IETF > should not engage in. Let the vendors play that game. >=20 > Simon > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From simon.perreault@viagenie.ca Fri May 24 04:19:48 2013 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 7DDFF21F8717; Fri, 24 May 2013 04:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n4ugHl09mBS; Fri, 24 May 2013 04:19:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1091D21F86DD; Fri, 24 May 2013 04:19:48 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2C5B8403D9; Fri, 24 May 2013 07:19:47 -0400 (EDT) Message-ID: <519F4CDF.3090005@viagenie.ca> Date: Fri, 24 May 2013 13:19:59 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se>, <519C7B17.8070405@viagenie.ca> <2A495B69-DEFE-4B6B-A80D-9C2263F9106D@skype.net> In-Reply-To: <2A495B69-DEFE-4B6B-A80D-9C2263F9106D@skype.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 11:19:48 -0000 Le 2013-05-24 12:19, Matthew Kaufman (SKYPE) a écrit : > (Channeling Randy Bush for a moment)... I strongly encourage my competitors to not engage in this battle. It's not about engaging or not, it's about standardizing. In an arms race, there no point to standardizing your weapons du jour. As a framework, ICE still allows whatever form of firewall traversal that vendors may think of. Simon > On May 22, 2013, at 9:00 AM, "Simon Perreault" wrote: > >> Le 2013-05-22 01:02, Karl Stahl a écrit : >>> Doesn’t the network administrator that configured the firewall have >>> a legitimate right to decide what traffic should be on his network? >> >> IMHO this is the strongest argument. >> >> STUN/TURN/ICE have always been about NAT traversal. Firewall traversal >> is a completely different beast. It implies a kind of battle between the >> client and the firewall, where the client implementer is trying to be >> smarter than the firewall administrator. This is a battle the IETF >> should not engage in. Let the vendors play that game. >> >> Simon >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From petithug@acm.org Fri May 24 09:02:34 2013 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 09A8C21F969D; Fri, 24 May 2013 09:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNynIe1j-gFV; Fri, 24 May 2013 09:02:33 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 824AB21F9615; Fri, 24 May 2013 09:02:32 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:2d:d9af:d9c7:dae0:e111] (unknown [IPv6:2601:9:4bc0:2d:d9af:d9c7:dae0:e111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C4FC4204BA; Fri, 24 May 2013 18:02:29 +0200 (CEST) Message-ID: <519F8F13.8020204@acm.org> Date: Fri, 24 May 2013 09:02:27 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Lorenzo Miniero References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> In-Reply-To: <20130520111522.1b7e2eb1@meetecho.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 16:02:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/20/2013 02:15 AM, Lorenzo Miniero wrote: > Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo GarcĆ­a > ha scritto: > >> I agree that TURN over websockets doesn't solve much more scenarios than >> TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over >> HTTP that aside of philosophical discussions would be the solution with >> better success rate? Otherwise we will have to continue answering for >> another 10 years "why is this app not working if skype does". >> >> Something like this draft sent some months ago but perhaps for TURN >> instead of direct connections: >> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >> > > > When I submitted that draft this summer, I had that exact purpose in mind, > that is taking care of corner edge cases like restrictive proxies and the > like. Of course it was not meant to be a solution, just a way to foster > discussion in that direction. In that discussion I also mentioned some work > we did about this in the past, which in part apparently ended up in > draft-hutton-rtcweb-nat-firewall-considerations: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html > > At the time most people in the ML thought it was either too useless, too > complex or even harmful, considering it could be considered as a "sneaky" > way to circumvent rules added by a network administrator, and so > unacceptable. Anyway, as I said back then, a solution like this doesn't > have to be sneaky, and it could very well be conceived in order to be > admin-friendly rather than have a parrot and a wooden leg. About circumventing rules added by a network administrator, I do think that using TURN over Websocket or HTTP is doing in fact the opposite: It is the only way to obey the wish of the network administrator, as long as you classify Webrtc is a *web* technology and not as a VoIP technology. Think about it this way: An administrator restricting UDP but authorizing HTTP is basically saying: All web applications are fine, and Webrtc being a Web application, it should just work fine, and should not be a collateral damage of restricting UDP. So TURN over Websocket/HTTP should be a mandatory part of Webrtc. Now the administrator should also have access to tools to restrict some classes of web applications, and Webrtc should be one of these classes. But that should not be done as a side-effect of closing the UDP ports. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9 dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2 9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH 0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n 78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8 tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53 HJsMG1MkVKRwRBgLsM9S =HTew -----END PGP SIGNATURE----- From rlb@ipv.sx Fri May 24 10:52:52 2013 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 338D021F9644 for ; Fri, 24 May 2013 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI7LjUfpDSQx for ; Fri, 24 May 2013 10:52:48 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0848021F95E2 for ; Fri, 24 May 2013 10:52:47 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id k14so6384072oag.8 for ; Fri, 24 May 2013 10:52:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4/8ezoRymLgYaW5UV+BFWCV3lwZDPqbB+H8Fp3KiTyo=; b=pSvnWZLlA5QwpQ2qb2KJxMxMCRQT5wxnVa0ovusDKoPeJt/h6aKuvW+buaa52xolYD r0OEmQE92Wdn/ZDoxveOh14WQVyXNa+fikM/eObtpbB04BVHai2nYsInD1xGZYCPn3ew WTj3hapmrCzEKSkT0ZsnPPkrBGLd/k4QSqn5D87ISbp+Er3mODZt3I07sDKbZkzS0ShF K8TVSJf/Z/k61vcTbrW+R7iKFHxYPUi05aOsT/SdRcyWFKiCm1guB6/BRU+sr6EpfJb9 oxl+b9ybsu5HwsbfNb/AxtHzjFGpEFYJKeKZO+mUImmoeL5gDCLsR/ChYxIDjSzL2GpN dFlQ== MIME-Version: 1.0 X-Received: by 10.60.42.104 with SMTP id n8mr12735649oel.94.1369417967588; Fri, 24 May 2013 10:52:47 -0700 (PDT) Received: by 10.60.102.146 with HTTP; Fri, 24 May 2013 10:52:47 -0700 (PDT) X-Originating-IP: [128.89.254.202] In-Reply-To: <519F8F13.8020204@acm.org> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <519F8F13.8020204@acm.org> Date: Fri, 24 May 2013 13:52:47 -0400 Message-ID: From: Richard Barnes To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=089e0149ca5c81ec2204dd7a7752 X-Gm-Message-State: ALoCoQnbL/0MNVOJS4YS/R7hv5hgtnlRYoqyi9FJOOxq+M4Ay2TwxjiZRciNefDhrsL3fmqY6ERp Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 17:52:52 -0000 --089e0149ca5c81ec2204dd7a7752 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is probably about the appropriate point in the thread to drop in a reference to Firewall Enhancement Protocol, RFC 3093: FEP has the benefit that you don't even negotiate the connection, since it tunnels the entire IP datagram, not just the UDP part. On Fri, May 24, 2013 at 12:02 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 05/20/2013 02:15 AM, Lorenzo Miniero wrote: > > Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa > > > ha scritto: > > > >> I agree that TURN over websockets doesn't solve much more scenarios th= an > >> TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it ove= r > >> HTTP that aside of philosophical discussions would be the solution wit= h > >> better success rate? Otherwise we will have to continue answering for > >> another 10 years "why is this app not working if skype does". > >> > >> Something like this draft sent some months ago but perhaps for TURN > >> instead of direct connections: > >> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt > >> > > > > > > When I submitted that draft this summer, I had that exact purpose in > mind, > > that is taking care of corner edge cases like restrictive proxies and t= he > > like. Of course it was not meant to be a solution, just a way to foster > > discussion in that direction. In that discussion I also mentioned some > work > > we did about this in the past, which in part apparently ended up in > > draft-hutton-rtcweb-nat-firewall-considerations: > > > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html > > > > At the time most people in the ML thought it was either too useless, to= o > > complex or even harmful, considering it could be considered as a "sneak= y" > > way to circumvent rules added by a network administrator, and so > > unacceptable. Anyway, as I said back then, a solution like this doesn't > > have to be sneaky, and it could very well be conceived in order to be > > admin-friendly rather than have a parrot and a wooden leg. > > About circumventing rules added by a network administrator, I do think th= at > using TURN over Websocket or HTTP is doing in fact the opposite: It is t= he > only way to obey the wish of the network administrator, as long as you > classify Webrtc is a *web* technology and not as a VoIP technology. > > Think about it this way: An administrator restricting UDP but authorizin= g > HTTP is basically saying: All web applications are fine, and Webrtc being= a > Web application, it should just work fine, and should not be a collateral > damage of restricting UDP. So TURN over Websocket/HTTP should be a > mandatory > part of Webrtc. > > Now the administrator should also have access to tools to restrict some > classes of web applications, and Webrtc should be one of these classes. > But > that should not be done as a side-effect of closing the UDP ports. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9 > dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr > oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2 > 9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a > zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv > WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH > 0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n > 78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8 > tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe > Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw > xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53 > HJsMG1MkVKRwRBgLsM9S > =3DHTew > -----END PGP SIGNATURE----- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0149ca5c81ec2204dd7a7752 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is probably about the appropriate point in the thread= to drop in a reference to Firewall Enhancement Protocol, RFC 3093:
FEP has the benefit that you don't even negotiate the connection, = since it tunnels the entire IP datagram, not just the UDP part.
&= lt;/sarcasm>




On Fri, May 24, 2013 at 12:02 PM, Marc P= etit-Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/20/2013 02:15 AM, Lorenzo Miniero wrote:
> Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa <ggb@tokbox.com>
> ha scritto:
>
>> I agree that TURN over websockets doesn't solve much more scen= arios than
>> TURN/TLS. =A0 If trying to fix HTTP Proxy traversal why not doing = it over
>> HTTP that aside of philosophical discussions would be the solution= with
>> better success rate? =A0Otherwise we will have to continue answeri= ng for
>> another 10 years "why is this app not working if skype does&q= uot;.
>>
>> Something like this draft sent some months ago but perhaps for TUR= N
>> instead of direct connections:
>> http://tools.ietf.org/id/draft-miniero-rtcwe= b-http-fallback-00.txt
>>
>
>
> When I submitted that draft this summer, I had that exact purpose in m= ind,
> that is taking care of corner edge cases like restrictive proxies and = the
> like. Of course it was not meant to be a solution, just a way to foste= r
> discussion in that direction. In that discussion I also mentioned some= work
> we did about this in the past, which in part apparently ended up in > draft-hutton-rtcweb-nat-firewall-considerations:
>
> http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg05041.html
>
> At the time most people in the ML thought it was either too useless, t= oo
> complex or even harmful, considering it could be considered as a "= ;sneaky"
> way to circumvent rules added by a network administrator, and so
> unacceptable. Anyway, as I said back then, a solution like this doesn&= #39;t
> have to be sneaky, and it could very well be conceived in order to be<= br> > admin-friendly rather than have a parrot and a wooden leg.

About circumventing rules added by a network administrator, I do thin= k that
using TURN over Websocket or HTTP is doing in fact the opposite: =A0It is t= he
only way to obey the wish of the network administrator, as long as you
classify Webrtc is a *web* technology and not as a VoIP technology.

Think about it this way: =A0An administrator restricting UDP but authorizin= g
HTTP is basically saying: All web applications are fine, and Webrtc being a=
Web application, it should just work fine, and should not be a collateral damage of restricting UDP. =A0So TURN over Websocket/HTTP should be a manda= tory
part of Webrtc.

Now the administrator should also have access to tools to restrict some
classes of web applications, and Webrtc should be one of these classes. =A0= But
that should not be done as a side-effect of closing the UDP ports.

- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9
dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr
oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2
9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a
zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv
WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH
0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n
78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8
tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe
Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw
xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53
HJsMG1MkVKRwRBgLsM9S
=3DHTew
-----END PGP SIGNATURE-----
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e0149ca5c81ec2204dd7a7752-- From bernard_aboba@hotmail.com Fri May 24 17:18:43 2013 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 3075711E812E for ; Fri, 24 May 2013 17:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.694 X-Spam-Level: X-Spam-Status: No, score=-101.694 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osj7Id1UXWIu for ; Fri, 24 May 2013 17:18:37 -0700 (PDT) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3811E813D for ; Fri, 24 May 2013 17:18:29 -0700 (PDT) Received: from BLU403-EAS112 ([65.55.116.72]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 May 2013 17:18:29 -0700 X-EIP: [7+fJyoVBoUk1vF2WYfoA+uEo2jjBQwlH] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> <51922959.3070708@alvestrand.no> <51931EF3.7080108@jitsi.org> <51932A2B.1080700@alvestrand.no> <5193B285.8090604@jitsi.org> <519E01E8.2090403@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <519E01E8.2090403@alvestrand.no> Date: Fri, 24 May 2013 12:58:19 -0700 To: Harald Alvestrand X-OriginalArrivalTime: 25 May 2013 00:18:29.0287 (UTC) FILETIME=[61D7C370:01CE58DD] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 25 May 2013 00:18:43 -0000 On May 23, 2013, at 4:48, "Harald Alvestrand" wrote: > If we're depending on RTCP, we have to wait until the first RTCP packet ar= rives, of course. [BA] Yes. The same is also true of parameters transmitted in RTP - they shou= ld be sent first, but may not necessarily arrive in order or at all. That is= why there is no substitute for reliable signaling at call setup, and why RT= P/RTCP control is more for changes in "mid stream", where speed is a conside= ration, and loss can be tolerated. For example, if the potential simulcast/l= ayered streams are defined in SDP up front, they can be rapidly switched on a= nd off without requiring signaling. This is one potential use of RTCP pause/= resume.=20= From tireddy@cisco.com Sun May 26 22:41:23 2013 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 6203421F8FB6; Sun, 26 May 2013 22:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6luXo-QzGss; Sun, 26 May 2013 22:41:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB0121F8AD1; Sun, 26 May 2013 22:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1369633278; x=1370842878; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=QuUFA/VRgRvsztzngnMSr3CUY57wNSm4fkqoH4de4+g=; b=POrRMicWdEG+CVDxRqWU/DYwAuecgu4ABhyeThpSEuwwlhlKVLaE+Q0q rpV4qjltN2IHFvx597B+qZaMEX60rg3ygGXyrRY4Qml1VF3NMcAAxbFdg 5V22LQMqVLswVCUoyH3vgP9pymx2x9A0iBkU0m0Z+ZdaDrj2Yz54M3ZMs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoFAFbxolGtJXHB/2dsb2JhbABagwgwgzu+Sg13FnSCIwEBAQQjEUMOBgEIEQQBAQMCBh0DAgQwFAEGAQEFBQQBEggBiAQMq26RAYEmjUY+gjsyYQOYZJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,748,1363132800"; d="scan'208";a="215329775" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 27 May 2013 05:41:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4R5fHix027226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 05:41:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 27 May 2013 00:41:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" , "pcp@ietf.org" Thread-Topic: New Version Notification for draft-penno-rtcweb-pcp-00.txt Thread-Index: AQHOWPEOhCS3F73H6EewJ07BF+QMZ5kVVslw Date: Mon, 27 May 2013 05:41:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B74ABC@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [rtcweb] FW: New Version Notification for draft-penno-rtcweb-pcp-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 27 May 2013 05:41:23 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBl bm5vLXJ0Y3dlYi1wY3AtMDAgZGVzY3JpYmVzIHRoZSByZWFzb25zIGZvciBXZWJSVEMgYXBwbGlj YXRpb25zIHRvIGJlIFBDUC1hd2FyZSBhbmQgdXNlIFBDUCBhbG9uZyBzaWRlIHdpdGggU1RVTiBh bmQgVFVSTi4gIEl0IGFsc28gZXhwbGFpbnMgdGhlIGJlbmVmaXRzIGZvciBhIG5ldHdvcmsgdGhh dCBkZXBsb3kgUENQLWNvbnRyb2xsZWQgTkFUcyBhbmQgRmlyZXdhbGxzLg0KDQpjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgUmVnYXJkcywNCi0tQXV0aG9ycy4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwg TWF5IDI1LCAyMDEzIDg6MDkgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBS ZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IE1vaGFtZWQgQm91Y2FkYWlyOyBEYW4gV2luZyAoZHdp bmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBlbm5vLXJ0 Y3dlYi1wY3AtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBlbm5vLXJ0 Y3dlYi1wY3AtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJlaW5h bGRvIFBlbm5vIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l OgkgZHJhZnQtcGVubm8tcnRjd2ViLXBjcA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgUENQIENv bnNpZGVyYXRpb25zIGZvciBXZWJSVEMgVXNhZ2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTI1 DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTYNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt cGVubm8tcnRjd2ViLXBjcC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5uby1ydGN3ZWItcGNwDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbm5vLXJ0Y3dlYi1wY3AtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBtb3RpdmF0aW9ucyBm b3IgV2ViUlRDIGFwcGxpY2F0aW9ucyB0byBiZQ0KICAgUENQLWF3YXJlIGFuZCB0aGUgYmVuZWZp dHMgcHJvdmlkZWQgYnkgUENQLWNhcGFibGUgTkFUcyBhbmQNCiAgIEZpcmV3YWxscy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From andrew.hutton@siemens-enterprise.com Tue May 28 08:04:01 2013 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 10A5721F9817; Tue, 28 May 2013 08:04:01 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwSjNsIi7EKU; Tue, 28 May 2013 08:03:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2C21F9814; Tue, 28 May 2013 08:03:56 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C2AE91EB8529; Tue, 28 May 2013 17:03:55 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 28 May 2013 17:03:55 +0200 From: "Hutton, Andrew" To: Marc Petit-Huguenin , Lorenzo Miniero Thread-Topic: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOWJgguR8PhNxiQUuYi4Iujc603Jkaseag Date: Tue, 28 May 2013 15:03:54 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115B2146@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <519F8F13.8020204@acm.org> In-Reply-To: <519F8F13.8020204@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 15:04:01 -0000 T246IDI0IE1heSAyMDEzIDE3OjAyIE1hcmMgUGV0aXQtSHVndWVuaW4gV3JvdGU6DQo+IA0KPiBB Ym91dCBjaXJjdW12ZW50aW5nIHJ1bGVzIGFkZGVkIGJ5IGEgbmV0d29yayBhZG1pbmlzdHJhdG9y LCBJIGRvIHRoaW5rDQo+IHRoYXQNCj4gdXNpbmcgVFVSTiBvdmVyIFdlYnNvY2tldCBvciBIVFRQ IGlzIGRvaW5nIGluIGZhY3QgdGhlIG9wcG9zaXRlOiAgSXQgaXMNCj4gdGhlDQo+IG9ubHkgd2F5 IHRvIG9iZXkgdGhlIHdpc2ggb2YgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciwgYXMgbG9uZyBh cyB5b3UNCj4gY2xhc3NpZnkgV2VicnRjIGlzIGEgKndlYiogdGVjaG5vbG9neSBhbmQgbm90IGFz IGEgVm9JUCB0ZWNobm9sb2d5Lg0KPiANCg0KSSBjZXJ0YWlubHkgYWdyZWUgd2l0aCB0aGlzLiBX RUJSdGMgaXMgYSBuZXcgdGVjaG5vbG9neSBlbWJlZGRlZCBpbiB0aGUgYnJvd3NlciBmb3Igd2Vi IGFwcGxpY2F0aW9ucyB0byB1c2Ugc28gd2UgbmVlZCB0byBkZWZpbmUgdGhlIG1lY2hhbmlzbSB1 c2VkIGJ5IHRoZSBicm93c2VyIHRvIGhhbmRsZSBmaXJld2FsbCBzY2VuYXJpb3MgYW5kIGdpdmUg dGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdGhlIHRvb2xzIHRvIGRvIHdoYXQgdGhleSB3YW50 Lg0KDQpUaGlzIGlzIG5vdCBhYm91dCBjaXJjdW12ZW50aW5nIHJ1bGVzIGJ1dCBhYm91dCBwdXR0 aW5nIHRvb2xzIGluIHBsYWNlIHNvIHJ1bGVzIGNhbiBiZSBkZWZpbmVkIGZvciB0aGlzIG5ldyB3 ZWIgdGVjaG5vbG9neSBhbmQgd2UgbmVlZCB0byBtb3ZlIG9uIHRoaXMgb3RoZXJ3aXNlIHdlYnJ0 YyB3aWxsIGJlIHVubmVjZXNzYXJpbHkgcmVzdHJpY3RlZCBpbiB3aGVyZS9ob3cgaXQgY2FuIGJl IHVzZWQuDQoNClNvIGZhciBJIHN0aWxsIHRoaW5rIHRoZSBIVFRQIENvbm5lY3QgbWVjaGFuaXNt IGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odXR0b24tcnRj d2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0aW9ucyBpcyB0aGUgYmVzdCBvcHRpb24gYXMgaXQg cmVxdWlyZXMgb25seSBicm93c2VyIGltcGxlbWVudGF0aW9uIGFuZCBleGlzdGluZyBpbmZyYXN0 cnVjdHVyZSB0byB3b3JrLiANCg0KSG93ZXZlciBsZXQncyBkZWJhdGUgdGhlIG1lcml0cyBvZiBh bGwgc29sdXRpb25zIGFuZCBtb3ZlIHRoaXMgZm9yd2FyZC4NCg0KQW5keS4NCg0KDQo= From ff@es.aau.dk Tue May 28 10:21:29 2013 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 A57C121F9690 for ; Tue, 28 May 2013 10:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UN0PenzBqFa for ; Tue, 28 May 2013 10:21:24 -0700 (PDT) Received: from ad-exchedge02.aau.dk (ad-exchedge02.aau.dk [130.225.194.124]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8921F9588 for ; Tue, 28 May 2013 10:21:24 -0700 (PDT) Received: from AD-EXCHHUB1-1.aau.dk (172.25.14.36) by ad-exchedge02.aau.dk (130.225.194.124) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 28 May 2013 19:21:38 +0200 Received: from [192.168.2.107] (93.220.127.226) by smtp.aau.dk (172.25.14.35) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 28 May 2013 19:21:14 +0200 Message-ID: <51A4E78C.3050500@es.aau.dk> Date: Tue, 28 May 2013 19:21:16 +0200 From: Frank Fitzek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [93.220.127.226] Subject: [rtcweb] Coding for rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 17:21:29 -0000 Dear all, I attended the meeting in Orlando and heard about your activities. I was highly motivated to follow this activity closer and plan to attend again in Berlin. In our research group we are interested in P2P in combination with coding, namely network coding. I scanned the documents but could not find anything related yet. We have a network coding library and plan to integrate it to webrtc. We plan to have a running system in autumn for the Vancouver meeting. Are there any other people in this group that look into similar directions? Looking forward to start a discussion here or in Berlin. FF -- Professor Dr.-Ing. Frank H.P. Fitzek Aalborg University Head of Future Visions and Mobile Devices Niels Jernes Vej 12, room A3 208 DK-9220 Aalborg Denmark Phone:+49 173 54 829 47 or +45 9940 8678 Fax:+45 9815 1583 email:ff@es.aau.dk web:www.fitzek.net From jonathan.detchart@isae.fr Wed May 29 02:39:52 2013 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 0644A21F923B for ; Wed, 29 May 2013 02:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTr8XegTcC1l for ; Wed, 29 May 2013 02:39:47 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4908421F9234 for ; Wed, 29 May 2013 02:39:45 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id 69A6322E46C; Wed, 29 May 2013 11:39:40 +0200 (CEST) Received: from [10.33.50.24] (port-detchart.isae.fr [10.33.50.24]) by catalpa (Postfix) with ESMTP id D57E7B7D5F; Wed, 29 May 2013 11:39:43 +0200 (CEST) Message-ID: <51A5CCDB.6030601@isae.fr> Date: Wed, 29 May 2013 11:39:39 +0200 From: Jonathan DETCHART User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Frank Fitzek References: <51A4E78C.3050500@es.aau.dk> In-Reply-To: <51A4E78C.3050500@es.aau.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Coding for rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 09:39:52 -0000 Hi Frank, Glad to see ISAE is not the only company which wants to combine network coding and webrtc. As I said in Orlando, we integrated our network coding library (Tetrys) inside both VLC RTC modules. We just encapsulate RTP packets inside Tetrys packets (application layer) at the sender, and do the reverse operation at the receivers. We also work on the integration of NC in webrtc. We saw that webrtc already integrates a FEC mechanism (you can find the sources in the rtp_rtcp module). We would like to estimate if NC could improve webrtc performance. We will attend Berlin meeting and we'll be happy to discuss with you about our proposal to assess whether it is possible to converge towards compilant implementations. So, we will be happy to participate to the discussion in Berlin. Best regards, Jonathan Le 28/05/2013 19:21, Frank Fitzek a écrit : > Dear all, > > I attended the meeting in Orlando and heard about your activities. I > was highly motivated to follow this activity closer and plan to attend > again in Berlin. > > In our research group we are interested in P2P in combination with > coding, namely network coding. I scanned the documents but could not > find anything related yet. We have a network coding library and plan > to integrate it to webrtc. We plan to have a running system in autumn > for the Vancouver meeting. > > Are there any other people in this group that look into similar > directions? > > Looking forward to start a discussion here or in Berlin. > > FF > From emil@sip-communicator.org Wed May 29 11:59:40 2013 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 DE50621F9698 for ; Wed, 29 May 2013 11:59:40 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M6cELZKjUG1 for ; Wed, 29 May 2013 11:59:39 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EBB2321F9690 for ; Wed, 29 May 2013 11:59:38 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg1so5039542bkc.6 for ; Wed, 29 May 2013 11:59:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=kKQ7hPOTHGoUlVQsMiHhyHACzBEXb+ZU7Q0PTWp18G8=; b=XveOtQpV4z+iWsuOr0GoerjaqbZfR273LqgvewMbCgXvO9C04LQzCH7z3OTg2Zz/Rv Yx9/5eBmtXsumWlsFNXrDOVRjjgZFaQSpLhIZ3DzjHM5IHIOxBaCdOn5dSh/rDkGhNY/ A8XhTqmeOhmQDbXjrNZ0hGvr4ddOn7XeQhh9KwNiq3JMJwSMwbQLS3HBa+9EROV0zcM6 tMrfuGA7PttoAyTXxkVz6wOi9V6Nlhm/0MlBvV+Q0FZFMBncxiF9A/fFgm91JRwcNJ0Z 5rcHjDX2OL9j1vA1WBzKkxYlMpplufnTHxIfvbgyxsFBMzrshdg+kP8oF4hoK0xAx6jz SoRA== X-Received: by 10.204.61.71 with SMTP id s7mr994633bkh.74.1369853977680; Wed, 29 May 2013 11:59:37 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id iy11sm12559744bkb.11.2013.05.29.11.59.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 11:59:36 -0700 (PDT) Message-ID: <51A65017.4090502@jitsi.org> Date: Wed, 29 May 2013 21:59:35 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkJBkxHuSEiAMgToYGZxInNkkJBsRD4yiaZcaWcuKJiO3L0OLZWltecSLE2BnEdqq9HvUa6 Subject: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 18:59:41 -0000 Hey all, Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. The following "no plan" draft attempts to present one such approach: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. Comments are welcome! Cheers, Emil -- https://jitsi.org From ff@es.aau.dk Wed May 29 12:08:29 2013 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 0D4CC21F8D70 for ; Wed, 29 May 2013 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9v2JPQjfqjv for ; Wed, 29 May 2013 12:08:23 -0700 (PDT) Received: from ad-exchedge02.aau.dk (ad-exchedge03.aau.dk [130.225.194.128]) by ietfa.amsl.com (Postfix) with ESMTP id A27B221F9746 for ; Wed, 29 May 2013 12:08:22 -0700 (PDT) Received: from AD-EXCHHUB2-1.aau.dk (172.25.14.38) by ad-exchedge03.aau.dk (130.225.194.128) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 May 2013 21:08:13 +0200 Received: from [192.168.2.107] (93.220.68.28) by smtp.aau.dk (172.25.14.35) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 May 2013 21:08:14 +0200 Message-ID: <51A6521D.7080301@es.aau.dk> Date: Wed, 29 May 2013 21:08:13 +0200 From: Frank Fitzek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jonathan DETCHART References: <51A4E78C.3050500@es.aau.dk> <51A5CCDB.6030601@isae.fr> In-Reply-To: <51A5CCDB.6030601@isae.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [93.220.68.28] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Coding for rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 19:08:29 -0000 Jonathan, great so lets sit down and see how we can collaborate on this. Let us know when you are in Berlin as we are there for the whole period. We can sit down with Morten and see how to work towards real time support. Should we aim to present something at the rtcweb meeting to the group to talk about the coding potential? In the end it is all about running code. All the best and see you in Berlin FF On 05/29/2013 11:39 AM, Jonathan DETCHART wrote: > Hi Frank, > > Glad to see ISAE is not the only company which wants to combine > network coding and webrtc. > As I said in Orlando, we integrated our network coding library > (Tetrys) inside both VLC RTC modules. > We just encapsulate RTP packets inside Tetrys packets (application > layer) at the sender, and do the reverse operation at the receivers. > > We also work on the integration of NC in webrtc. > We saw that webrtc already integrates a FEC mechanism (you can find > the sources in the rtp_rtcp module). We would like to estimate if NC > could improve webrtc performance. > > We will attend Berlin meeting and we'll be happy to discuss with you > about our proposal to assess whether it is possible to converge > towards compilant implementations. > > So, we will be happy to participate to the discussion in Berlin. > > Best regards, > Jonathan > > Le 28/05/2013 19:21, Frank Fitzek a écrit : >> Dear all, >> >> I attended the meeting in Orlando and heard about your activities. I >> was highly motivated to follow this activity closer and plan to >> attend again in Berlin. >> >> In our research group we are interested in P2P in combination with >> coding, namely network coding. I scanned the documents but could not >> find anything related yet. We have a network coding library and plan >> to integrate it to webrtc. We plan to have a running system in autumn >> for the Vancouver meeting. >> >> Are there any other people in this group that look into similar >> directions? >> >> Looking forward to start a discussion here or in Berlin. >> >> FF >> > From mary.ietf.barnes@gmail.com Wed May 29 12:23:24 2013 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 4FE4221F9725 for ; Wed, 29 May 2013 12:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCoK5DPEPB6X for ; Wed, 29 May 2013 12:23:23 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2D35221F944C for ; Wed, 29 May 2013 12:23:23 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bv4so567470qab.12 for ; Wed, 29 May 2013 12:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rYYH/4tTFFHUrOyWfJ229/Pfbw2EVFUbixprWgOC//M=; b=KXhQ0/Tbnrt7VFelHNydo61/7T3yDwg1XEHTmQvAg8OgHa5rEhv2OWHNiNKSN5TT+o 5w02vEAX07nGLny5+4AVim057Yc7pdo8pyZL+T4ifUG1fvFfwkT6+et/3scPyyMdBqIP ilNTOfBNdTv5pOjjkPO2FEhxdhdT9qCV4nGLxYG7MVhl+VjFt00F5EDr6EeG0s1eY8FN 53pb9Y9AErrFsLm2scafFHmks9iaA2VtrRDzpAnZcBTrAfiYPW+GAJaY1EkG+vgXp9qf +VyeJ1pn13ehXIEmi+DF0R3crJaFW9X8eBAmQMC9NFXBuh0gW63jpkq1Dk3MsA1U7YGu /auA== MIME-Version: 1.0 X-Received: by 10.224.70.147 with SMTP id d19mr4346725qaj.91.1369855402535; Wed, 29 May 2013 12:23:22 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 12:23:22 -0700 (PDT) In-Reply-To: <51A65017.4090502@jitsi.org> References: <51A65017.4090502@jitsi.org> Date: Wed, 29 May 2013 14:23:22 -0500 Message-ID: From: Mary Barnes To: Emil Ivov Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 19:23:24 -0000 Personally, I really like this approach. I think it will work well for CLUE. You might also want to add a reference to XCON in section 4. The very reason we chartered XCON was because it seemed much more sensible to include more complex conferencing operations in a separate application layer protocol as opposed to overloading SIP/SDP O/A. Mary. On Wed, May 29, 2013 at 1:59 PM, Emil Ivov wrote: > Hey all, > > Based on many of the discussions that we've had here, as well as many others > that we've had offlist, it seemed like a good idea to investigate a > negotiation alternative that relies on SDP and Offer/Answer just a little > bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacies > of multi-source scenarios to application-specific signalling, with > potentially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the interoperability > requirements that concerned them can still be met with "no plan". Of course > they would have to be addressed by application-specific signalling and/or > signalling gateways. > > Comments are welcome! > > Cheers, > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pkyzivat@alum.mit.edu Wed May 29 12:57:52 2013 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 12EBE21F8F27 for ; Wed, 29 May 2013 12:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65mt+8teZc6J for ; Wed, 29 May 2013 12:57:47 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 3515821F8F28 for ; Wed, 29 May 2013 12:57:46 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta06.westchester.pa.mail.comcast.net with comcast id huxY1l0091wpRvQ56vxmNE; Wed, 29 May 2013 19:57:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id hvxm1l00K3ZTu2S3evxmMw; Wed, 29 May 2013 19:57:46 +0000 Message-ID: <51A65DB8.9060702@alum.mit.edu> Date: Wed, 29 May 2013 15:57:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> In-Reply-To: <51A65017.4090502@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369857466; bh=VrTekUqvCXC/lz8uQGEZzE0LiACmXVqHfpJbIkVWDLY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FrjRX9OA1ilyGg4BVXgqkv5yz0+Dl/BXd0qDAt4xQbCqcQxD1ta79d3pECFy6jVDg 0WE6p9WGfT3gHwEW7pfiwujcxa+ofK1L2cjSHNCotbpHlV5cmPrYsDJZ/ANxYzGEvt vBepH2sPKY+hjzPj4d5lyIiTswD5XYtkYrpX4OoqzJSjec1oIh8F2kbsulBf475PGE WSNrDKfVSEBdwa398eFXJPqxB3qAaWJb7uOPZlAo8m+/o9IkDHyAeke0DGmlv6jXIN fXvSeHUi84ehvr+beu4pu9enr0jHH0lvCnbTV975G/cOq1VsXEhVvybHEvLrmP2+ZE kku9i5s3N4b5w== Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 19:57:52 -0000 Emil, I'm going to reserve judgment on this pending further discussion. I think this *might* work for CLUE, but I want to be certain. The following statements (culled from various places in the text) leave me confused about your intent: This is exactly what the use of Offer/Answer discussed here strives to achieve. Audio/Video offers originating from WebRTC endpoints will always have a maximum of one audio and one video m= line. It will be up to applications to determine exactly how many streams they can afford to send once such a session has been established. The exact mechanism to do this is outside the scope of this document (or WebRTC in general). For the sake of interoperability this specification strongly advises against the use of multiple m= lines for a single media type. Not only would such use be meaningless to a large number of legacy endpoints but it is also likely to be mishandled by many of them and to cause unexpected behaviour. ... Whatever the reason, offerers that find they need more than the available payload type numbers, will simply need to either use a second bundle group or not use BUNDLE at all (which in the case of a single audio and a single video m= line amounts to roughly the same thing). ... I'm concerned with decomposed endpoints that can't manage all the streams on the same address/port. They will need multiple independent m-lines and/or bundle groups. Further questions: I presume that you expect bandwidth in the SDP to be an aggregate per-m-line, with application specific signaling for bandwidth at the per-RTP-stream level? Thanks, Paul On 5/29/13 2:59 PM, Emil Ivov wrote: > Hey all, > > Based on many of the discussions that we've had here, as well as many > others that we've had offlist, it seemed like a good idea to investigate > a negotiation alternative that relies on SDP and Offer/Answer just a > little bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the > intricacies of multi-source scenarios to application-specific > signalling, with potentially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the > interoperability requirements that concerned them can still be met with > "no plan". Of course they would have to be addressed by > application-specific signalling and/or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > From bernard_aboba@hotmail.com Wed May 29 13:30:41 2013 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 751F321F96B0 for ; Wed, 29 May 2013 13:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31Im19WBce9b for ; Wed, 29 May 2013 13:30:37 -0700 (PDT) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by ietfa.amsl.com (Postfix) with ESMTP id D91DE21F97AC for ; Wed, 29 May 2013 13:30:36 -0700 (PDT) Received: from BLU404-EAS183 ([65.55.116.74]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 May 2013 13:30:36 -0700 X-EIP: [mnHLlWefVDbhcEcWidGxcbxRVSn4cwHq] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Wed, 29 May 2013 13:30:33 -0700 From: Bernard Aboba To: Mary Barnes MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 29 May 2013 20:30:36.0083 (UTC) FILETIME=[600B2830:01CE5CAB] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 20:30:41 -0000 I also like it quite a bit. In particular I think it is more compatible wit= h simulcast and layered coding than Plan A or Plan B. Mary Barnes wrote: Personally=2C I really like this approach. I think it will work well for CLUE. You might also want to add a reference to XCON in section 4. The very reason we chartered XCON was because it seemed much more sensible to include more complex conferencing operations in a separate application layer protocol as opposed to overloading SIP/SDP O/A. Mary. On Wed=2C May 29=2C 2013 at 1:59 PM=2C Emil Ivov wrote: > Hey all=2C > > Based on many of the discussions that we've had here=2C as well as many o= thers > that we've had offlist=2C it seemed like a good idea to investigate a > negotiation alternative that relies on SDP and Offer/Answer just a little > bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacie= s > of multi-source scenarios to application-specific signalling=2C with > potentially a little help from RTP. > > Hopefully=2C proponents of Plans A and B would find that the interoperabi= lity > requirements that concerned them can still be met with "no plan". Of cour= se > they would have to be addressed by application-specific signalling and/or > signalling gateways. > > Comments are welcome! > > Cheers=2C > Emil > > -- > https://jitsi.org > _______________________________________________ > 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 sergio.garcia.murillo@gmail.com Wed May 29 13:56:20 2013 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 1538621F85C9 for ; Wed, 29 May 2013 13:56:20 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edMpqc2dasoE for ; Wed, 29 May 2013 13:56:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8659921F961C for ; Wed, 29 May 2013 13:55:26 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w62so6847220wes.3 for ; Wed, 29 May 2013 13:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iaMg/6wmYD1WlhN8kFrrAjsgF/NFn6Hi+To3VkkueqQ=; b=l33SOsU18WyHo22tdUHJdfFwfCbDr84rjP9gxenU5mtb5usD1xrH+9pseayl1Fqj1n d3GD3GgJBKnFHJZTJdGS3lhHDJi1tirS/DRAuiJyXy7l2r4j/GlvwV8jPO3zq2Ys4H8q 5WeRx+13Geev63vtm9yacxd38VOS3W2KdiVFSomeYW6BQdcKRsEYxGY+yp5XA4+ttLwl WaLZ3RqfNN9VGuuvcc7/LxpmcBf4gd6IGqK7UP75H0Bz3IpS0zV3Kc6TIGZPHkyMY5+8 TAGnblAOyxR9MeJEDrI7hjNGZXqep4hAVvDQpp4XQavmb8EuzO620+O5G3sW8+s9pdMC 2lrA== X-Received: by 10.180.160.206 with SMTP id xm14mr16143402wib.50.1369860923997; Wed, 29 May 2013 13:55:23 -0700 (PDT) Received: from [192.168.1.2] ([90.165.209.115]) by mx.google.com with ESMTPSA id ca19sm33744447wib.3.2013.05.29.13.55.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 13:55:22 -0700 (PDT) Message-ID: <51A66B3B.6070005@gmail.com> Date: Wed, 29 May 2013 22:55:23 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 20:56:20 -0000 Hi, I also think it is the best approach. Best regards Sergio El 29/05/2013 22:30, Bernard Aboba escribió: > I also like it quite a bit. In particular I think it is more compatible with simulcast and layered coding than Plan A or Plan B. > > Mary Barnes wrote: > > Personally, I really like this approach. I think it will work well > for CLUE. You might also want to add a reference to XCON in section 4. > The very reason we chartered XCON was because it seemed much more > sensible to include more complex conferencing operations in a separate > application layer protocol as opposed to overloading SIP/SDP O/A. > > Mary. > > On Wed, May 29, 2013 at 1:59 PM, Emil Ivov wrote: >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many others >> that we've had offlist, it seemed like a good idea to investigate a >> negotiation alternative that relies on SDP and Offer/Answer just a little >> bit less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the intricacies >> of multi-source scenarios to application-specific signalling, with >> potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the interoperability >> requirements that concerned them can still be met with "no plan". Of course >> they would have to be addressed by application-specific signalling and/or >> signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> >> -- >> https://jitsi.org >> _______________________________________________ >> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From rlb@ipv.sx Wed May 29 14:00:47 2013 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 B468C21F8E6E for ; Wed, 29 May 2013 14:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1cp9bjc7vgl for ; Wed, 29 May 2013 14:00:43 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F270721F958B for ; Wed, 29 May 2013 14:00:42 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id h10so5712149eaj.20 for ; Wed, 29 May 2013 14:00:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=e7iYBkDU2XtpXCfYjTDpzzbHSO7CTakX32OT627IcwE=; b=al3VZ9LISaJ1KWZwT/am5Sn8rN0SjHcR4V73G0UZcdxM1IAgvg2QWXxy7c/DZDZ9GP cQIqdw1m6H+ek/OWKRyrYDMfrAHHab5KC4HgR2XHTT2HS6+obHNWtv/xJ8Uc0Ed/5X+h t1gZrwZKrmuqbrtH3xfGxylQrjPbK9AlGD4RYxdKmPkqw3v720hu3b/+BC0XXOy3Uwk2 wG9zAQMeA2MaAEmXzCb9G/85n8Vl1+Pr5z4vyq5Bu74w7A3msYToHnDtnh32hygDz6Q9 3MGRurXkWmqe8oM3ITH5Hsatqb3n1qM5ldG/WTZCw9iYjq13lxzyTrxGdRathE6CXlq8 WoQA== MIME-Version: 1.0 X-Received: by 10.15.23.4 with SMTP id g4mr6431585eeu.107.1369861241995; Wed, 29 May 2013 14:00:41 -0700 (PDT) Received: by 10.14.38.199 with HTTP; Wed, 29 May 2013 14:00:41 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <51A66B3B.6070005@gmail.com> References: <51A66B3B.6070005@gmail.com> Date: Wed, 29 May 2013 17:00:41 -0400 Message-ID: From: Richard Barnes To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=089e01681c86b8c0cb04dde1ac82 X-Gm-Message-State: ALoCoQlBzkuNsdQQQNjvjW7qrcJ8bOSGPba9rfZQ668QviDI9mJjuLidjeCLXUunCJIg3gP7LWKf Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 21:00:47 -0000 --089e01681c86b8c0cb04dde1ac82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Like Paul, I'll reserve a full judgement until I've had a little more time to digest this. At first read, though, it seems like there's a lot of "magic happens here" in the draft. There's an example of how you establish a legacy-compatible stream, and an assertion that JS can do the rest. The truth of this assertion isn't obvious to me. It would be helpful if the document had an example of, say, how one might add a stream. --Richard On Wed, May 29, 2013 at 4:55 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi, > > I also think it is the best approach. > > Best regards > Sergio > > El 29/05/2013 22:30, Bernard Aboba escribi=F3: > > I also like it quite a bit. In particular I think it is more compatible >> with simulcast and layered coding than Plan A or Plan B. >> >> Mary Barnes wrote: >> >> Personally, I really like this approach. I think it will work well >> for CLUE. You might also want to add a reference to XCON in section 4. >> The very reason we chartered XCON was because it seemed much more >> sensible to include more complex conferencing operations in a separate >> application layer protocol as opposed to overloading SIP/SDP O/A. >> >> Mary. >> >> On Wed, May 29, 2013 at 1:59 PM, Emil Ivov wrote: >> >>> Hey all, >>> >>> Based on many of the discussions that we've had here, as well as many >>> others >>> that we've had offlist, it seemed like a good idea to investigate a >>> negotiation alternative that relies on SDP and Offer/Answer just a litt= le >>> bit less. >>> >>> The following "no plan" draft attempts to present one such approach: >>> >>> http://tools.ietf.org/html/**draft-ivov-rtcweb-noplan >>> >>> The draft relies on conventional use of SDP O/A but leaves the >>> intricacies >>> of multi-source scenarios to application-specific signalling, with >>> potentially a little help from RTP. >>> >>> Hopefully, proponents of Plans A and B would find that the >>> interoperability >>> requirements that concerned them can still be met with "no plan". Of >>> course >>> they would have to be addressed by application-specific signalling and/= or >>> signalling gateways. >>> >>> Comments are welcome! >>> >>> Cheers, >>> Emil >>> >>> -- >>> https://jitsi.org >>> ______________________________**_________________ >>> 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 >> ______________________________**_________________ >> 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 > --089e01681c86b8c0cb04dde1ac82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Like Paul, I'll reserve a full judgement until I'v= e had a little more time to digest this. =A0At first read, though, it seems= like there's a lot of "magic happens here" in the draft. =A0= There's an example of how you establish a legacy-compatible stream, and= an assertion that JS can do the rest. =A0The truth of this assertion isn&#= 39;t obvious to me. =A0It would be helpful if the document had an example o= f, say, how one might add a stream.

--Richard


On Wed, May 29, 2013 at 4:55 PM, Sergio Garcia Muril= lo <sergio.garcia.murillo@gmail.com> wrote:
Hi,

I also think it is the best approach.

Best regards
Sergio

El 29/05/2013 22:30, Bernard Aboba escribi=F3:

I also like it quite a bit. In particular I think it is more compatible wit= h simulcast and layered coding than Plan A or Plan B.

Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Personally, I really like this approach. =A0I think it will work well
for CLUE. You might also want to add a reference to XCON in section 4.
=A0 =A0The very reason we chartered XCON was because it seemed much more sensible to include more complex conferencing operations in a separate
application layer protocol as opposed to overloading SIP/SDP O/A.

Mary.

On Wed, May 29, 2013 at 1:59 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey all,

Based on many of the discussions that we've had here, as well as many o= thers
that we've had offlist, it seemed like a good idea to investigate a
negotiation alternative that relies on SDP and Offer/Answer just a little bit less.

The following "no plan" draft attempts to present one such approa= ch:

http://tools.ietf.org/html/draft-ivov-rtcweb-noplan

The draft relies on conventional use of SDP O/A but leaves the intricacies<= br> of multi-source scenarios to application-specific signalling, with
potentially a little help from RTP.

Hopefully, proponents of Plans A and B would find that the interoperability=
requirements that concerned them can still be met with "no plan".= Of course
they would have to be addressed by application-specific signalling and/or signalling gateways.

Comments are welcome!

Cheers,
Emil

--
https://jitsi.org
_______________________________________________
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
_______________________________________________
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

--089e01681c86b8c0cb04dde1ac82-- From stpeter@stpeter.im Wed May 29 14:15:51 2013 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 4DA4121F8CF4 for ; Wed, 29 May 2013 14:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpF59r7KBtoN for ; Wed, 29 May 2013 14:15:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3B24B21F882A for ; Wed, 29 May 2013 14:15:46 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A160D411D6; Wed, 29 May 2013 15:28:34 -0600 (MDT) Message-ID: <51A66FFF.9050905@stpeter.im> Date: Wed, 29 May 2013 15:15:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Barnes References: <51A66B3B.6070005@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 21:15:51 -0000 On 5/29/13 3:00 PM, Richard Barnes wrote: > Like Paul, I'll reserve a full judgement until I've had a little more > time to digest this. At first read, though, it seems like there's a lot > of "magic happens here" in the draft. As Alan Lakein used to say: "Failing to plan is planning to fail." Hopefully that's not true of the "No Plan Plan" for RTCWEB. :-) Peter -- Peter Saint-Andre https://stpeter.im/ From fandreas@cisco.com Wed May 29 14:21:22 2013 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 E6A3821F941F for ; Wed, 29 May 2013 14:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sie2DRxaoFkr for ; Wed, 29 May 2013 14:21:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CB51421F971B for ; Wed, 29 May 2013 14:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5611; q=dns/txt; s=iport; t=1369862473; x=1371072073; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=SoVzbXPFEbpl5b0XMIJr+Oh+gLG8SajGg5/cjw8RYLA=; b=HdVwgJTifnmR6m8k3sQCrjZ3kGGhKROItrlNI28+3ybhRastX3VBaKP5 waS/cqFFjMvNuzpVF9bDiQH4yuyY9hBzS7MTI147ZZAq55KkEG8NoO1Rj J959vBLwxFq+UrLCsegaco39aDmTtfBcF7mGRsOcXK1MMIDk2v+0H6B6M U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUJAG1vplGtJXG9/2dsb2JhbABagwkwiRm4a4EKFm0HgiMBAQEEAQEBawoNBBwDAQIKFg8JAwIBAgEVJgIIBg0GAgEBBYgEDLl7jwIYBoNRA5c7kUCDKyA X-IronPort-AV: E=Sophos;i="4.87,766,1363132800"; d="scan'208,217";a="216531991" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 29 May 2013 21:21:11 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4TLLBRZ015559 for ; Wed, 29 May 2013 21:21:11 GMT Message-ID: <51A67147.1010308@cisco.com> Date: Wed, 29 May 2013 17:21:11 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <51A6700B.40108@cisco.com> In-Reply-To: <51A6700B.40108@cisco.com> X-Forwarded-Message-Id: <51A6700B.40108@cisco.com> Content-Type: multipart/alternative; boundary="------------040002070204050807050405" Subject: [rtcweb] Fwd: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 21:21:22 -0000 This is a multi-part message in MIME format. --------------040002070204050807050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 Date: Wed, 29 May 2013 17:15:55 -0400 From: Flemming Andreasen To: IETF Announcement List CC: mmusic Greetings This is to announce a(nother) virtual interim meeting for the MMUSIC Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: Per our previous interim meeting announcement, we tried to schedule a longer and in-person physical interim meeting, however it has proven impossible to find a set of dates where we could get critical mass for such a meeting. Scheduling even a virtual interim before the Berlin IETF has been surprisingly difficult with the above date being the only viable option at this point. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------040002070204050807050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI


-------- Original Message --------
Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013
Date: Wed, 29 May 2013 17:15:55 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: mmusic <mmusic@ietf.org> 


Greetings

This is to announce a(nother) virtual interim meeting for the MMUSIC Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am
Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed
by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt

You may also want to look at
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt


Thanks

-- Ari & Flemming (MMUSIC co-chairs)


PS: Per our previous interim meeting announcement, we tried to schedule a longer and in-person physical interim meeting, however it has proven impossible to find a set of dates where we could get critical mass for such a meeting. Scheduling even a virtual interim before the Berlin IETF has been surprisingly difficult with the above date being the only viable option at this point.

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


--------------040002070204050807050405-- From martin.thomson@gmail.com Wed May 29 15:17:49 2013 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 C852F21F87E0 for ; Wed, 29 May 2013 15:17:48 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfq5b0r1MSJo for ; Wed, 29 May 2013 15:17:48 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C4FB521F871D for ; Wed, 29 May 2013 15:17:47 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id er20so9239859lab.19 for ; Wed, 29 May 2013 15:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kg990NzcZC+fS7NXuJL7kTY2p7JsPnsjY3coQwOxhC8=; b=u2aB7RWiQBS3AVOufKuZ8DlrdtDXoSuFT8o8PqFJADKAEEM4XfZbX2zAyks4kJp75t RcNLrEFkzPGe/+BROSS5IAE1z2QMQspY/znkFFuOAIhW/uUikcCcUkeouF+B+4sbq0dB GKhrpqmGZ0GBFs1fxCYNEIYkjDued2DueQ1orz68/rBrkjIFtY2Zp+GIPk138h9HdPAo OeE25mRMdYPPJNat/EXeqpvd9d8wMR8s1LfFFNm+GCRcaKzThvq8XJeTHL/zf0m7vmLv EwO1+XgY/oAgCEnZffFL3HwxJXuK+5Ao0O1J0TGzRn4EPgdeHTt4HenqYI1x9jStojgq H62w== MIME-Version: 1.0 X-Received: by 10.112.146.198 with SMTP id te6mr2443305lbb.133.1369865866745; Wed, 29 May 2013 15:17:46 -0700 (PDT) Received: by 10.112.154.161 with HTTP; Wed, 29 May 2013 15:17:46 -0700 (PDT) In-Reply-To: <51A66FFF.9050905@stpeter.im> References: <51A66B3B.6070005@gmail.com> <51A66FFF.9050905@stpeter.im> Date: Wed, 29 May 2013 15:17:46 -0700 Message-ID: From: Martin Thomson To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 22:17:49 -0000 On 29 May 2013 14:15, Peter Saint-Andre wrote: > As Alan Lakein used to say: "Failing to plan is planning to fail." > Hopefully that's not true of the "No Plan Plan" for RTCWEB. :-) I hope that what Emil intends is for these other things to be addressed by expanding the WebRTC API in various ways to accommodate the use cases we've identified. There's an argument for not doing these things in SDP. It's also known as Comment 22. From stpeter@stpeter.im Wed May 29 15:48:04 2013 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 37EE521F96FC for ; Wed, 29 May 2013 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmAmCDLHmgM8 for ; Wed, 29 May 2013 15:47:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 540EC21F96A3 for ; Wed, 29 May 2013 15:47:57 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29CF0411D6; Wed, 29 May 2013 17:00:46 -0600 (MDT) Message-ID: <51A6859A.4070106@stpeter.im> Date: Wed, 29 May 2013 16:47:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <51A66B3B.6070005@gmail.com> <51A66FFF.9050905@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 22:48:04 -0000 On 5/29/13 4:17 PM, Martin Thomson wrote: > On 29 May 2013 14:15, Peter Saint-Andre wrote: >> As Alan Lakein used to say: "Failing to plan is planning to fail." >> Hopefully that's not true of the "No Plan Plan" for RTCWEB. :-) > > I hope that what Emil intends is for these other things to be > addressed by expanding the WebRTC API in various ways to accommodate > the use cases we've identified. > > There's an argument for not doing these things in SDP. It's also > known as Comment 22. Yes, agreed. I have yet to read Emil's proposal in depth, so my comment was just a general observation and not feedback on the I-D. Peter -- Peter Saint-Andre https://stpeter.im/ From prvs=38621cb7c1=christer.holmberg@ericsson.com Thu May 30 00:44:30 2013 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 AFD9D21F96FF for ; Thu, 30 May 2013 00:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjJ1WMjvHP5X for ; Thu, 30 May 2013 00:44:26 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8727B21F96B8 for ; Thu, 30 May 2013 00:44:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-09-51a703581302 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.69.15700.85307A15; Thu, 30 May 2013 09:44:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Thu, 30 May 2013 09:44:24 +0200 From: Christer Holmberg To: Emil Ivov , "rtcweb@ietf.org" Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkdWAeQ Date: Thu, 30 May 2013 07:44:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> In-Reply-To: <51A65017.4090502@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrW4E8/JAg9//9CzW7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIritklKLCkLzkzP07dL4M64vOk0W8EGwYrf57+zNzB283UxcnJICJhI THx0jw3CFpO4cG89kM3FISRwmFHix5p2JghnCaPEpJ/TGbsYOTjYBCwkuv9pgzSICLhInF// gx3EFhaQldgyeQYTRFxO4vrPfWwQtpHE6WlbmUFsFgFViTXXJ4HV8Ar4SvT332UBsYUENCRW /1jMDjKeU0BTYt82RpAwI9A930+tAStnFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCtIqIaAo sbxfDqJcR2LB7k9sELa2xLKFr5khtgpKnJz5hGUCo+gsJFNnIWmZhaRlFpKWBYwsqxjZcxMz c9LLDTcxAuPg4JbfujsYT50TOcQozcGiJM6rx7s4UEggPbEkNTs1tSC1KL6oNCe1+BAjEwcn iOCSamD0epDN9PpzjJys65Vn2zc2/1ijuHr5o7ogF+srNq4H4uWr1q/89vTrSXvB0jMsEbJ6 y1oDF25Rmv43hLn9wYS01yYfPh9rbIg0btyW1xXk8OhA2LFVz/emaR7Yp/11R2HX5H2eRX5p Jde/frNxl9xqnbSusWzyzLOfNBvDV8+9KD3teOD8Y/2XlViKMxINtZiLihMBMvnA21YCAAA= Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 07:44:30 -0000 Hi Emil, The draft says: "For the sake of interoperability this specification strongly advises against the use of multiple m=3D lines for a single media type." My understanding is that the usage of multiple m=3D lines for a single medi= a type would not affect the mechanism as such, but I just want to verify th= at :) Also, there ARE "legacy" implementations that use multiple m=3D lines for a= single media type (e.g. video enabled devices using two video m=3D lines: = one for camera content, and one for slides). So, while I definitely think that legacy interoperability shall be taken in= to consideration, I would not like to make such strong statements. In my op= inion (the draft also talks about it), the usage of multiple simultaneous S= SRCs per m- line is a much bigger issue when it comes to legacy interoperab= ility. Also, in CLUE we have been working on signaling scenarios with multiple m= =3D lines per media type. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Emil Ivov Sent: 29. toukokuuta 2013 22:00 To: rtcweb@ietf.org Subject: [rtcweb] No Plan Hey all, Based on many of the discussions that we've had here, as well as many other= s that we've had offlist, it seemed like a good idea to investigate a negot= iation alternative that relies on SDP and Offer/Answer just a little bit le= ss. The following "no plan" draft attempts to present one such approach: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan The draft relies on conventional use of SDP O/A but leaves the intricacies = of multi-source scenarios to application-specific signalling, with potentia= lly a little help from RTP. Hopefully, proponents of Plans A and B would find that the interoperability= requirements that concerned them can still be met with "no plan". Of cours= e they would have to be addressed by application-specific signalling and/or= signalling gateways. Comments are welcome! Cheers, Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From prvs=7862ec38f4=stefan.lk.hakansson@ericsson.com Thu May 30 01:24:37 2013 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 9A24921F9726 for ; Thu, 30 May 2013 01:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21z+R4VuxUzE for ; Thu, 30 May 2013 01:24:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EBA4121F972C for ; Thu, 30 May 2013 01:24:30 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-bd-51a70cbd9f24 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 19.25.09795.DBC07A15; Thu, 30 May 2013 10:24:29 +0200 (CEST) Received: from [150.132.141.62] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 30 May 2013 10:24:29 +0200 Message-ID: <51A70CBC.5010108@ericsson.com> Date: Thu, 30 May 2013 10:24:28 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> In-Reply-To: <51A65017.4090502@jitsi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJMWRmVeSWpSXmKPExsUyM+Jvre5enuWBBgfuy1ms/dfO7sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7owPb78wFRwWqZj/6xRrA+NmgS5GTg4JAROJKxPmskLYYhIX 7q1n62Lk4hASOMUoceP6cyYIZw2jxKwPvWBVvALaEo92nWACsVkEVCV6zj4Cs9kEAiWu//8F ZosKREnMWfeADaJeUOLkzCcsILaIgLDE1le9YDXCArIS167PAKsREtCQWP1jMXsXIwcHp4Cm xL5tjCBhZgFbiQtzrrNA2PIS29/OYYYo15V49/oe6wRGgVlINsxC0jILScsCRuZVjOy5iZk5 6eXmmxiBgXZwy2+DHYyb7osdYpTmYFES59XnXRwoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNE cEk1MAo1l1SyB69codSU4u7uGK/gp3R2Spji5Iy2ldMma7xnLa78pMQhbNueuKHdXnL9cc6/ gltZliz37yzZYbXvcDtDnK2qdUzoTVP7D1+VqoVlLkWrn093fHO7cOUpPzVTbksXUYGZx7k3 /4j/EPfkZApfnsrHTU1FrPeqOeNnR6T39FkLzpmixFKckWioxVxUnAgArguNlwcCAAA= Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 08:24:38 -0000 Hi Emil, a couple of comments: "1. Expose the SSRCs of all local MediaStreamTrack-s that the application may want to attach to a PeerConnection." I don't think that would be possible, or desirable. SSRC _only_ come into play when a MediaStreamTrack is to be transported over the network - it is useless in local cases. And, the same local MediaStreamTrack could be sent to several peers (using different PeerConnections) and could have different SSRC's (and even different number of SSRC's) for the different peers. I think SSRCs would only be available for MediaStreamTracks that are attached to a PeerConnection. One thing I like about Plan A and B is that the naive application developer does not have to deal with things below MediaStream and MediaStreamTrack level. The application would simply add a MediaStream (containing MediaStreamTracks) to the PeerConnection, do the createOffer/setLocal and exchange signaling blobs that it need not look into, and the MediaStream with MediaStreamTrack's would be reflected at the remote end. The application would not have to deal with PT's, SSRC's etc. I think that the "No Plan" proposal could be made similar if the info about how MediaStreamTrack's relate to SSRC's (including those for FEC and RTX) is exchanged using some blobs that the (naive) app can just exchange and need not look into. If done that way, "No Plan" seems to me to be quite similar to Plan B, with the difference being that the info about how SSRC's relate to MediaStreamTrack's is exchanged not in the core SDP but in separate messages. This could be seen as an improvement I think. Stefan On 2013-05-29 20:59, Emil Ivov wrote: > Hey all, > > Based on many of the discussions that we've had here, as well as many > others that we've had offlist, it seemed like a good idea to investigate > a negotiation alternative that relies on SDP and Offer/Answer just a > little bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the > intricacies of multi-source scenarios to application-specific > signalling, with potentially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the > interoperability requirements that concerned them can still be met with > "no plan". Of course they would have to be addressed by > application-specific signalling and/or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > From enrico.marocco@telecomitalia.it Thu May 30 02:03:44 2013 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 5477221F980E for ; Thu, 30 May 2013 02:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1U74mUqQsbi for ; Thu, 30 May 2013 02:03:39 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0521F97A0 for ; Thu, 30 May 2013 02:03:38 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 30 May 2013 11:03:35 +0200 Received: from MacLab.local (10.229.8.26) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 30 May 2013 11:03:34 +0200 Message-ID: <51A715E6.6060703@telecomitalia.it> Date: Thu, 30 May 2013 11:03:34 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Barnes References: <51A66B3B.6070005@gmail.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020308040905050709020502" X-TI-Disclaimer: Disclaimer1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 09:03:44 -0000 --------------ms020308040905050709020502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/29/13 11:00 PM, Richard Barnes wrote: > Like Paul, I'll reserve a full judgement until I've had a little more > time to digest this. At first read, though, it seems like there's a lo= t > of "magic happens here" in the draft. There's an example of how you > establish a legacy-compatible stream, and an assertion that JS can do > the rest. The truth of this assertion isn't obvious to me. It would b= e > helpful if the document had an example of, say, how one might add a str= eam. This is how I'd do it, in a way that seems quite consistent with no-plan:= 1. sender gets the additional local tracks 2. sender tells the receiver on the app-specific signalling channel (assuming a plain-english-over-something one): "I can also send you video and audio of a webcam I've just installed in the girls locker room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved through JS API -- kind of what exists in Chrome today for stats) 3. receiver responds "Shoot!" 4. sender attaches the new tracks to the local stream attached to the existing connection 4.1. if appropriate media lines exist (i.e. with the required media type and payloads), new media will be sent there, same ports, new SSRCs or 4.2. if a new media line is required, the sender receives an event to be handled by an RTCSessionDescriptionCallback-like callback that triggers renegotiation in the usual app-specific way (AFAIK the API doesn't have such an event right now) 5. receiver gets addtrack notifications and the application will take care of their display, according to the app-specific information received on the app-specific signalling channel The most critical part here is 4.2 (i.e. additional O/A exchanges, what no-plan tries to reduce). It would probably never happen when the sender is a browser, seldom otherwise. I'm certainly not the greatest JS expert, but I don't see an easier way to achieve this. I'm also not the greatest expert of legacy RTP devices (although I deal with them every day), but I'm pretty convinced that for such non-trival scenarios some kind of gatewaying will be required anyway. The no-plan approach seems to make it easier than both plan A and plan B. Enrico --------------ms020308040905050709020502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA1MzAw OTAzMzRaMCMGCSqGSIb3DQEJBDEWBBTDqisZBLFfbPNIYG4kzbwzTXlxSjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAQAaPlFhl+69SVHqqgzDHMXq6oOmBtpLHgFHBvtKy 2vA4OH3Lf2rMl6NuwbtmZ2208vh3O8d6uEOMcD6fO0Z9Og2lEgVGOowJEjOE1S8hDcN0xDRm P9GK76+TAIlOvBadzy3+ye5V1YOfparm4Vfyq1aYlMvupV5l3q3O81KkDgzln5X4nFdlFHWw eaZE9GTs6IEgfOqoQQXXsPast7q9+KTgm4kTCONUGcBLl4p/nBtPsfdv3l3S370002QlrHLE SybtN9x213vNRasz0JQleXPhIRsSKy8T6Yp2WnXX0ByFtlHF7eHgCIDIX1+TX5yNcqQKlVHK wxtLjhKerv6MDwAAAAAAAA== --------------ms020308040905050709020502-- From bernard_aboba@hotmail.com Thu May 30 02:19:46 2013 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 C6F3221F97A0 for ; Thu, 30 May 2013 02:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDpYje28UetG for ; Thu, 30 May 2013 02:19:41 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by ietfa.amsl.com (Postfix) with ESMTP id EB53521F978B for ; Thu, 30 May 2013 02:19:40 -0700 (PDT) Received: from BLU402-EAS376 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 May 2013 02:19:40 -0700 X-EIP: [vDzF4e0aEiKPijEP5b9MKh59i7oMAi+W] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51A70CBC.5010108@ericsson.com> Date: Thu, 30 May 2013 02:19:39 -0700 To: =?utf-8?Q?Stefan_H=C3=A5kansson_LK?= X-OriginalArrivalTime: 30 May 2013 09:19:40.0298 (UTC) FILETIME=[D02396A0:01CE5D16] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 09:19:46 -0000 Q29tbWVudHMgYmVsb3cuDQoNCk9uIE1heSAzMCwgMjAxMywgYXQgMToyNCwgIlN0ZWZhbiBIw6Vr YW5zc29uIExLIiA8c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+ IEhpIEVtaWwsDQo+IA0KPiBhIGNvdXBsZSBvZiBjb21tZW50czoNCj4gDQo+ICIxLiAgRXhwb3Nl IHRoZSBTU1JDcyBvZiBhbGwgbG9jYWwgTWVkaWFTdHJlYW1UcmFjay1zIHRoYXQgdGhlDQo+ICAg ICAgIGFwcGxpY2F0aW9uIG1heSB3YW50IHRvIGF0dGFjaCB0byBhIFBlZXJDb25uZWN0aW9uLiIN Cj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhhdCB3b3VsZCBiZSBwb3NzaWJsZSwgb3IgZGVzaXJhYmxl LiBTU1JDIF9vbmx5XyBjb21lIGludG8gcGxheSB3aGVuIGEgTWVkaWFTdHJlYW1UcmFjayBpcyB0 byBiZSB0cmFuc3BvcnRlZCBvdmVyIHRoZSBuZXR3b3JrIC0gaXQgaXMgdXNlbGVzcyBpbiBsb2Nh bCBjYXNlcy4gQW5kLCB0aGUgc2FtZSBsb2NhbCBNZWRpYVN0cmVhbVRyYWNrIGNvdWxkIGJlIHNl bnQgdG8gc2V2ZXJhbCBwZWVycyAodXNpbmcgZGlmZmVyZW50IFBlZXJDb25uZWN0aW9ucykgYW5k IGNvdWxkIGhhdmUgZGlmZmVyZW50IFNTUkMncyAoYW5kIGV2ZW4gZGlmZmVyZW50IG51bWJlciBv ZiBTU1JDJ3MpIGZvciB0aGUgZGlmZmVyZW50IHBlZXJzLg0KPiANCj4gSSB0aGluayBTU1JDcyB3 b3VsZCBvbmx5IGJlIGF2YWlsYWJsZSBmb3IgTWVkaWFTdHJlYW1UcmFja3MgdGhhdCBhcmUgYXR0 YWNoZWQgdG8gYSBQZWVyQ29ubmVjdGlvbi4NCg0KW0JBXSBJZiBJQ0UgZmFpbHMsIGl0IG1heSBi ZSBuZWNlc3NhcnkgdG8gdXNlIGFsdGVybmF0aXZlIHRyYW5zcG9ydCwgb3V0c2lkZSBvZiBQZWVy Q29ubmVjdGlvbi4gU28gaWYgU1NSQ3MgYXJlIHRvIGJlIHVzZWQgaW4gc2lnbmFsaW5nIGZvciB0 aGF0IGNhc2UsIHRoZSBBUEkgbmVlZHMgdG8gbWFrZSB0aGVtIGF2YWlsYWJsZS4NCg0KPiANCg== From prvs=1862a96fff=stefan.lk.hakansson@ericsson.com Thu May 30 02:55:29 2013 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 4731B21F963A for ; Thu, 30 May 2013 02:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in+lk8iaFp1g for ; Thu, 30 May 2013 02:55:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2121F96A0 for ; Thu, 30 May 2013 02:55:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-cc-51a721f7aa5b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.B5.09795.7F127A15; Thu, 30 May 2013 11:55:03 +0200 (CEST) Received: from [150.132.141.62] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 30 May 2013 11:55:03 +0200 Message-ID: <51A721F6.6090805@ericsson.com> Date: Thu, 30 May 2013 11:55:02 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3Vve74vJAg0f/VSz2L7nMbLH2Xzu7 A5PH454zbB5LlvxkCmCK4rZJSiwpC85Mz9O3S+DOeLT+H1vBfJ6Kg59XMTUwPuLsYuTkkBAw kdg4ZwMjhC0mceHeerYuRi4OIYFTjBJXji5jhnDWMEqsmdDKBFLFK6AtcXXXP6AEBweLgKrE 4dM6IGE2gWCJ/ctBmjk5RAWiJOase8AGUS4ocXLmExaQchEBXYm/XUYgYWYBdYk7i8+xg9jC ArIS167PACsXEqiUWPppJguIzSlgK3Fg2WUmiHoLicVvDrJD2PISzVtnM0PU60q8e32PdQKj 4Cwk22YhaZmFpGUBI/MqRvbcxMyc9HLzTYzAkDy45bfBDsZN98UOMUpzsCiJ8+rzLg4UEkhP LEnNTk0tSC2KLyrNSS0+xMjEwQkiuKQaGA34Or2ldR+a/vq/SWDi1IqWhytEuNa9XObfdrb8 6NF+tYBjdpyVj1uEUgVe379kd8V8XUzEORaedTGFL84bJe5lM5m/p9T+xbL8iY57ix/xyZ/a ayoReOXkHIELlWmmU5csX1r5c9WDHtlgGzthg/Zsl+mTb1QZbrU8/yhH/ZJAmrPktU+yU5VY ijMSDbWYi4oTAQDj40IcAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 09:55:29 -0000 On 2013-05-30 11:19, Bernard Aboba wrote: > Comments below. > > On May 30, 2013, at 1:24, "Stefan HĆ„kansson LK" > wrote: > >> Hi Emil, >> >> a couple of comments: >> >> "1. Expose the SSRCs of all local MediaStreamTrack-s that the >> application may want to attach to a PeerConnection." >> >> I don't think that would be possible, or desirable. SSRC _only_ >> come into play when a MediaStreamTrack is to be transported over >> the network - it is useless in local cases. And, the same local >> MediaStreamTrack could be sent to several peers (using different >> PeerConnections) and could have different SSRC's (and even >> different number of SSRC's) for the different peers. >> >> I think SSRCs would only be available for MediaStreamTracks that >> are attached to a PeerConnection. > > [BA] If ICE fails, it may be necessary to use alternative transport, > outside of PeerConnection. So if SSRCs are to be used in signaling > for that case, the API needs to make them available. Definitely. But my point was that unless there is an intention to transport, SSRCs are useless (and they only have a meaning if there is RTP involved, right?). There are a lot of local use cases for MediaStream's (containing MediaStreamTrack's), so it does not make sense to add SSRC APIs to those objects; it belongs to PeerConnection IMO. But when (if) another transport object in JS space than PeerConnection is defined, it would also need an API where SSRCs could be accessed. Stefan > >> From michelg@upperside.fr Thu May 30 06:15:39 2013 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 2A7C321F9318 for ; Thu, 30 May 2013 06:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOM-vIX0BZaa for ; Thu, 30 May 2013 06:15:34 -0700 (PDT) Received: from smtp01.msg.oleane.net (smtp01.msg.oleane.net [62.161.4.1]) by ietfa.amsl.com (Postfix) with ESMTP id B807F21F8B27 for ; Thu, 30 May 2013 06:15:26 -0700 (PDT) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp01.msg.oleane.net (MSA) with ESMTP id r4UDFMTY008734 for ; Thu, 30 May 2013 15:15:23 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: References: <001701ce5d2b$87e6f480$97b4dd80$@upperside.fr> <005f01ce5d30$9cf8d690$d6ea83b0$@upperside.fr> In-Reply-To: <005f01ce5d30$9cf8d690$d6ea83b0$@upperside.fr> Date: Thu, 30 May 2013 15:15:22 +0200 Message-ID: <005201ce5d37$bee842c0$3cb8c840$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CE5D48.82724B40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNLMTQd2zYiT2xuxvXoL/70eHUHtAHrjdZ5lhSwNtA= Content-Language: fr X-PMX-Spam: Probability=8% X-PFSI-Info: PMX 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.130354 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [rtcweb] WebRTC Paris 2013 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 13:15:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0053_01CE5D48.82724B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The agenda of the second edition of the WebRTC Conference is online. The event will be organized in Paris Roissy from 10 to 12 December 2013. Sessions include WebRTC for service providers and enterprises as well as a large set of implementation experiences. http://www.uppersideconferences.com/webrtc2013/webrtc2013program_day1_confer ence.html ------=_NextPart_000_0053_01CE5D48.82724B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The agenda of = the second edition of the WebRTC Conference is online. The event will be = organized in Paris Roissy from 10 to 12 December = 2013.

 

Sessions = include WebRTC for service providers and enterprises as well as a large = set of implementation experiences.

 

http://www.uppersideconferences.com/webrtc2013/webrtc2013pro= gram_day1_conference.html

------=_NextPart_000_0053_01CE5D48.82724B40-- From Jonathan.DETCHART@isae.fr Thu May 30 07:34:15 2013 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 0326721F86AE for ; Thu, 30 May 2013 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7mos3JdMc2x for ; Thu, 30 May 2013 07:34:03 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9221F8E12 for ; Thu, 30 May 2013 07:33:34 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id 1649C22E427; Thu, 30 May 2013 16:33:14 +0200 (CEST) Received: from webmail.isae.fr (alisier.isae.fr [193.54.120.24]) by catalpa (Postfix) with ESMTP id BBF41B7D5F; Thu, 30 May 2013 16:33:19 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 30 May 2013 16:33:19 +0200 From: DETCHART Jonathan To: Frank Fitzek In-Reply-To: <51A6521D.7080301@es.aau.dk> References: <51A4E78C.3050500@es.aau.dk> <51A5CCDB.6030601@isae.fr> <51A6521D.7080301@es.aau.dk> Message-ID: <2b46ca92eb2774c7cf4646bf92690213@merisier.isae.fr> X-Sender: Jonathan.DETCHART@isae.fr User-Agent: Roundcube ISAE Webmail/0.7.1 Cc: =?UTF-8?Q?LACAN_J=C3=A9r=C3=B4me?= , rtcweb@ietf.org, LOCHIN Emmanuel Subject: Re: [rtcweb] Coding for rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:34:15 -0000 Sure ! I will also be in Berlin for the whole periode. I will come with my colleague Emmanuel Lochin. We can make a common presentation about the network coding and its potential benefits on webrtc. Or we can just do a small meeting between us, see how we could organize the work and show a demo for the next IETF meeting in Vancouver. It's up to you. Best regards, Jonathan Le 29.05.2013 21:08, Frank Fitzek a Ć©critĀ : > Jonathan, > > great so lets sit down and see how we can collaborate on this. Let us > know when you are in Berlin as we are there for the whole period. We > can sit down with Morten and see how to work towards real time > support. > > Should we aim to present something at the rtcweb meeting to the group > to talk about the coding potential? > > In the end it is all about running code. > > All the best and see you in Berlin > > FF > > > On 05/29/2013 11:39 AM, Jonathan DETCHART wrote: >> Hi Frank, >> >> Glad to see ISAE is not the only company which wants to combine >> network coding and webrtc. >> As I said in Orlando, we integrated our network coding library >> (Tetrys) inside both VLC RTC modules. >> We just encapsulate RTP packets inside Tetrys packets (application >> layer) at the sender, and do the reverse operation at the receivers. >> >> We also work on the integration of NC in webrtc. >> We saw that webrtc already integrates a FEC mechanism (you can find >> the sources in the rtp_rtcp module). We would like to estimate if NC >> could improve webrtc performance. >> >> We will attend Berlin meeting and we'll be happy to discuss with you >> about our proposal to assess whether it is possible to converge >> towards compilant implementations. >> >> So, we will be happy to participate to the discussion in Berlin. >> >> Best regards, >> Jonathan >> >> Le 28/05/2013 19:21, Frank Fitzek a Ć©crit : >>> Dear all, >>> >>> I attended the meeting in Orlando and heard about your activities. >>> I was highly motivated to follow this activity closer and plan to >>> attend again in Berlin. >>> >>> In our research group we are interested in P2P in combination with >>> coding, namely network coding. I scanned the documents but could not >>> find anything related yet. We have a network coding library and plan >>> to integrate it to webrtc. We plan to have a running system in autumn >>> for the Vancouver meeting. >>> >>> Are there any other people in this group that look into similar >>> directions? >>> >>> Looking forward to start a discussion here or in Berlin. >>> >>> FF >>> >> From ff@es.aau.dk Thu May 30 07:46:30 2013 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 E562F21F84E7 for ; Thu, 30 May 2013 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrpFptKHVGvH for ; Thu, 30 May 2013 07:46:23 -0700 (PDT) Received: from ad-exchedge02.aau.dk (ad-exchedge03.aau.dk [130.225.194.128]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2F21F8616 for ; Thu, 30 May 2013 07:46:23 -0700 (PDT) Received: from AD-EXCHHUB2-1.aau.dk (172.25.14.38) by ad-exchedge03.aau.dk (130.225.194.128) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 30 May 2013 16:46:18 +0200 Received: from [192.168.33.21] (87.139.237.181) by smtp.aau.dk (172.25.14.35) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 30 May 2013 16:46:18 +0200 Message-ID: <51A7663B.1020508@es.aau.dk> Date: Thu, 30 May 2013 16:46:19 +0200 From: Frank Fitzek User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: DETCHART Jonathan References: <51A4E78C.3050500@es.aau.dk> <51A5CCDB.6030601@isae.fr> <51A6521D.7080301@es.aau.dk> <2b46ca92eb2774c7cf4646bf92690213@merisier.isae.fr> In-Reply-To: <2b46ca92eb2774c7cf4646bf92690213@merisier.isae.fr> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [87.139.237.181] Cc: =?UTF-8?B?TEFDQU4gSsOpcsO0bWU=?= , rtcweb@ietf.org, LOCHIN Emmanuel Subject: Re: [rtcweb] Coding for rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:46:30 -0000 On 30.05.2013 16:33, DETCHART Jonathan wrote: > Sure ! I will also be in Berlin for the whole periode. > I will come with my colleague Emmanuel Lochin. Great so lets arrange for some meetings, I have office space here as well. I bring some of my colleagues too. > > We can make a common presentation about the network coding and its > potential benefits on webrtc. That would be awesome. > Or we can just do a small meeting between us, see how we could > organize the work and show a demo for the next IETF meeting in Vancouver. > Maybe a motivation talk in Berlin and demo in Vancouver. > It's up to you. > > Best regards, > Jonathan > > > Le 29.05.2013 21:08, Frank Fitzek a Ć©crit : >> Jonathan, >> >> great so lets sit down and see how we can collaborate on this. Let us >> know when you are in Berlin as we are there for the whole period. We >> can sit down with Morten and see how to work towards real time >> support. >> >> Should we aim to present something at the rtcweb meeting to the group >> to talk about the coding potential? >> >> In the end it is all about running code. >> >> All the best and see you in Berlin >> >> FF >> >> >> On 05/29/2013 11:39 AM, Jonathan DETCHART wrote: >>> Hi Frank, >>> >>> Glad to see ISAE is not the only company which wants to combine >>> network coding and webrtc. >>> As I said in Orlando, we integrated our network coding library >>> (Tetrys) inside both VLC RTC modules. >>> We just encapsulate RTP packets inside Tetrys packets (application >>> layer) at the sender, and do the reverse operation at the receivers. >>> >>> We also work on the integration of NC in webrtc. >>> We saw that webrtc already integrates a FEC mechanism (you can find >>> the sources in the rtp_rtcp module). We would like to estimate if NC >>> could improve webrtc performance. >>> >>> We will attend Berlin meeting and we'll be happy to discuss with you >>> about our proposal to assess whether it is possible to converge >>> towards compilant implementations. >>> >>> So, we will be happy to participate to the discussion in Berlin. >>> >>> Best regards, >>> Jonathan >>> >>> Le 28/05/2013 19:21, Frank Fitzek a Ć©crit : >>>> Dear all, >>>> >>>> I attended the meeting in Orlando and heard about your activities. >>>> I was highly motivated to follow this activity closer and plan to >>>> attend again in Berlin. >>>> >>>> In our research group we are interested in P2P in combination with >>>> coding, namely network coding. I scanned the documents but could >>>> not find anything related yet. We have a network coding library and >>>> plan to integrate it to webrtc. We plan to have a running system in >>>> autumn for the Vancouver meeting. >>>> >>>> Are there any other people in this group that look into similar >>>> directions? >>>> >>>> Looking forward to start a discussion here or in Berlin. >>>> >>>> FF >>>> >>> > -- Professor Dr.-Ing. Frank H.P. Fitzek Aalborg University Head of Future Visions and Mobile Devices Niels Jernes Vej 12, room A3 208 DK-9220 Aalborg Denmark Phone:+49 173 54 829 47 or +45 9940 8678 Fax:+45 9815 1583 email:ff@es.aau.dk web:www.fitzek.net From pkyzivat@alum.mit.edu Thu May 30 08:08:08 2013 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 06A3D21F8E41 for ; Thu, 30 May 2013 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUab+EgZ4CEL for ; Thu, 30 May 2013 08:07:55 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5AA21F9128 for ; Thu, 30 May 2013 08:07:48 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id iAkM1l0041ei1Bg58F7nYC; Thu, 30 May 2013 15:07:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id iF7n1l00R3ZTu2S3kF7nlb; Thu, 30 May 2013 15:07:47 +0000 Message-ID: <51A76B42.2000209@alum.mit.edu> Date: Thu, 30 May 2013 11:07:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> In-Reply-To: <51A70CBC.5010108@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369926467; bh=VCbJoyLTqDfnB6qHLF8uQZ0cn2+e8n7dZ1GOQPM3ooo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S1Xl8pT3ZF9gDmBw3kZJQcbX0KVHHuo/e0blrsxlzVTlkMoEN689LZzjg25rX9aAK y/RyWRoWUJLuIMep9Y6wdbX3yozfVGzXKGeI4D50q5Vaq0gdCjtokdxQ73DC9NA/IZ fjjcELw+HYpJF/9n4rF/+jOYqD0IaSQTAUaTGRYHT8WKpXSQSAsCqCg3MvXRjOZEmF sqMjzhPc1EuH4IWpzB0wxJmw8EE54y8NrKmczeg69jYzwuMgahyh6BC+1gN4DBOkGS vtzWiIqociq/ARBK5tI0sf/CNJEejR9XHXkRD60JsFhyM7LO1Ybg/+9yiDquO0zPJy SZ/EAR8PH7RYw== Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:08:08 -0000 On 5/30/13 4:24 AM, Stefan Håkansson LK wrote: > Hi Emil, > > a couple of comments: > > "1. Expose the SSRCs of all local MediaStreamTrack-s that the > application may want to attach to a PeerConnection." > > I don't think that would be possible, or desirable. SSRC _only_ come > into play when a MediaStreamTrack is to be transported over the network > - it is useless in local cases. And, the same local MediaStreamTrack > could be sent to several peers (using different PeerConnections) and > could have different SSRC's (and even different number of SSRC's) for > the different peers. > > I think SSRCs would only be available for MediaStreamTracks that are > attached to a PeerConnection. If that is true, then I think it calls for exposing to the API an object that binds MediaStreamTrack to the PeerConnection, so that there is a place to hang the SSRC attribute. Thanks, Paul > One thing I like about Plan A and B is that the naive application > developer does not have to deal with things below MediaStream and > MediaStreamTrack level. The application would simply add a MediaStream > (containing MediaStreamTracks) to the PeerConnection, do the > createOffer/setLocal and exchange signaling blobs that it need not look > into, and the MediaStream with MediaStreamTrack's would be reflected at > the remote end. The application would not have to deal with PT's, SSRC's > etc. > > I think that the "No Plan" proposal could be made similar if the info > about how MediaStreamTrack's relate to SSRC's (including those for FEC > and RTX) is exchanged using some blobs that the (naive) app can just > exchange and need not look into. > > If done that way, "No Plan" seems to me to be quite similar to Plan B, > with the difference being that the info about how SSRC's relate to > MediaStreamTrack's is exchanged not in the core SDP but in separate > messages. This could be seen as an improvement I think. > > Stefan > > > > On 2013-05-29 20:59, Emil Ivov wrote: >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many >> others that we've had offlist, it seemed like a good idea to investigate >> a negotiation alternative that relies on SDP and Offer/Answer just a >> little bit less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the >> intricacies of multi-source scenarios to application-specific >> signalling, with potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the >> interoperability requirements that concerned them can still be met with >> "no plan". Of course they would have to be addressed by >> application-specific signalling and/or signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From pkyzivat@alum.mit.edu Thu May 30 08:14:08 2013 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 D613D21F9113 for ; Thu, 30 May 2013 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quOiMxk7C3KZ for ; Thu, 30 May 2013 08:14:04 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 1265A21F8FF8 for ; Thu, 30 May 2013 08:14:03 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id iB4A1l0021vXlb85CFE3QA; Thu, 30 May 2013 15:14:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id iFE31l00X3ZTu2S3dFE38B; Thu, 30 May 2013 15:14:03 +0000 Message-ID: <51A76CBA.7030106@alum.mit.edu> Date: Thu, 30 May 2013 11:14:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A66B3B.6070005@gmail.com> <51A715E6.6060703@telecomitalia.it> In-Reply-To: <51A715E6.6060703@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369926843; bh=3n1zo8Ca9srNo7iCcrkEETweHlX30xlryRNBOgEF4Aw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ms3oOnBs2nKCEmbykoJ2mtf6fYk8Oe4vHADcIh37sBrVlMORad0xgl+bZPF95HLsm d9QTeEJyiQGl64OMzeaOWCMsbI/ThtH/DpPFovrpx2diDK8wYzHR1S18R2DB5vjHvt 34ueNnhEcTRSyWmo9Q42Laf4a8zvhDGx8xjN/bdxZ7uJnB6U1/MEZvrf7T06V4a+yO bPzTa53M0lIEdOp+kCfBRRRUw1Cm1zJ2gp/dypNsHdfWW12owodhMNxbeJFW2oFr3P mU2vs+GVdt+4CNUyPeEIjAhdnK5ZhXkWPxVfIpVpg6eL9adJTHfquCvDebxOIu0ls4 ZM449e9Da48hg== Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:14:09 -0000 On 5/30/13 5:03 AM, Enrico Marocco wrote: > On 5/29/13 11:00 PM, Richard Barnes wrote: >> Like Paul, I'll reserve a full judgement until I've had a little more >> time to digest this. At first read, though, it seems like there's a lot >> of "magic happens here" in the draft. There's an example of how you >> establish a legacy-compatible stream, and an assertion that JS can do >> the rest. The truth of this assertion isn't obvious to me. It would be >> helpful if the document had an example of, say, how one might add a stream. > > This is how I'd do it, in a way that seems quite consistent with no-plan: > > 1. sender gets the additional local tracks > > 2. sender tells the receiver on the app-specific signalling channel > (assuming a plain-english-over-something one): "I can also send you > video and audio of a webcam I've just installed in the girls locker > room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved through > JS API -- kind of what exists in Chrome today for stats) > > 3. receiver responds "Shoot!" What does the receiver say if it can use the media, but cannot receive it over the *existing* audio and video m-lines where it is receiving other media already? Thanks, Paul > 4. sender attaches the new tracks to the local stream attached to the > existing connection > > 4.1. if appropriate media lines exist (i.e. with the required > media type and payloads), new media will be sent there, > same ports, new SSRCs > > or > > 4.2. if a new media line is required, the sender receives an > event to be handled by an > RTCSessionDescriptionCallback-like callback that triggers > renegotiation in the usual app-specific way (AFAIK the API > doesn't have such an event right now) > > 5. receiver gets addtrack notifications and the application will take > care of their display, according to the app-specific information > received on the app-specific signalling channel > > The most critical part here is 4.2 (i.e. additional O/A exchanges, what > no-plan tries to reduce). It would probably never happen when the sender > is a browser, seldom otherwise. > > I'm certainly not the greatest JS expert, but I don't see an easier way > to achieve this. I'm also not the greatest expert of legacy RTP devices > (although I deal with them every day), but I'm pretty convinced that for > such non-trival scenarios some kind of gatewaying will be required > anyway. The no-plan approach seems to make it easier than both plan A > and plan B. > > Enrico > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From fluffy@cisco.com Thu May 30 08:30:07 2013 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 21B8D21F929F for ; Thu, 30 May 2013 08:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.119 X-Spam-Level: X-Spam-Status: No, score=-110.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnu-yEp-c6Kz for ; Thu, 30 May 2013 08:30:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8521F92F5 for ; Thu, 30 May 2013 08:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1674; q=dns/txt; s=iport; t=1369927791; x=1371137391; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=CKgbp4pcLJXrPhddrrPmNe+yJOGFUBkl/2DsouJQ424=; b=CCvknN3hJCVhSBgQVpDlrIw38u6uS0yIBDglu3B8aPcEmUsTPS9zMDRS QUfXHwBCqVi/lG3VvmA3odJEkZE/Nf6R4qXSjgZsf7fbEzUquB76PqIcC K22nsiWhr8xF+y41kEwTaA+qhNzVvzsgf2SMBqf+JtRmEjWjKyL4iiMKf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAG5vp1GtJXHA/2dsb2JhbAA/FwODCTDCD34WbQeCJQECAjosAhESARwOCgQGBjwkAwEDDg2IBQwyrQ2OC41aG3YhEAkPB4JeYQOofoI/UIFxNg X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216576864" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 30 May 2013 15:29:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4UFTo5W007023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 15:29:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 30 May 2013 10:29:50 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: RTCWeb Virtual Interim Meeting on SDP Security Description (SDES) Thread-Index: AQHOXUqFsvzENcyg2kG1UgmC51Y/fQ== Date: Thu, 30 May 2013 15:28:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <3DF5C3F39313994980613111DD77D818@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] RTCWeb Virtual Interim Meeting on SDP Security Description (SDES) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:30:07 -0000 We are having an Virtual Interim meeting for the IETF RTCWeb WG on the topi= c of SDP Security Descriptions (RFC 4568 aka SDES). The goal is not to make= a decision about this but is to get everyone understanding the pros and co= ns of all the options.=20 The meeting will be on Tuesday June 18th at 6:00 AM PDT meeting and will be= 2.5 hours long. Cullen, Magnus, & Ted The webex information is Topic: RTCWeb SDES=20 Date: Tuesday, June 18, 2013=20 Time: 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 206 291 561=20 Password: ietf=20 -------------------------------------------------------=20 To join the meeting online(Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D227227992&UID=3D4821= 86897&PW=3DNM2I5MTliYzU4&RT=3DMiM0 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: ietf=20 4. Click "Join".=20 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen.=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code.=20 Call-in toll-free number (US/Canada): +1-866-432-9903=20 Call-in toll number (US/Canada): +1-408-525-6800=20 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf=20 Access code:206 291 561=20 From fluffy@iii.ca Thu May 30 08:47:45 2013 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 27D6F21F8F5D for ; Thu, 30 May 2013 08:47:42 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz2c+9uQEhBv for ; Thu, 30 May 2013 08:47:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC121F8C0C for ; Thu, 30 May 2013 08:47:35 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C79EE22E200; Thu, 30 May 2013 11:47:28 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 30 May 2013 09:47:26 -0600 Message-Id: To: "rtcweb@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [rtcweb] Requests for agenda items for SDP Security Description (SDES) viral meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:47:45 -0000 If you would like agenda time at this meeting, please send email by the = end of June 5 and let us know.=20 Thanks, Ted, Magnus, Cullen = From enrico.marocco@telecomitalia.it Thu May 30 08:54:08 2013 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 9C3D421F939E for ; Thu, 30 May 2013 08:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrGbi1Zx68EZ for ; Thu, 30 May 2013 08:53:45 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9103121F96A3 for ; Thu, 30 May 2013 08:53:37 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 30 May 2013 17:53:33 +0200 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 30 May 2013 17:53:33 +0200 Message-ID: <51A775FC.8080003@telecomitalia.it> Date: Thu, 30 May 2013 17:53:32 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <51A66B3B.6070005@gmail.com> <51A715E6.6060703@telecomitalia.it> <51A76CBA.7030106@alum.mit.edu> In-Reply-To: <51A76CBA.7030106@alum.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030202050205060605060909" X-TI-Disclaimer: Disclaimer1 Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:54:12 -0000 --------------ms030202050205060605060909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/30/13 5:14 PM, Paul Kyzivat wrote: >> 1. sender gets the additional local tracks >> >> 2. sender tells the receiver on the app-specific signalling channel >> (assuming a plain-english-over-something one): "I can also send yo= u >> video and audio of a webcam I've just installed in the girls locke= r >> room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved throug= h >> JS API -- kind of what exists in Chrome today for stats) >> >> 3. receiver responds "Shoot!" >=20 > What does the receiver say if it can use the media, but cannot receive = > it over the *existing* audio and video m-lines where it is receiving=20 > other media already? I may have misinterpreted the draft, but it seems to me the whole point here is about having WebRTC endpoints support multiple SSRCs on the same m-line. If that's the case, an endpoint not supporting that would qualify as "legacy". It would be behind a gateway anyway, and the gateway function would be in the best position to translate both SDP and media in a way it can digest. Enrico --------------ms030202050205060605060909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA1MzAx NTUzMzJaMCMGCSqGSIb3DQEJBDEWBBSvwgW4pFkCBwmC9+RWP8Ss/FKWKTBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAafEvPvuZDyRTcSk//2AgdkHsneGqyl3SZwKRnWSV FYhyIcN9A1+Hsly2EzZfR8gf+CE5PICiGOuaeX3Ey/i4pyApQZE0sE1AxkO8zMakL9xRPXvl D+0NrZi2LuG7oAJOwNLemu0xtgdQR/tr0XGfg70mfMrDw0sTgc3HL+I020w9nisfq3/RAoB3 HXGkRD2VV6edZMkIkMxOFf6c8kiJiZH0toL/7yI9E68c1Uj8D17cgCFjaAywfAxRcFKSHEhj kRk8MH9WfBO9j5OZ2OZeCceTkQYC5BF6dBT8fB6cbaU0TIyrfQAOaqz0EtLVB2FZMSi352zL v05uBW1lqHeM7wAAAAAAAA== --------------ms030202050205060605060909-- From pkyzivat@alum.mit.edu Thu May 30 09:53:59 2013 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 C51DC21F89C3 for ; Thu, 30 May 2013 09:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cLpQMg8ILKt for ; Thu, 30 May 2013 09:53:54 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C0BDB21F92FB for ; Thu, 30 May 2013 09:53:53 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id iCuD1l0041ZXKqc53GttZ7; Thu, 30 May 2013 16:53:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id iGtt1l0053ZTu2S3hGttwA; Thu, 30 May 2013 16:53:53 +0000 Message-ID: <51A78420.40308@alum.mit.edu> Date: Thu, 30 May 2013 12:53:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A66B3B.6070005@gmail.com> <51A715E6.6060703@telecomitalia.it> <51A76CBA.7030106@alum.mit.edu> <51A775FC.8080003@telecomitalia.it> In-Reply-To: <51A775FC.8080003@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369932833; bh=xVnl6pIJpoEGi4H6Cpclv1N+KiKO9Z2drWgpSQvbrAM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nbLZjEZ1wMdgjr8gWgZo3EOlxTUgvOmjbq6HaQAXNTGhEBuWv+nSNYvOwziD60NhS 3OoS50d5XmGj+YUMv2c5mXRtzSwVUKP30p6mrr0gNVeHX+ppySERykl2Y8LMHaaC3j +0DYpoujBucWWDOz9n9teRBBXtO7fCPyAb5XTjsDHv+Oz+jU14+txl7L9KiBWIn7Oz TVot00osVL2psSXuSkfMAGz38Rc9xFszWmLFuATYYnA74N50fezYNCZ4CGqm3ivBGS g+NU4GCn+5k1Nx06gqvbdUhXsdWzYrCo/PgNoZTpVXHsrgIWQwhg6k1q90nJNP01yP 5ImNhzY8iAapw== Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 16:54:00 -0000 On 5/30/13 11:53 AM, Enrico Marocco wrote: > On 5/30/13 5:14 PM, Paul Kyzivat wrote: >>> 1. sender gets the additional local tracks >>> >>> 2. sender tells the receiver on the app-specific signalling channel >>> (assuming a plain-english-over-something one): "I can also send you >>> video and audio of a webcam I've just installed in the girls locker >>> room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved through >>> JS API -- kind of what exists in Chrome today for stats) >>> >>> 3. receiver responds "Shoot!" >> >> What does the receiver say if it can use the media, but cannot receive >> it over the *existing* audio and video m-lines where it is receiving >> other media already? > > I may have misinterpreted the draft, but it seems to me the whole point > here is about having WebRTC endpoints support multiple SSRCs on the same > m-line. If that's the case, an endpoint not supporting that would > qualify as "legacy". It would be behind a gateway anyway, and the > gateway function would be in the best position to translate both SDP and > media in a way it can digest. "legacy" and "decomposed" are not the same thing. Presumably the design center for webrtc is a browser running on one system with a single display. And in that case everything to a single address makes sense. But consider webrtc in the context of clue/telepresence. A browser be a very good basis for a controller for a telepresence room - providing the UI for managing a telepresence system. But that room will also have multiple displays. Each may have its own rendering hw. Or, if that is too extreme for you, consider a simple PC running a browser and connecting to a telepresence room. The PC may be putting several video streams into windows, and be happy to get them on a single address/port. But the *other* end may be a sip-based clue system, decomposed, that can't group all of the streams into a single bundle. This is not a *legacy* case - we are still designing clue. Thanks, Paul From fluffy@iii.ca Thu May 30 10:07:32 2013 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 F3EA721F92F5 for ; Thu, 30 May 2013 10:07:31 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDbOjuWerAcf for ; Thu, 30 May 2013 10:07:24 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CEF1321F8B90 for ; Thu, 30 May 2013 10:07:23 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0279122E2BA; Thu, 30 May 2013 13:07:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A65017.4090502@jitsi.org> Date: Thu, 30 May 2013 11:07:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5E1D65CF-C490-4DE6-BB8D-6CB871433846@iii.ca> References: <51A65017.4090502@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - PT based MUX X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 17:07:32 -0000 So my read of this draft is that it allows two camera to send on the = same PT but the applications would demux them based on SSRC and the = browser would only look at the PT.=20 I can't understand how this would possibly work. Lets say they are both = VP8, we two different VP8 decoder contexts. The jitter buffers for the = two need to be different. Unless that VP8 decoder is in the JS along = with the jitter buffer, how does this work ? On May 29, 2013, at 12:59 PM, Emil Ivov wrote: > Hey all, >=20 > Based on many of the discussions that we've had here, as well as many = others that we've had offlist, it seemed like a good idea to investigate = a negotiation alternative that relies on SDP and Offer/Answer just a = little bit less. >=20 > The following "no plan" draft attempts to present one such approach: >=20 > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >=20 > The draft relies on conventional use of SDP O/A but leaves the = intricacies of multi-source scenarios to application-specific = signalling, with potentially a little help from RTP. >=20 > Hopefully, proponents of Plans A and B would find that the = interoperability requirements that concerned them can still be met with = "no plan". Of course they would have to be addressed by = application-specific signalling and/or signalling gateways. >=20 > Comments are welcome! >=20 > Cheers, > Emil >=20 > --=20 > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu May 30 10:07:32 2013 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 0AC6721F9307 for ; Thu, 30 May 2013 10:07:32 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQDkhDR+lFvD for ; Thu, 30 May 2013 10:07:24 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 947D221F8616 for ; Thu, 30 May 2013 10:07:23 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 03E4122E1F4; Thu, 30 May 2013 13:07:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A65017.4090502@jitsi.org> Date: Thu, 30 May 2013 11:07:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A65017.4090502@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 17:07:32 -0000 Interesting draft but it seemed to have more questions about how things = would wok than answers. Let me try and ask you some specifics to help = flesh out what this plan is and offer a few comments. Of the actual recommendations in the draft that relate to the problem I = would summarize that draft as=20 1) demux RTP based on PT but let the application know the SSRC in case = it wants to do something more=20 2) the way the applications interacts with the browser for set up of the = media stack is via SDP=20 3) Other session control not related to the media stack is left up to = the application to do how it wants 4) Things like conference control and clue control and call control = should be handled by the application 5) you have a few avenues we might pursue for making FEC, RTC, etc work=20= 6) you have some API requirements which, with the exception of 4 about = exposing the max number of incoming streams that can be decoded, I think = are pretty much agreed to be put put in W3C API already. On the topic of = #4, it's a big unclear what is really needed and ongoing discussion is = happening around how do indicate what can be received but thats a webrtc = issue This is very close to Plan A. So I read the whole draft and asked myself = how is this different than plan A. What parts of this draft would not be = abel to do if we did Plan A. The only real topic I could come up with = was the port music here is PT only instead of PT + SSRC. I'l start a = separate thread on that.=20 But lets ask what the proposal is for the question Plan A and Plan B are = trying to resolve.=20 Let's say browse A wants to say it can send two streams of video and = here are the parameters for the video codecs for each to the streams. = What does the SDP that createOffer generates look like? I see the draft = says "strongly advises against the use of multiple m=3D lines for a = single media type. " but I don't really know what you mean by that. Can = you explain what you are actually proposing we do do instead of just = saying what not to do ? The above paragraph is the most important part of my email. Please, what = is the proposal for what the SDP in the offer looks like.=20 The idea of exposing a low level API to the media stack and having the = all proposing to do FEC, RTX, SDP processing ect has been discussed many = times across the various working groups. It' jokingly refereed to as = comment 22 at this point. It's not that it does not have merits, but = many people myself included see it as a much longer road to get done, a = lot more work, and no clear gain. One of the other issues is we are = trying to make this so you don't have to be a telephone expert to use it = and that lots of developers can use it. I'm not going to try and = summarize the low level API augments here but if you want to discus it = webrtc is the right WG.=20 I'll note there are many points in the draft that I disagree with but = I'd rather try and sort through what the actually proposal is here = before addressing any of them. There is one point I would like to make that is the confusion introduced = by "legacy endpoint". When I talk about legacy endpoints, I am talking = about endpoints that use SIP or Jingle and both past ones and future = endpoints. SIP will continue to evolve and I expect WebRTC to continue = being able to negotiate new features. For example, if a SIP phone added = VP9 and a browser supported VP9, I would expect to be able to use it. = The legacy refers to an older protocol, SIP, and not to the age of the = endpoint. We do know that things can't work with all deployed endpoints = and long ago we made the decision to give up on endpoints that don't do = ICE. But we do try and have a reasonable experience with old and future = endpoints.=20 On May 29, 2013, at 12:59 PM, Emil Ivov wrote: > Hey all, >=20 > Based on many of the discussions that we've had here, as well as many = others that we've had offlist, it seemed like a good idea to investigate = a negotiation alternative that relies on SDP and Offer/Answer just a = little bit less. >=20 > The following "no plan" draft attempts to present one such approach: >=20 > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >=20 > The draft relies on conventional use of SDP O/A but leaves the = intricacies of multi-source scenarios to application-specific = signalling, with potentially a little help from RTP. >=20 > Hopefully, proponents of Plans A and B would find that the = interoperability requirements that concerned them can still be met with = "no plan". Of course they would have to be addressed by = application-specific signalling and/or signalling gateways. >=20 > Comments are welcome! >=20 > Cheers, > Emil >=20 > --=20 > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu May 30 10:10:19 2013 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 55EA921F9012 for ; Thu, 30 May 2013 10:10:19 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k6MrFS1mtAG for ; Thu, 30 May 2013 10:10:13 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 328A421F93DC for ; Thu, 30 May 2013 10:10:11 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1FA0622E200; Thu, 30 May 2013 13:10:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Thu, 30 May 2013 11:10:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3F7A9F37-F2CD-415F-A61C-7BF63134C9D6@iii.ca> References: <51A65017.4090502@jitsi.org> To: Mary Barnes X-Mailer: Apple Mail (2.1503) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 17:10:19 -0000 On May 29, 2013, at 1:23 PM, Mary Barnes = wrote: > Personally, I really like this approach. I think it will work well > for CLUE.=20 Mary, I'm really trying to get my head around all the CLUE stuff and = make sure music can do something that, as much as possible, works for = CLUE, WebRTC and other SIP users. Can you elaborate on what part of this = draft you like and why that works for CLUE. I think that would help find = good solutions. From fluffy@cisco.com Thu May 30 10:26:31 2013 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 8FC7821F9625 for ; Thu, 30 May 2013 10:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaBaxpXPxJ9f for ; Thu, 30 May 2013 10:26:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE421F9397 for ; Thu, 30 May 2013 10:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1142; q=dns/txt; s=iport; t=1369934785; x=1371144385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eTFmeaMcFWQNvlCneUusZgOEINWQR9bviCj4gPN5C2w=; b=WlZl6yP6Ithsk7XaOC1wNRfSyIav/ucZcmBo/9vm6KzDHvuz7ekBbGOX pniG++G2CvcRytUQz5b1C/3tmxVil7j5Ky3Kh1aDZHLJ6bXzT1XrGB7Ym tql7IPWgdDD4784d9Gl6ru/LLDIaeIQsQc14nBxaPtpkXQ4/1Mi3oT9EL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI+Kp1GtJXG+/2dsb2JhbABQCYMJwkZ+FnSCIwEBAQMBOj8QAgEIDgoKFBAyJQIEDgUIh38Gu3CNYYEIAjEHgnZhA6h+gw+CJw X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216925714" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 30 May 2013 17:26:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHQL1H011044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 17:26:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:26:21 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [rtcweb] A problem with both A and B Thread-Index: AQHOXVrM3QhpqWEsQEOof9XIjI1G9Q== Date: Thu, 30 May 2013 17:25:23 +0000 Message-ID: References: <51965506.7050008@jitsi.org> <5199EE06.30705@jitsi.org> In-Reply-To: <5199EE06.30705@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <977A77DA82C175499F92B6545E4F18DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 17:26:31 -0000 On May 20, 2013, at 3:33 AM, Emil Ivov wrote: >=20 >=20 > On 20.05.13, 11:53, Kevin Dempsey wrote: >> Relying on SSRC signalling would mean that RTP sent before the SSRC >> identity arrives would not be handled consistently with RTP arriving >> after the SSRC identity. >=20 > If the application is doing the SSRC signalling and if the WebRTC API > provides a way of retrieving it, an app would be able to signal an SSRC > before, together with, or after the SDP from O/A. It will all be up to > exactly what the app needs. >=20 > Emil Uh, so I thought that is how both plan A and plan B worked. Yes the syntax = of the passing the SSRC across the API uses SDP in both cases but the appli= cation can do whatever it wants with and provide it any way it wants. What = am I missing? I think people long ago agreed stats API would reflect up SSR= C and other information to the application as a second path that is not SDP= .=20 If you are suggesting that a syntax like JSON would be better than SDP synt= ax to pass the semantic information across the JS API, well that back to co= mment 22.=20 From fluffy@cisco.com Thu May 30 10:27:54 2013 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 D368E21F9467 for ; Thu, 30 May 2013 10:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qZPAv0pjeoF for ; Thu, 30 May 2013 10:27:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39021F9485 for ; Thu, 30 May 2013 10:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=390; q=dns/txt; s=iport; t=1369934866; x=1371144466; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z+WLDa2V+2UqfgoR55glFZFs2doC3eSWLyMXIPi+Nzo=; b=m9k77QSBeAJkV7C0BJeMsiR1BD1Ce6q40ixGLLaDZeooLIgbzPEjbV4Y M3Bm/fZ3cgIdvc1SQGVouYtwN8vL+VTSv4oMMqAspNGzuPD9TJiSAgomV SLEZMyR20QboWF24cwCwzV2GA4zENYGTOA2z3LrTaccTFNsHafoicPVbJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAI+Kp1GtJV2Y/2dsb2JhbABZgwmDJK0AkiJ+FnSCIwEBAQMBeQULAgEIIiQyJQIEDgUIh3MDCQa7cIxEgiUCMQeCdmEDiGiMcY4ChSODD4In X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216833602" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 30 May 2013 17:27:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHRjBb015421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 17:27:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:27:45 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [rtcweb] Comments on draft-uberti-rtcweb-plan-00 Thread-Index: AQHOXVr/UMZXG2rPG0q7AkRHIl0/3A== Date: Thu, 30 May 2013 17:26:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19AA0565FF81CC4DB73C8F2926822DDD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-uberti-rtcweb-plan-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 17:27:54 -0000 On May 11, 2013, at 5:59 PM, Bernard Aboba wrot= e: > To some extent this document is arguing against a straw man (individual m= =3D lines for RTP streams) that in its extreme case (dozens of RTP streams= , possibly with simulcast and layered coding) is quite impractical. Can you say a bit more about why it is impractical to have lots of m line ? From rlb@ipv.sx Thu May 30 10:28:27 2013 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 0A50221F960C for ; Thu, 30 May 2013 10:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzHbT9oad0e9 for ; Thu, 30 May 2013 10:28:23 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E186221F9590 for ; Thu, 30 May 2013 10:28:22 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so1167976obb.0 for ; Thu, 30 May 2013 10:28:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uM00DgSLvQRi9ysjwKxt4mB7gO3ujCsfBOUWf593QIo=; b=G/Zal80/Je2EPR5F7OD7bjLqlH6HD71SYh6XoCzidem2A6AOOB4Dfd5wwZv0CKbZAK SynakARyvKmKTWblt9KxI71KKQsMW4Vm4gqkFV2iCz5twCXzHA9Kv6ZPgbXkfrbe2pMW gw1JPeVWHPzuTNawjssT/SDPTB/JmsPzN4UYZoyzYsiNXnIrEmZTb0HfnHioYbnAfHQG k2L1Bso8f/bwpBHPClyfvLINGm3JrM638tLVU52yHttsRd5sJJg/qoDPYLgHR6xLeoLy ii3MhReh6MT61gbIRKuaCNu8nbNDRnzMUUat2Hd+I9rjjMOLhOqahbDRpxVjUvOj6t2k TWpg== MIME-Version: 1.0 X-Received: by 10.60.35.100 with SMTP id g4mr4491526oej.53.1369934902352; Thu, 30 May 2013 10:28:22 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Thu, 30 May 2013 10:28:22 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: References: Date: Thu, 30 May 2013 13:28:22 -0400 Message-ID: From: Richard Barnes To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e013c68a0386da604ddf2d3c1 X-Gm-Message-State: ALoCoQkX16LadAontRMoSOuPHZ5WexLZBoayq3bAEvhoQRH9qFTj+bv89hr4yZ6x8CckFtyb7N8c Cc: "Dale R. Worley" , "rtcweb@ietf.org" Subject: Re: [rtcweb] A problem with both A and B X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 17:28:27 -0000 --089e013c68a0386da604ddf2d3c1 Content-Type: text/plain; charset=ISO-8859-1 I'm confused. The "no plan" plan still requires signaling, it's just not O/A. So what are you saving? On Fri, May 17, 2013 at 4:21 PM, Bernard Aboba wrote: > It is important. In fact, I would argue it is critical for congestion > control (e.g. removal of simulcast or layered streams by the sender should > not require an O/A exchange). > > "Dale R. Worley" wrote: > > > From: Emil Ivov > > > > Both plan A and B currently describe semantics that would require O/A > > exchanges every time a source is added or removed from a session. > > [...] > > Does any of this make any sense? > > My understanding (and I'm not tracking everything carefully) is that > this is a bad situation. I've been accumulating desiderata, and one > that has been on the list for a long time is: > > DES F11 It must be possible to add and remove one way video flows > within the bundle without requiring an additional offer/answer > cycle. > > Do people think that this is not important? > > Dale > _______________________________________________ > 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 > --089e013c68a0386da604ddf2d3c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm confused. =A0The "no plan" plan still re= quires signaling, it's just not O/A. =A0So what are you saving?


On Fri, May 17,= 2013 at 4:21 PM, Bernard Aboba <bernard_aboba@hotmail.com>= wrote:
It is important. In fact, I would argue it i= s critical for congestion control (e.g. removal of simulcast or layered str= eams by the sender should not require an O/A exchange).

"Dale R. Worley" <worley= @ariadne.com> wrote:

> From: Emil Ivov <emcho@jitsi.org= >
>
> Both plan A and B currently describe semantics that would require O/A<= br> > exchanges every time a source is added or removed from a session.
> [...]
> Does any of this make any sense?

My understanding (and I'm not tracking everything carefully) is that this is a bad situation. =A0I've been accumulating desiderata, and one<= br> that has been on the list for a long time is:

=A0 =A0DES F11 =A0It must be possible to add and remove one way video flows=
=A0 =A0 =A0 within the bundle without requiring an additional offer/answer<= br> =A0 =A0 =A0 cycle.

Do people think that this is not important?

Dale
_______________________________________________
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

--089e013c68a0386da604ddf2d3c1-- From fluffy@cisco.com Thu May 30 12:29:08 2013 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 85A2121F9052 for ; Thu, 30 May 2013 12:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOzknkt5Zh5V for ; Thu, 30 May 2013 12:29:03 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7C221F911B for ; Thu, 30 May 2013 12:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=667; q=dns/txt; s=iport; t=1369942143; x=1371151743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LuW5syfdRf7BDfKnxHca2zQsOvAhLiTUYVUI5UWNzhk=; b=gXeVK64keu+Lb6ScfjcXqxJRmJNO7DYHp0eJd6bJUWVYs23ib5TMXDuZ VlHeDcZ4+X225oIUlQZ5dvPWdHagiu+Jwhp3M9gB3U3U29U5BFhR5wdI3 CnI2iRFKw5Ms20cO9MmWOp5jyT/MUvBDI5/OYwjWWFmjACtyKop3frlNN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAEKnp1GtJXG//2dsb2JhbABZgwkwQ4IxvyN+FnSCIwEBAQMBaA8CBQsCAQgOFBkLMiUCBA4FCId/Bge7V41qfwIxB4J2YQOIaJp2AYUfgViBN3IBAX02 X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216980515" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 30 May 2013 19:29:03 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4UJT2xu008500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 19:29:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 30 May 2013 14:29:02 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) Thread-Index: AQHOXWvwcN6zFOJ3ZUmLbzKeS3jk2Q== Date: Thu, 30 May 2013 19:28:04 +0000 Message-ID: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, , <518AAAF2.5000207@alum.mit.edu>, , <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, , <518D6C76.5060606@alum.mit.edu>, <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> In-Reply-To: <5192947F.90206@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E63FE2FF7B9BA42B1506C87399269D4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt ) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 19:29:08 -0000 On May 14, 2013, at 1:46 PM, Emil Ivov wrote: > The issue that I am referring to (I describe this in an earlier mail to > Harald here http://goo.gl/M8NbQ ) is that of a conference based on an > RTP translator. It's basically what we do in Jitsi Videobridge. Many deployments use a mixer instead of a translator from an RTP point of v= iew. I understand at the media level you would not decode / encode or mix t= he media but at the RTP layer the bridge could have it's own SSRC and put t= he SSRC of the original sender in the CSRC.=20 Any reason you choose a translator over a mixer when building a conferencin= g fencing bridge? From fluffy@cisco.com Thu May 30 12:42:01 2013 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 E890A21F8F3E for ; Thu, 30 May 2013 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUUozxI39mRk for ; Thu, 30 May 2013 12:41:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4A32321F8EFE for ; Thu, 30 May 2013 12:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=190; q=dns/txt; s=iport; t=1369942916; x=1371152516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d/LlPCo2favQCdwJFOnF26CbXe1UHLA0C8XgSwzIUQU=; b=B81oY6ff2E0JF2cSAVpKGHN+S3L9EpPSa536YWs0KR9WHdnaMfZfA4+k y4TUH945kMJhTFWNC8x4u8v8exkuZ8rdCI3KLZcqLeJS9623IBKRvMhqV XJ8ng9Q+OYBxRkyDg57FCG6MupLmKHJiJyzKYmoGfPWayROPSqipIAH+8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAOSqp1GtJV2b/2dsb2JhbABZgwmDJL8jfhZ0giMBAQEDATo/BQsCAQgiFBAyJQIEDgUIh38GuzOOaQIxB4J2YQOofoMPgic X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216905830" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 30 May 2013 19:41:54 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4UJfsTY029725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 19:41:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 30 May 2013 14:41:54 -0500 From: "Cullen Jennings (fluffy)" To: Harald Alvestrand Thread-Topic: [rtcweb] Plan A, respun Thread-Index: AQHOXW28v2AAdW1bEEqeJP5168RJEA== Date: Thu, 30 May 2013 19:40:56 +0000 Message-ID: References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no> <51952860.5030906@nostrum.com> <5195304B.10706@alvestrand.no> In-Reply-To: <5195304B.10706@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C76D2CF59AC9744A9BE2099E6872751@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan A, respun X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 19:42:02 -0000 On May 16, 2013, at 1:15 PM, Harald Alvestrand wrote= : > Has dynamic allocation of sub-96 payload numbers ever been tested at a SI= Pit, for instance? Yes From gunnar.hellstrom@omnitor.se Thu May 30 14:04:10 2013 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 AF82021F9003 for ; Thu, 30 May 2013 14:04:10 -0700 (PDT) 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=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obQCoMHkhXK0 for ; Thu, 30 May 2013 14:04:05 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 35E4B21F8FBA for ; Thu, 30 May 2013 14:04:04 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 30 May 2013 23:03:56 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 374543A123 for ; Thu, 30 May 2013 23:03:56 +0200 (CEST) Message-ID: <51A7BEBE.2040302@omnitor.se> Date: Thu, 30 May 2013 23:03:58 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> In-Reply-To: <51A65017.4090502@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 21:04:10 -0000 Interesting. I find it to be good to have a specified ambition for legacy interoperability. But I cannot see how we could specify it without RTP based real-time text on the SIP side. It seems that you mean that support for sessions with media beyond the defined limited legacy session will be specified and implemented for each application where they appear. I think that leaves real-time text usage with too high risk of not achieving harmonized interoperability and not being supported in an harmonized way. It needs to be included in the interoperability specification. A very important driving force behind legacy interop will be emergency service access. We have touched that before, and there has been varying acceptance for that fact, but it will be needed. The emergency services cannot be expected to set up parallel systems for each call control environment, but will need to get calls converted to SIP. And video, audio, real-time text and text messaging are specified for the interface. I think it is best to accept to build that whole set of media into rtcweb from the beginning. This set of media is of course not only used for emergency calling, but also for user-to-user sessions. It is just that the emergency service is a good harmonizing factor. What you need to do to interoperate with emergency services is convenient to also offer for interop with other providers. This reasoning is not isolated to the No Plan, but it stood out so clear in your chapter about the limited interoperability plan. The No Plan would just need to be extended with reasoning about m=text for RTP based real-time text. (It possibly need some text about text messaging also if there is any interest in that. Someone else need to argue for that. Is it sdp - negotiated MSRP that would be the natural choice, requiring a discussion of data channel inclusion in the draft?) /Gunnar On 2013-05-29 20:59, Emil Ivov wrote: > Hey all, > > Based on many of the discussions that we've had here, as well as many > others that we've had offlist, it seemed like a good idea to > investigate a negotiation alternative that relies on SDP and > Offer/Answer just a little bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the > intricacies of multi-source scenarios to application-specific > signalling, with potentially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the > interoperability requirements that concerned them can still be met > with "no plan". Of course they would have to be addressed by > application-specific signalling and/or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > From ibc@aliax.net Thu May 30 14:34:01 2013 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 1920B21F86CA for ; Thu, 30 May 2013 14:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QASFzqC5UXX for ; Thu, 30 May 2013 14:34:00 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD3C21F93BD for ; Thu, 30 May 2013 14:33:59 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so96791qab.17 for ; Thu, 30 May 2013 14:33:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=o71DNFZw5w0cICvQ7VPoF+WUXb9Ql2dj+Ct6v6dQ85o=; b=paavwwCGMiLJvwd4GD5DA3WkVzoA0OddSxCcNAvFDqXg6GiN8ervMMqM1hCcEo2Mjv dlBjBdgIpRxAdoohsU6d9BWeCpIshJ46W4oPeSN59oZJqwC4yrn1+ZiYy6fDdMp1b3nV AyuOx0VkMxlqc05Nv0BQECyWPDuMhfQwAWlhAuGDKsHLp8HcwbIkakwhbbE0cqzNjNOZ muMg7vGO6E7Fy9J70KdCV2T5FGjr/iB9VXAStEpI2vVOmtizAe5Z84vf7a5rI2hkBM/O jJ08rkIJOrTmhAOrHYfXIbH/TPP5UxLj8AlCvOi4NZKQlsOTqXlihqCbBTG7M2UvZFOX fqbA== X-Received: by 10.224.4.74 with SMTP id 10mr7975884qaq.38.1369949639246; Thu, 30 May 2013 14:33:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Thu, 30 May 2013 14:33:39 -0700 (PDT) In-Reply-To: <51A7BEBE.2040302@omnitor.se> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 30 May 2013 23:33:39 +0200 Message-ID: To: Gunnar Hellstrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmCEjkUOJPzLEFOvjsjU1qS/0V9uHz8oD6FLwV4Hrryij2ZsBZb5gAQL6JmQE7BzJUZ4GL7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 21:34:01 -0000 2013/5/30 Gunnar Hellstrom : > I find it to be good to have a specified ambition for legacy > interoperability. > But I cannot see how we could specify it without RTP based real-time text= on > the SIP side. > The No Plan would just need to be extended with reasoning about m=3Dtext = for > RTP based real-time text. > > (It possibly need some text about text messaging also if there is any > interest in that. Someone else need to argue for that. Is it sdp - > negotiated MSRP that would be the natural choice, requiring a discussion = of > data channel inclusion in the draft?) In the Web there are lot of ways for sending any kind of messages. In WebRTC we are not limited to the "RTP" channel to communicate with others (peers or servers). In WebRTC the destination of a "media session" is not mandated to be a PSTN phone or PSTN server. Here there is a "web context", something that does not exist in VoIP protocols which are just limited to the signaling capabilities of the protocol itself. Here the application using WebRTC (a JavaScript application) is a custom app designed to work with a custom server side (the web server), and each website will choose and design how their client applications (the JS of their web pages) communicate with their web servers and other clients. This includes usage of HTTP requets, AJAX, WebSocket or whatever. We are not constrained to the "media channel" anymore, this is not the PSTN with funny DTMFs for all. So honestly I don't understand why WebRTC should care about "text messaging via RTP", and I really hope that "MSRP" word is never included in any RTCWEB WG specification. IMHO it's already enough having 3 proposals attempting to adapt SDP into WebRTC requirements. Gateways are required, in any way, for connecting WebRTC and the world outside (SIP, PSTN, etc), let's leave those gateways to do the "magic" instead of proposing that a browser can send text messages via RTP to a SIP phone. Just my opinion. Regards. -- I=C3=B1aki Baz Castillo From sergio.garcia.murillo@gmail.com Thu May 30 15:07:00 2013 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 777A421F86CA for ; Thu, 30 May 2013 15:07:00 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vMr3bZxJD-F for ; Thu, 30 May 2013 15:06:59 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6607721F8555 for ; Thu, 30 May 2013 15:06:59 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id u57so703308wes.40 for ; Thu, 30 May 2013 15:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3vCE8Jisy/ooVpq3AEMR55ntXH2cJ6B0OmZGkKIkMPc=; b=g2W9v8v7jvgfvVmWcugAlF3896CjOjoRf5VUyl53GrnkKUhpTdfraJ0vo+tJejFjG9 p1IF3uGu+m3+gol5ZEWNz+srqYrMQSODMxLyB/XERRNtuBaW3AaDEo+kWks2YP85CDE8 NqFpUjZ7c8HzUhrdOxUTJv9WLDnQaHSVopw3G8FFgwUsPeKB3kGsM/9ENAyffb7tB2mO 3O6Y05b/u6rWO7Y++moW8+Bk2giJiyzgOw/3WpqlUSX7YCPVranjIR/EBlILHIpUv021 RGyCCf6nrfPGC9gf0iRGhb/CIRULRg5GWCIDJ3P4OFNHg8pHd/cNEINMl23K/FmiQ2Dj yQ9w== X-Received: by 10.180.149.131 with SMTP id ua3mr592510wib.55.1369951618434; Thu, 30 May 2013 15:06:58 -0700 (PDT) Received: from [192.168.1.2] ([90.165.220.207]) by mx.google.com with ESMTPSA id fv11sm122975wic.11.2013.05.30.15.06.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 15:06:57 -0700 (PDT) Message-ID: <51A7CD81.2060805@gmail.com> Date: Fri, 31 May 2013 00:06:57 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 22:07:00 -0000 El 30/05/2013 23:33, IƱaki Baz Castillo escribiĆ³: > 2013/5/30 Gunnar Hellstrom : >> I find it to be good to have a specified ambition for legacy >> interoperability. >> But I cannot see how we could specify it without RTP based real-time text on >> the SIP side. > So honestly I don't understand why WebRTC should care about "text > messaging via RTP", and I really hope that "MSRP" word is never > included in any RTCWEB WG specification. IMHO it's already enough > having 3 proposals attempting to adapt SDP into WebRTC requirements. To be fair, only two proposals try to modify the SDP, the third about not adapting the SDP or change the O/A model. > Gateways are required, in any way, for connecting WebRTC and the world > outside (SIP, PSTN, etc), let's leave those gateways to do the "magic" > instead of proposing that a browser can send text messages via RTP to > a SIP phone. Just my opinion. Indeed. I understand Gunnar requirements for RTT, but as you say, to connect to legacy devices you would need a gateway in the middle anyway. If the gateway support datachannels, It would be fairly trivial to bridge the real time text data from T140 rtp packets from/to the browser. Best regards Sergio From gunnar.hellstrom@omnitor.se Thu May 30 22:33:18 2013 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 C001F21F990D for ; Thu, 30 May 2013 22:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FJmSWkTQNs1 for ; Thu, 30 May 2013 22:33:13 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 2E70921F8EAE for ; Thu, 30 May 2013 22:33:10 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 31 May 2013 07:32:04 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 2CA5A3A123 for ; Fri, 31 May 2013 07:32:04 +0200 (CEST) Message-ID: <51A835D7.9060603@omnitor.se> Date: Fri, 31 May 2013 07:32:07 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> In-Reply-To: <51A7CD81.2060805@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 05:33:18 -0000 On 2013-05-31 00:06, Sergio Garcia Murillo wrote: > El 30/05/2013 23:33, IƱaki Baz Castillo escribiĆ³: >> 2013/5/30 Gunnar Hellstrom : >>> I find it to be good to have a specified ambition for legacy >>> interoperability. >>> But I cannot see how we could specify it without RTP based real-time >>> text on >>> the SIP side. >> So honestly I don't understand why WebRTC should care about "text >> messaging via RTP", and I really hope that "MSRP" word is never >> included in any RTCWEB WG specification. IMHO it's already enough >> having 3 proposals attempting to adapt SDP into WebRTC requirements. > > To be fair, only two proposals try to modify the SDP, the third about > not adapting the SDP or change the O/A model. > >> Gateways are required, in any way, for connecting WebRTC and the >> world outside (SIP, PSTN, etc), let's leave those gateways to do the >> "magic" instead of proposing that a browser can send text messages >> via RTP to a SIP phone. Just my opinion. It is not about text messages, it is about the real-time text medium. Just like real-time audio and real-time video. Smoother than messaging. Its user requirements for real-time transmission are close to the needs for audio and video, so it is on the rim to need RTP, but well designed data channel can also do. I do not understand why modern communication users accept to see a chat state indication of "composing" instead of really seeing what text is composed. With real-time text you get rid of the frustration that "composing" creates. Now, this was not meant to be a repetition of the motivations for real-time text, but a discussion on interoperability requirements and sdp handling. >> > > Indeed. I understand Gunnar requirements for RTT, but as you say, to > connect to legacy devices you would need a gateway in the middle > anyway. If the gateway support datachannels, It would be fairly > trivial to bridge the real time text data from T140 rtp packets > from/to the browser. Yes, agreed, a data channel is one possible transport for real-time text and we need to get down to describing the alternatives and decide soon. What I am getting afraid of when I see the limited interperabillity discussion in "No Plan" is that we will not get a chance to specify the full view of the really needed interoperability. The mechanisms are tied to RTP characteristics, such as SSRCs, and it is said that interop beyond that limited scope will be an application concern. If this is the only place where we will discuss common specifications for SIP interoperability, then I want RTT to ride with this train and not be left alone on the station. I also do not share IƱaki's view that rtcweb is all about communication between a server and a client delivered by that server, so that text communication is a local thing between that server and client. We have agreed that rtcweb must not be the continuation of building silos. Users of different providers and servers will want to have communication with each other, and that creates a need for explicit standards for session establishment and media stream establishment. Real-time text is one of the basic media together with audio and video which need to be fully defined for such interoperability. Regards Gunnar > > Best regards > Sergio > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From sergio.garcia.murillo@gmail.com Fri May 31 01:18:43 2013 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 C6FB621F93E1 for ; Fri, 31 May 2013 01:18:43 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4fjTZboZWbG for ; Fri, 31 May 2013 01:18:43 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A988B21F93DA for ; Fri, 31 May 2013 01:18:42 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id r16so1293328ead.27 for ; Fri, 31 May 2013 01:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9ah7Caj88zNiOPiE+zVSc3Op9TazwTlFuHwgYYBzJWM=; b=EKk32KhrNKd6+hJ9Z3yNtbJEfuB7pEzgnm2u8WP81uyCex9kGyPf4IKNLzwmbSkWVB a8GoFfCb58GMkzuq0+zcFWMZS9bJouUqpndIeA66dfIaN+FUX6XA1MrV42kBb5LOEm6x 1Z/k1CwQ6/0etKIPvNTvpUQxN7E/pzCQ0s219KwIQqu4EFHyks0J+zkPrtui9MXuRNza PADnTS0lojd9LCe7ZmCqjzFJzIZ9TRzrZ2jNCSk1MjVODdIvkrE5nMfliCdnDl23kTZi WRP7pjx37/1LWd3jX3dRXMTMaYoZEMGE7Et0gKbcb/2iA2F24poDSPTJdrgf/G4VzCo5 wG2w== X-Received: by 10.15.82.193 with SMTP id a41mr2950984eez.39.1369988321792; Fri, 31 May 2013 01:18:41 -0700 (PDT) Received: from [192.168.1.50] (226.Red-95-122-179.staticIP.rima-tde.net. [95.122.179.226]) by mx.google.com with ESMTPSA id z52sm65272022eea.1.2013.05.31.01.18.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 01:18:40 -0700 (PDT) Message-ID: <51A85CE3.4030700@gmail.com> Date: Fri, 31 May 2013 10:18:43 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> In-Reply-To: <51A835D7.9060603@omnitor.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 08:18:44 -0000 El 31/05/2013 7:32, Gunnar Hellstrom escribiĆ³: > On 2013-05-31 00:06, Sergio Garcia Murillo wrote: >> El 30/05/2013 23:33, IƱaki Baz Castillo escribiĆ³: >>> 2013/5/30 Gunnar Hellstrom : >>> Indeed. I understand Gunnar requirements for RTT, but as you say, to >>> connect to legacy devices you would need a gateway in the middle >>> anyway. If the gateway support datachannels, It would be fairly >>> trivial to bridge the real time text data from T140 rtp packets >>> from/to the browser. > Yes, agreed, a data channel is one possible transport for real-time > text and we need to get down to describing the alternatives and decide > soon. What I am getting afraid of when I see the limited > interperabillity discussion in "No Plan" is that we will not get a > chance to specify the full view of the really needed interoperability. > The mechanisms are tied to RTP characteristics, such as SSRCs, and it > is said that interop beyond that limited scope will be an application > concern. If this is the only place where we will discuss common > specifications for SIP interoperability, then I want RTT to ride with > this train and not be left alone on the station. How "No Plan" is limiting interoperability for RTT? Supporting RTT is an orthogonal topic to No Plan/Plan A/Plan B as they are about how to handle different multiple tracks of the already defined media types. If RTT media tracks are finally supported by webrtc, they will be handled by "No Plan" automatically, and will be in fact handled the same way as it is done today in RTT sip clients, so in fact "No Plan" makes interoperability easier, not harder. Best regards Sergio From emil@sip-communicator.org Fri May 31 03:51:11 2013 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 812EA21F949D for ; Fri, 31 May 2013 03:51:10 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcoXShXxKV-p for ; Fri, 31 May 2013 03:51:07 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7A21F9433 for ; Fri, 31 May 2013 03:51:06 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk14so681177bkc.29 for ; Fri, 31 May 2013 03:51:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=lCTB4xp4cUxpZrP+OJVp6HqfM8y4qlhtVj20NC46j/Q=; b=mdTgq74XnX6gM2z7q2tHk9Sg6bdzwAvtjlViTWQJ4eFK1MUaiPafsCHaPwCpHGnX/H a+kvO7fe5b74fZ6mc30+ZbctXxdA9ChsKPTiZz8aVR7IHR1dNvQ9menFXcMOuNpz0DPo OzcRyaIHuypntKbdq9CFYfijahI5s9F/zl1PhiBXnm03oQAFO+EJc3XaqiQwqNsxZtKF BGQh0qgcjAgQmHKKU03Ya2tjITLlmlsIoeyRd4eZuriHeqa9Gp7pXTcshDUAf1BYsKzx Pb1riQWUMgwBHRG+/+u5rmfghlyNYUeGprmZEkOlVDn2ihKTHAv7fMXgR3awqLVMe/N5 Likg== X-Received: by 10.204.26.8 with SMTP id b8mr3192909bkc.83.1369997465878; Fri, 31 May 2013 03:51:05 -0700 (PDT) Received: from camionet.local (77-85-161-202.btc-net.bg. [77.85.161.202]) by mx.google.com with ESMTPSA id og1sm11203912bkb.16.2013.05.31.03.51.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 03:51:04 -0700 (PDT) Message-ID: <51A88098.1070407@jitsi.org> Date: Fri, 31 May 2013 13:51:04 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mary Barnes References: <51A65017.4090502@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnaJEAczc1jPKP+raLSQ6NPMbT5YXkJrZ+RFmtRWPTXbN/ddY+oSo1tJVGGs5uxGpA7WfkC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 10:51:11 -0000 Hey Mary, On 29.05.13, 22:23, Mary Barnes wrote: > Personally, I really like this approach. I think it will work well > for CLUE. You might also want to add a reference to XCON in section 4. > The very reason we chartered XCON was because it seemed much more > sensible to include more complex conferencing operations in a separate > application layer protocol as opposed to overloading SIP/SDP O/A. Agreed! Thanks, Emil > > Mary. > > On Wed, May 29, 2013 at 1:59 PM, Emil Ivov wrote: >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many others >> that we've had offlist, it seemed like a good idea to investigate a >> negotiation alternative that relies on SDP and Offer/Answer just a little >> bit less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the intricacies >> of multi-source scenarios to application-specific signalling, with >> potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the interoperability >> requirements that concerned them can still be met with "no plan". Of course >> they would have to be addressed by application-specific signalling and/or >> signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> >> -- >> https://jitsi.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > . > -- https://jitsi.org From emil@sip-communicator.org Fri May 31 03:51:28 2013 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 37FE921F9433 for ; Fri, 31 May 2013 03:51:28 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pptw-jnRAhrS for ; Fri, 31 May 2013 03:51:27 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D66B621F94E1 for ; Fri, 31 May 2013 03:51:21 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so673520bkc.38 for ; Fri, 31 May 2013 03:51:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=uU73sTtCdpBd/YrFGPzQBjycDKm9OEvee00TZ5EEb64=; b=j/MiVdLQECg4mmfS/h30HR54+qGuCG+2yv3bvRdrgK40Owm4emM7JvxdFATuY4sGj4 vzjpVyFPd3edSN1+G7cDFcmdMIEyMQJb+5RA/lUvMghO7LuxVXaQoJ4yreRSpZ81wWwt EFzjRTcPmCxazfXD7sIHzv4e900lGQCbk7N/BDKTtsaom8WYK29zK+/3DUIxsDcCxfKu WzVk7CSKPOpvgri6UR7nSaFuQZh/wGUUJZwRS3wSvyiEiOh7OA1O0hGu2hi0PM6o+eSw 49cuiNK922STYo9mOKliIM18wyFlkNEPBM05RQvnDPaQq1SmdDGfCs5g6V4hEoXJ0c+F 2hww== X-Received: by 10.205.21.10 with SMTP id qq10mr3181136bkb.133.1369997480813; Fri, 31 May 2013 03:51:20 -0700 (PDT) Received: from camionet.local (77-85-161-202.btc-net.bg. [77.85.161.202]) by mx.google.com with ESMTPSA id v6sm14966118bko.3.2013.05.31.03.51.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 03:51:20 -0700 (PDT) Message-ID: <51A880A7.7010908@jitsi.org> Date: Fri, 31 May 2013 13:51:19 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> In-Reply-To: <51A65DB8.9060702@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmGMVgzpOg/mM0A0nhjuk40p0HJTK9VPq6g+VPeB5kgnS+hlFBH36BDKvCPk+6eRczUOeFC Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 10:51:28 -0000 Hey Paul, On 29.05.13, 22:57, Paul Kyzivat wrote: > Emil, > > I'm going to reserve judgment on this pending further discussion. > I think this *might* work for CLUE, but I want to be certain. Sure! > I'm concerned with decomposed endpoints that can't manage all the > streams on the same address/port. They will need multiple independent > m-lines and/or bundle groups. This is obviously open for debate but the general idea of No Plan is that: Offer/Answer is used for configuring media and RTP stacks and additional signalling is not the browser's concern. Having extra m= lines, particularly when using BUNDLE, is in many ways just extra signalling. If you'd like for that signalling to be in SDP, I don't see any problem with it. However it would be best for this extra layer of SDP signalling to appear at either the application layer or in a signalling gateway (that is going to be there anyway). Does this make sense? Emil > > Further questions: > > I presume that you expect bandwidth in the SDP to be an aggregate > per-m-line, with application specific signaling for bandwidth at the > per-RTP-stream level? > > Thanks, > Paul > > On 5/29/13 2:59 PM, Emil Ivov wrote: >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many >> others that we've had offlist, it seemed like a good idea to investigate >> a negotiation alternative that relies on SDP and Offer/Answer just a >> little bit less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the >> intricacies of multi-source scenarios to application-specific >> signalling, with potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the >> interoperability requirements that concerned them can still be met with >> "no plan". Of course they would have to be addressed by >> application-specific signalling and/or signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > . > -- https://jitsi.org From ibc@aliax.net Fri May 31 05:35:57 2013 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 6735221F9425 for ; Fri, 31 May 2013 05:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDnBC5Trkzgm for ; Fri, 31 May 2013 05:35:56 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1F821F9473 for ; Fri, 31 May 2013 05:35:56 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bn16so450477qab.14 for ; Fri, 31 May 2013 05:35:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=YpzkFvRjvpu8dv/Bt8/UutPP3MHhDXSa7CDxZBY3fZs=; b=YYGh8sbmYKbSPad93As2clnjjQcIeldknWPbf9gns1o86+WgTdRq5wB9bCS3QNosNU 3GunHAxhDJBumtJHomBIoswzhK/QZy9EU7HFyIpgzmuYw0OGI3gm1CQWOM1idcUemkpo MWlQU61YeT5MxYweA0Wn0WqBNJ8TMfDKoIXNuMYKTljKVxFJUtF1fz+ebwSGnf2vFVa0 tH9dhMlCWq192CR1BnYo5YAEdM/b8NzNfyIzwuDsK+C+8VMpR1DKSXevxX85sEJXqM+p DVtg5qvSAenHR5o++yhkceBUxgD+rWtazPS5OWcEVKOAHzYD6e+4oTXATYiTXxsD6GQz oyQg== X-Received: by 10.229.124.80 with SMTP id t16mr235034qcr.93.1370003755525; Fri, 31 May 2013 05:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Fri, 31 May 2013 05:35:35 -0700 (PDT) In-Reply-To: <51A835D7.9060603@omnitor.se> References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 31 May 2013 14:35:35 +0200 Message-ID: To: Gunnar Hellstrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlKO/+cmj6lLQG+aidBtFNqnX5nKZeG/8h4bp9kP6wosu88gVmNmXk7LFaGqUxYGNgTuMEu Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 12:35:57 -0000 > I do not understand why modern communication users accept to see a > chat state indication of "composing" instead of really seeing what text i= s > composed. With real-time text you get rid of the frustration that > "composing" creates. > Now, this was not meant to be a repetition of the motivations for real-ti= me > text, but a discussion on interoperability requirements and sdp handling. That can be implemented on top of DataChannel anyway, I see no need for mandating it as a new RTP media stream negotiated via SDP. > I also do not share I=C3=B1aki's view that rtcweb is all about communicat= ion > between a server and a client delivered by that server, so that text > communication is a local thing between that server and client. We have > agreed that rtcweb must not be the continuation of building silos. Users = of > different providers and servers will want to have communication with each > other, and that creates a need for explicit standards for session > establishment and media stream establishment. Really? I don't think so. I will share a secret: the famous SIP trapezoid will never take place in WebRTC (it does not exist neither in SIP anyway). Can you open a user session into Facebook and chat or share content with a Google+ or Twitter use? for sure NOT. The same for RTC communication. If you are logged into Facebook, how will you tell your Facebook WebRTC user interface to "open a multimedia session" with a Google+ user? It seems that non-web people still think that Alice will be able to log into her website www.atlanta.com and initiate an audio/video "call" with Bob, logged into www.biloxi.com (two separate and independent websites). That will never occur. This is the WWW, not the PSTN in which the "media channel" is the communication base between users of different "providers" (with the extra cool feature of DTMFs). Not here, not in WWW. Please, take a look to the current WWW scenario. The same will be true when WebRTC is widely deployed. Another secret: Alice and Bob use Skype to communicate one to each other (when at least one of them is at home), and they both connect via SIP to the same PBX at work, and when they work in remote places, there is one or two SBC between them. The SIP trapezoid just exists in RFC's and our imaginations and will never exist in WebRTC. Same for WebRTC. I insist: a Facebook user cannot initiate a chat with a Google+ user, so he won't be able to establish a media session with him when both websites provide WebRTC capabilities. Really. > Real-time text is one of the > basic media together with audio and video which need to be fully defined = for > such interoperability. Facebook, Google+, Twitter and any other website use their own custom mechanisms for providing chat capabilities to *their own* users *between them*. I don't expect that they will be interested in a peer-to-peer (user-to-user) realtime text because they want to log the messages, inspect them, offer you advertisements based on the content of your "private" chats, etc. Really, WebRTC is not the new PSTN, and there is no need at all to waste time thinking about "interoperability" between different WebRTC islands. In fact there won't be WebRTC islands but Web islands (as today), and WebRTC will be just a new "feature" provide by those web islands for their users. Probably some website (i.e. www.example-A.com) will let you sending an "invitation URL" to any contact (i.e. via mail) so the receipt of the invitation will open the URL and will get automatically "logged" or "authorized" into www.example-A.com for having a multimedia session with the first user (note that both users will use a WebRTC JavaScript app provided by the same website www.example-A.com). That's all. But Alice logged into www.example-A.com won't be able to make a "call" to Bob logged into www.example-B.com. Saying the opposite goes against the facts provided by the WWW during long years. Best regards. -- I=C3=B1aki Baz Castillo From fluffy@cisco.com Fri May 31 07:34:45 2013 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 0F6A721F92E3 for ; Fri, 31 May 2013 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT5Zw8aFiNgF for ; Fri, 31 May 2013 07:34:34 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 570CC21F918C for ; Fri, 31 May 2013 07:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=747; q=dns/txt; s=iport; t=1370010874; x=1371220474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ss2wWZ9VDQNM9Xp6htNOUJIC94XijrQQ61/8rdN/cGQ=; b=BLHaqB8RFhx34lWNY9ayeDNbf1J6ViURXxOCCgSKJfRpx3xYWOAv1Pb4 lD9ogXLSpHGHaib23Sr+deplrHzp3oqdKRxsVlZgcL74raxM5cmJZt/GF sFGkZi4qMbE+ndAmAuDpTAgq3NOwACvWpduwh9sW+/SxIYZwxPDSBhL6y k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAOOyqFGtJXG9/2dsb2JhbABagwmDJbt1gQEWdIIjAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiHfwa6Wo5pAjEHgnZhA6h+gw+CJw X-IronPort-AV: E=Sophos;i="4.87,779,1363132800"; d="scan'208";a="217199648" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 31 May 2013 14:34:34 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4VEYX8d022927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 14:34:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 31 May 2013 09:34:33 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXgv3C45MyLwwRkGGzRGA5mvi0A== Date: Fri, 31 May 2013 14:33:32 +0000 Message-ID: References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> In-Reply-To: <51A880A7.7010908@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <583931493C1C48469419A6D15044C06F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 14:34:45 -0000 On May 31, 2013, at 4:51 AM, Emil Ivov wrote: > Having extra m=3D lines, particularly when using BUNDLE, is in many ways = just extra signalling. If you'd like for that signalling to be in SDP, I do= n't see any problem with it. However it would be best for this extra layer = of SDP signalling to appear at either the application layer or in a signall= ing gateway (that is going to be there anyway). >=20 > Does this make sense? No. That does no make sense.=20 Can you please provide an specific example of what you think the SDP would = look like going across the JS API in the browser and then what the SDP at t= he applications of signaling layer would look like and how this would work = with CLUE.=20 From emil@sip-communicator.org Fri May 31 10:56:16 2013 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 1543021F8F83 for ; Fri, 31 May 2013 10:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyGOmLKOejkH for ; Fri, 31 May 2013 10:56:15 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1A621F8E79 for ; Fri, 31 May 2013 10:56:11 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so912890bkc.10 for ; Fri, 31 May 2013 10:56:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=AHU5/veni9joeHqKRCHFY4VH6CTXvjqNwx8qo6IcrVY=; b=Ey9Ehuzs2G4amQ2fq0gYGB4xTw8qn8nkqG8j3bTcoSah7GRfCRCc0t2hUYPAtTTQDS 6fXpQMJW6SLd0TvrHtu7vqeDz7dqHdiORTjcv8AkQrWCvjxtSy582s8h6+Fz6kq+ESNn nEx6lGC7w6cY9py/t0+lbMW/8ARDgX2rvnitQfoS+BRYWcJOBjRUUPiskNZ9UYVj7YoT z4RT17dM0wRqOY/+7LeZ/tvDeTxsIjyFW3aHD1heJEgbB1x1PDDl4N+gpG2j+/22kZ1S lLV2/sdp/U2o+vMkdoODLQH9sMkzZ5pQ+5UlSFMlv3DV+/hEWKt+xYBCUJJxft9GvTxZ Iapg== X-Received: by 10.205.113.16 with SMTP id eu16mr3732085bkc.109.1370022970356; Fri, 31 May 2013 10:56:10 -0700 (PDT) Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id og1sm11819674bkb.16.2013.05.31.10.56.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 10:56:09 -0700 (PDT) Message-ID: <51A8E434.1020904@jitsi.org> Date: Fri, 31 May 2013 20:56:04 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> In-Reply-To: <51A70CBC.5010108@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnjIsx1KNRqvFmMIeC+/u2jUlfCDP6bzXIwUyBNqEwzjISTdwlTdRYvJOYamvNR89qu3t2O Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 17:56:16 -0000 Hey Stefan, On 30.05.13, 11:24, Stefan H=E5kansson LK wrote: > Hi Emil, > > a couple of comments: > > "1. Expose the SSRCs of all local MediaStreamTrack-s that the > application may want to attach to a PeerConnection." > > I don't think that would be possible, or desirable. SSRC _only_ come > into play when a MediaStreamTrack is to be transported over the network= > - it is useless in local cases. And, the same local MediaStreamTrack > could be sent to several peers (using different PeerConnections) and > could have different SSRC's (and even different number of SSRC's) for > the different peers. > > I think SSRCs would only be available for MediaStreamTracks that are > attached to a PeerConnection. I believe Paul already commented on this but just to be clear: yes I=20 agree that SSRCs would only make sense for tracks that are actually=20 going on the network, so the API methods that give access to them would=20 have to take this into account. > One thing I like about Plan A and B is that the naive application > developer does not have to deal with things below MediaStream and > MediaStreamTrack level. I don't think this is any different with "No Plan". Is there a=20 particular scenario that you think would not work? > The application would simply add a MediaStream > (containing MediaStreamTracks) to the PeerConnection, do the > createOffer/setLocal and exchange signaling blobs that it need not look= > into, and the MediaStream with MediaStreamTrack's would be reflected at= > the remote end. The application would not have to deal with PT's, SSRC'= s > etc. Note that No Plan does not suggest that PT's be taken up to the=20 application. As for SSRCs, those would just serve as identifiers and=20 shouldn't bother developers that don't care about them. > I think that the "No Plan" proposal could be made similar if the info > about how MediaStreamTrack's relate to SSRC's (including those for FEC > and RTX) is exchanged using some blobs that the (naive) app can just > exchange and need not look into. I was indeed hoping that we could push FEC and RTX down to the RTP layer = for the applications that wouldn't want to be bothered. As for the SSRC, = the point of making them available to applications would be so that they = could use them so I don't think that putting them into blobs would=20 change anything. > If done that way, "No Plan" seems to me to be quite similar to Plan B, It definitely has a lot in common with Plan B, and it's all about=20 relaxing its constraints so that applications who want to handle=20 signalling a bit differently could do so. Cheers, Emil > On 2013-05-29 20:59, Emil Ivov wrote: >> Hey all, >> >> Based on many of the discussions that we've had here, as well as many >> others that we've had offlist, it seemed like a good idea to investiga= te >> a negotiation alternative that relies on SDP and Offer/Answer just a >> little bit less. >> >> The following "no plan" draft attempts to present one such approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the >> intricacies of multi-source scenarios to application-specific >> signalling, with potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the >> interoperability requirements that concerned them can still be met wit= h >> "no plan". Of course they would have to be addressed by >> application-specific signalling and/or signalling gateways. >> >> Comments are welcome! >> >> Cheers, >> Emil >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 https://jitsi.org From markybox@gmail.com Fri May 31 11:20:02 2013 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 4C2FD21F8FCB for ; Fri, 31 May 2013 11:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-tIvdLbuRUX for ; Fri, 31 May 2013 11:20:01 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id F238321F8FB3 for ; Fri, 31 May 2013 11:20:00 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so1403098veb.27 for ; Fri, 31 May 2013 11:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hwR3uDfWgWah2fVO1CeoBMdNgtcjH+ZYXrD7PRmiXgo=; b=TAfcluRsyWnO3lgsNwt9lwyeZQUDbD4wNv9aqJNyXfm9SwgYLfywVelN3BLu2Z5bNv YYIRGNCwyT+GbrDJGZ1DUM0kpDPtOM9fs7lrVLLYnTN+OMYNSS7MCPfqRA9kd3Pi6Yor 4bo57BF3UHWLcMQHMYC7Je6+m/ydaeDCzyBJu8ZnwlVNNSq+YCDpOKqOJczS0AixOMCo BTMXQlwkahnW/HUtUfx4SGBHuXLKETpUXT6B5KSqcREO7t7wG1iI9uoBZoxgeEkfQPFL yQ6QcWbD8QfOZhh7pEWTZ8l93P5uuRlNjzAJx9mr6yZD4oatTLDqzKfCaSo9zYtRPqZ8 0YNg== X-Received: by 10.220.7.134 with SMTP id d6mr11287368vcd.56.1370024400436; Fri, 31 May 2013 11:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.163 with HTTP; Fri, 31 May 2013 11:19:40 -0700 (PDT) In-Reply-To: References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> From: Mark Rejhon Date: Fri, 31 May 2013 14:19:40 -0400 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c3a5beb8c62f04de07a9ec Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 18:20:02 -0000 --001a11c3a5beb8c62f04de07a9ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 31, 2013 at 8:35 AM, I=F1aki Baz Castillo wrote= : > > Real-time text is one of the > > basic media together with audio and video which need to be fully define= d > for > > such interoperability. > > Facebook, Google+, Twitter and any other website use their own custom > mechanisms for providing chat capabilities to *their own* users > *between them*. I don't expect that they will be interested in a > peer-to-peer (user-to-user) realtime text because they want to log the > messages, inspect them, offer you advertisements based on the content > of your "private" chats, etc. > Objection, objection! They are NOT mutually exclusive. I have been in contact with Facebook as part of my XEP-0301 authorship (XMPP real-time text). See this animated GIF of Facebook real-time text concept: http://www.realjabber.org/anim/facebook_chat_concept.gif Go to http://tap.gallaudet.edu/rtt/ for an *WORKING WEB-BASED DEMO* of *GOO= GLE TALK REAL TIME TEXT* a seamless integration of real-time text into Google Talk. In fact, you can keep your GMAIL running simultaneously while you use this RTT-compatible client, and your completed line-by-line messages are still automatically logged. Real-time text *CAN* be an add-on to existing line-by-line networks. Sincerely, Mark Rejhon --001a11c3a5beb8c62f04de07a9ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 31, 2013 at 8:35 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
> =A0Real-time text is one of the
> basic media together with audio and video which need to be fully defin= ed for
> such interoperability.

Facebook, Google+, Twitter and any other website use their own custom
mechanisms for providing chat capabilities to *their own* users
*between them*. I don't expect that they will be interested in a
peer-to-peer (user-to-user) realtime text because they want to log the
messages, inspect them, offer you advertisements based on the content
of your "private" chats, etc.

Objection, objection!
They are NOT mutually exclusive.

I have been in contact with Facebook as part of my XEP-0301= authorship (XMPP real-time text).
See this animated GIF of Facebook real-time text concept:
http://w= ww.realjabber.org/anim/facebook_chat_concept.gif=A0

Go to http://tap.gallaudet.e= du/rtt/ for an WORKING WEB-BASED DEMO of GOOGLE TALK REAL TIM= E TEXT a seamless integration of real-time text into Google Talk. =A0In= fact, you can keep your GMAIL running simultaneously while you use this RT= T-compatible client, and your completed line-by-line messages are still aut= omatically logged.

Real-time text *CAN* be an add-on to existing line-by-l= ine networks.

Sincerely,
Mark Rejhon
--001a11c3a5beb8c62f04de07a9ec-- From emil@sip-communicator.org Fri May 31 11:24:06 2013 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 2AF0221F90EE for ; Fri, 31 May 2013 11:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAFIgB6852CC for ; Fri, 31 May 2013 11:24:05 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6421F9050 for ; Fri, 31 May 2013 11:24:01 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id mz10so912185bkb.11 for ; Fri, 31 May 2013 11:23:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=PZlli30GfiWIbMwr8IjFGui0tz+geIMdjJjivyufD3k=; b=kDskgs9Xihmu972Z9eH4ReU1dYdHPoce52ZjrcqMF5Wif7giQrhUXd3wX45Qzwb+HY MQR1XzeSvw9g7XwIGGD+n+Jp8PLMy5Hp8pF/O4tw8gKnJjP06k7qq4Lcu60ps6uuQZGH /GqCSd5ptbP1SoGFPnZDDcVv9/h64z3/FiaedjzyHUZzLvMlewIsFegizeqQiKNhkdxl FXXOk1zIseMRPH1qwFrNuVt9J+6U2zXGPwYDYoZejRErRm4SpM3CM9AN3qKrtFiDcfT9 xxlkVCDirqWij34nlloWugbGQF2peuz9kx9DSQNA1uw97innWZ7MyzNH0DbNUwu3ytwH RdnQ== X-Received: by 10.204.187.9 with SMTP id cu9mr3734831bkb.104.1370024635847; Fri, 31 May 2013 11:23:55 -0700 (PDT) Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id cm9sm15610174bkb.4.2013.05.31.11.23.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 11:23:55 -0700 (PDT) Message-ID: <51A8EAB7.8080206@jitsi.org> Date: Fri, 31 May 2013 21:23:51 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk8WAXKeIvD6cq3hIX5ZV/YcW1C5V5ett87aCoXd1m5wMYJxT+yH4VkqFUHTwa29z29XpWH Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 18:24:06 -0000 On 31.05.13, 17:33, Cullen Jennings (fluffy) wrote: > > On May 31, 2013, at 4:51 AM, Emil Ivov wrote: > >> Having extra m= lines, particularly when using BUNDLE, is in many >> ways just extra signalling. If you'd like for that signalling to be >> in SDP, I don't see any problem with it. However it would be best >> for this extra layer of SDP signalling to appear at either the >> application layer or in a signalling gateway (that is going to be >> there anyway). >> >> Does this make sense? > > No. That does no make sense. > > Can you please provide an specific example of what you think the SDP > would look like going across the JS API in the browser and then what > the SDP at the applications of signaling layer would look like and > how this would work with CLUE. Certainly. Could you please post the SDP that you would like to see translated in a way that's compatible with "No Plan"? Emil -- https://jitsi.org From emil@sip-communicator.org Fri May 31 11:27:19 2013 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 1EED721F9050 for ; Fri, 31 May 2013 11:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_20=-0.74, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrS+-6KNtC+4 for ; Fri, 31 May 2013 11:27:18 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3421F8FCB for ; Fri, 31 May 2013 11:27:17 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm2so917482bkc.2 for ; Fri, 31 May 2013 11:27:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=QVCeerntQ/RfFrsKOA6qSbPP16zsKzFIuHNnlPgfvuM=; b=HNgzAzYrlpEJHIzdlsJCgPx7vGWnHP54H2Rc0U1m99qsGnFwQ7IkyZarHQ2r7S0K09 rBppAxqrOrJycrTfwUzCMhBzif38MP0Y0KdD4hVFZe8TbIKKyGVH+WA0ncpmkJISlxPI BOlu8yg7gnkzZq/lPzYgSGT8YY2Zj0PieMmvF0lFfsDd4EJ5qHNwUyRFKPNoOEtaJT6b lYp8BE2ntvHREN8UZpf909mJUedszkLUYC/0m4gJUfdROdNXpcQ5PiX9JMS109ov0JS4 yLAthRPkPgIC3bIWfaq8AiF0eF2sFWDrprtr/CdOhXG9fWcjavmf3ZguwBm5b6wQEInf hS+Q== X-Received: by 10.204.172.136 with SMTP id l8mr3656285bkz.49.1370024836605; Fri, 31 May 2013 11:27:16 -0700 (PDT) Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id da16sm15604733bkb.2.2013.05.31.11.27.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 11:27:15 -0700 (PDT) Message-ID: <51A8EB7F.6000506@jitsi.org> Date: Fri, 31 May 2013 21:27:11 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <51A65017.4090502@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkpInODCrxDH2v6VdNSkk5nBGXqYKBQ0wN5MS6tCuNlbK+estQK47WJ2USHz+I/iR+KT3dh Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan - but what's the proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 18:27:19 -0000 Hey Cullen, On 30.05.13, 20:07, Cullen Jennings wrote: > Interesting draft but it seemed to have more questions about how > things would wok than answers. Let me try and ask you some specifics > to help flesh out what this plan is and offer a few comments. > > Of the actual recommendations in the draft that relate to the problem > I would summarize that draft as > > 1) demux RTP based on PT but let the application know the SSRC in > case it wants to do something more > > 2) the way the applications interacts with the browser for set up of > the media stack is via SDP > > 3) Other session control not related to the media stack is left up to > the application to do how it wants > > 4) Things like conference control and clue control and call control > should be handled by the application > > 5) you have a few avenues we might pursue for making FEC, RTC, etc > work > > 6) you have some API requirements Yes, the above seem like an accurate summary. > which, with the exception of 4 > about exposing the max number of incoming streams that can be > decoded, I think are pretty much agreed to be put put in W3C API > already. > On the topic of #4, it's a big unclear what is really needed > and ongoing discussion is happening around how do indicate what can > be received but thats a webrtc issue Then I suppose this is a good time for us to agree here on what we need the API to expose so that the underlying protocols would work. > This is very close to Plan A. I'd say it's actually closer to Plan B but Plan-A-style signalling should certainly be possible to implement by the app or a signalling gateway. > So I read the whole draft and asked > myself how is this different than plan A. What parts of this draft > would not be abel to do if we did Plan A. The part where one doesn't have to redo (and propagate) an Offer/Answer exchange every time a source is added or removed. > The only real topic I could > come up with was the port music here is PT only instead of PT + SSRC. > I'l start a separate thread on that. This is another difference indeed. > But lets ask what the proposal is for the question Plan A and Plan B > are trying to resolve. > > Let's say browse A wants to say it can send two streams of video and > here are the parameters for the video codecs for each to the streams. > What does the SDP that createOffer generates look like? There's an example in the draft. I assume the "parameters" you mention are not in there, so could you please be more specific? > I see the > draft says "strongly advises against the use of multiple m= lines for > a single media type. " but I don't really know what you mean by that. It means a browser should generate and offer that looks like this: m=audio m=video rather than an offer that looks like this m=audio m=video m=video m=video Also if one bundle is not enough to fit all payload types in the two media lines, then we split them in two. > Can you explain what you are actually proposing we do do instead of > just saying what not to do ? We create an offer that would describe the media types and the bundle. We use that offer to also describe capabilities in terms of maximum resolutions, supported header extensions, potentially max-ssrc-s, etc. It is up to the application how to handle the rest. If it needs to transmit additional signalling: let it. If it wants to encode that in SDP, great. If it wants to attach it in JSON next to the browser generated SDP, that also works. > The above paragraph is the most important part of my email. Please, > what is the proposal for what the SDP in the offer looks like. You started another thread for this, so I'll respond there. > The idea of exposing a low level API to the media stack and having > the all proposing to do FEC, RTX, SDP processing ect has been > discussed many times across the various working groups. It' jokingly > refereed to as comment 22 at this point. I appreciate you are trying to turn this into a joke (which I think is a pity provide your chairing role in this working group), but abandoning SDP really isn't what this is about. You might have noticed text about this as early as the abstract: This document does not question the use of SDP and the Offer/Answer model or the value they have in terms of interoperability with legacy or other non-WebRTC devices. Emil > It's not that it does not > have merits, but many people myself included see it as a much longer > road to get done, a lot more work, and no clear gain. One of the > other issues is we are trying to make this so you don't have to be a > telephone expert to use it and that lots of developers can use it. > I'm not going to try and summarize the low level API augments here > but if you want to discus it webrtc is the right WG. > > I'll note there are many points in the draft that I disagree > with but > I'd rather try and sort through what the actually proposal is here > before addressing any of them. > > There is one point I would like to make that is the confusion > introduced by "legacy endpoint". When I talk about legacy endpoints, > I am talking about endpoints that use SIP or Jingle and both past > ones and future endpoints. SIP will continue to evolve and I expect > WebRTC to continue being able to negotiate new features. For example, > if a SIP phone added VP9 and a browser supported VP9, I would expect > to be able to use it. The legacy refers to an older protocol, SIP, > and not to the age of the endpoint. We do know that things can't work > with all deployed endpoints and long ago we made the decision to give > up on endpoints that don't do ICE. But we do try and have a > reasonable experience with old and future endpoints. > > > On May 29, 2013, at 12:59 PM, Emil Ivov wrote: > >> Hey all, >> >> Based on many of the discussions that we've had here, as well as >> many others that we've had offlist, it seemed like a good idea to >> investigate a negotiation alternative that relies on SDP and >> Offer/Answer just a little bit less. >> >> The following "no plan" draft attempts to present one such >> approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the >> intricacies of multi-source scenarios to application-specific >> signalling, with potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the >> interoperability requirements that concerned them can still be met >> with "no plan". Of course they would have to be addressed by >> application-specific signalling and/or signalling gateways. >> >> Comments are welcome! >> >> Cheers, Emil >> >> -- https://jitsi.org >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > -- https://jitsi.org From pkyzivat@alum.mit.edu Fri May 31 12:03:18 2013 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 7B8FD21F86F5 for ; Fri, 31 May 2013 12:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxhrRnrC4gWF for ; Fri, 31 May 2013 12:03:12 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 8687221F86AE for ; Fri, 31 May 2013 12:03:12 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id ighm1l0011ap0As51j3C9z; Fri, 31 May 2013 19:03:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id ij3B1l01Q3ZTu2S3ij3BZ3; Fri, 31 May 2013 19:03:12 +0000 Message-ID: <51A8F3EF.9080702@alum.mit.edu> Date: Fri, 31 May 2013 15:03:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370026992; bh=eRFwkKMIAowE3ponEC77C5O5+vQBGhreFYcDKb7P6n0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VhUBAoGDjyvofG2rIP9UbjNMRJceuMH1ys9lNvCOKfUIjNRuYHQ6aU84DaYAS5HD0 WDQUOk/7EmoKY2QPY13z+7GImbZpsfsJrxisKeIv1XrWDnWpIZQnERu1GnrDfTFXRI DrzU3HcyunXCvwBnicqqrhpxv07PlZ0BnM+JVKbfvE6L3RFTKg4h+dcJwfRKxV9245 vfipR0FOcysJzBtpPUmWVmM2+KJJI7zKwZoc+yaSpkmEIc1ereAWMLaO8wzCQ2Oqbi deJXvSHQ0gDRHjOKT0JeLF0xszvqMtWeJA3Zu3S/+lPfW72K1f+RNh16nJbRQnOG40 ow9YtuxTaO9Cg== Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:03:18 -0000 On 5/31/13 8:35 AM, IƱaki Baz Castillo wrote: >> I do not understand why modern communication users accept to see a >> chat state indication of "composing" instead of really seeing what text is >> composed. With real-time text you get rid of the frustration that >> "composing" creates. >> Now, this was not meant to be a repetition of the motivations for real-time >> text, but a discussion on interoperability requirements and sdp handling. > > That can be implemented on top of DataChannel anyway, I see no need > for mandating it as a new RTP media stream negotiated via SDP. IIUC, Gunnar is expecting that virtually every app that provides real time voice communication should also provide RTT. (And this has a habit of showing up as a legal mandate.) Leaving the decision about how to transport RTT to be reinvented by each application doesn't seem like a good way to achieve that. If that is good enough for RTT, then why not voice and video too? Just send it over a data channel in any format you like. We don't need to standardize how to do it. Thanks, Paul From markybox@gmail.com Fri May 31 12:04:14 2013 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 0F4C621F925A for ; Fri, 31 May 2013 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELzf7Io+TYpE for ; Fri, 31 May 2013 12:04:12 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEDD21F87E0 for ; Fri, 31 May 2013 12:04:12 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id i3so1328152vbh.3 for ; Fri, 31 May 2013 12:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=IpJe7ET869XbXlqywUmf9XYlX/2Hpw1JHoQmVpnQRvQ=; b=aqcIkNI9L+1wbgYoQ/kpqi7+9k7l4XoOWkAtoyry33UHM7ggTjD4jiEYugdnzrcn7B SdMNaXLmVbBqoLfbigNS1fINYKOV5+Yx7FAHXaacE342+HD5XyjQ7nBp9CIhaEIIDaBx t+WK9Dq74ipZ0Z/Zck8BGH2BAoMO+9iy94VdCYv2Ndg/Bm4KtSwdmPOAmnNIvES96i9p bsNf2zTM2+Nq6xLzvCO2Fz1k5NNKLld9DbxTsuUWFU69QGrElnmZoaTXWQiF1D0oKdRY K95+fqVcKjAd5g5lL2JLFce8er9Rk/vih/5NznnfDjH3+tgiukGLLm4cO/l/Y0tJuPHA GIvQ== X-Received: by 10.52.159.72 with SMTP id xa8mr9772272vdb.48.1370027052013; Fri, 31 May 2013 12:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.163 with HTTP; Fri, 31 May 2013 12:03:51 -0700 (PDT) From: Mark Rejhon Date: Fri, 31 May 2013 15:03:51 -0400 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e0160bf48c4a3fe04de084765 Cc: "rtcweb@ietf.org" Subject: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:04:14 -0000 --089e0160bf48c4a3fe04de084765 Content-Type: text/plain; charset=ISO-8859-1 Although this is not 100% webrtc related, it has implications, since Gunnar (RFC4103) worked with me as the co-author of XEP-0301, so I want to write this to help people understand that RTT is not necessarily always peer-to-peer. -- Federated network-to-network compatible. Anything federated will interop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RTT) Neat Demonstration of XEP-0301 interoperability in multiple XMPP clients (including non-RTT) *This is a live demonstration of non-peer-to-peer RTT*, but broadcast RTT sent through the same channels as full messages. On one account on one computer, run two browser windows simultaneously: *1. Log onto your Google Talk via GMAIL account at http://www.gmail.com * *2. Log onto your Google Talk via Gallaudet University's implementation: http://tap.gallaudet.edu/rtt/ ... (Same account) * On a different account on a different computer: *3. On a separate computer, log using a different, separate Google account at http://tap.gallaudet.edu/rtt/ (or use any RTT client such as the RealJabber.org client)* Observe the following interoperability: -- You can message from any #1, #2, or #3. -- Completed messages from #1/#2 (simultaneously logged into same account) will reach #3 and vice-versa -- Messages from #3 will reach both #1 and #2 simultaneously. -- Real-time text doesn't show up in GMAIL, but does show up in RTT-compatible clients -- GMAIL keeps working merrily along, logging & archiving the completed messages. GMAIL silently ignores the extraneous RTT XML Observe that: -- Everything is routed through unmodified XMPP servers -- No server modifications -- Not peer-to-peer. No direct connections. No firewall worries. -- If full messages make it through, real-time text also makes it through. -- Federated network-to-network compatible. Anything federated will interop with each other for RTT. -- One end can be a jabber.org account, another end can be a Cisco WebEx account (if federated). An RTT-enhanced Lync client transmits RTT to an RTT-enhanced WebEx. Yes, federation is being abandoned by Google -- but others aren't. You can still test RTT over federation between jabber.organd gmail.com using two separate copies of RealJabber.org client -- it works! It bridges the mainstream and accessibility. I got feedback for my XEP-0301 specification from several people at Microsoft (including Bernard Aboba), Facebook (Name requested to be private), Cisco (Paul E. Jones), and others. See the names at http://xmpp.org/extensions/xep-0301.html#acknowledgments. So you see, big names are on real-time text already on a 10-year roadmap. It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g. environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). It is also used for transmission of live speech transcription. It can also be turned on/off, for privacy considerations, and when you're not in as a chatty mood. It also proved more popular and appealing than video: When I did a test among family and friends, when taught about real-time text ( http://www.fasttext.org -- The International Symbol of Real-Time Text), more people enabled the RTT feature than the video feature. There is potential for RTT to be more popular than video, once people are more fully familiar with the feature, and when it's not intrusive (e.g. easy to turn on/off) -- Gunnar Helstrom has also developed a bridge that fills the gap between RFC4103 and XEP-0301 -- Vint Cerf received an accessibility demonstration involving real-time text demonstration as part of Raising The Floor, by Gregg Vanderheiden. -- Real-time text was demonstrated at FCC text-to-911 as a standardized add-on to line-by-line SMS text messaging. I developed a method of presenting real-time text smoothly (non-bursty) despite only 1 packet every second, or every 2 seconds: http://www.realjabber.org/anim/real_time_text_demo.gif Observe that the key press intervals are successfully (optionally) preserved. (Many deafies like the natural typing feel) It also can support word-at-a-time buffering, for those people who hate watching typing mistakes. Closed captioning was thought of as a luxury in 1970's. Now it's built into TV's. Mainstream loves captioning nowadays. In 10 years from now, this could become a mainstream feature. It may not happen in 3 years, maybe not even 5 years. But there is movement behind the scenes. It is important to understand the implications of real-time text and its ability to be 100% seamlessly compatible with existing messaging networks, potentially as a more popular optional feature than Video. Sincerely, Mark Rejhon --089e0160bf48c4a3fe04de084765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Although this is not 100% webrtc related, it has implications, since Gunnar= (RFC4103) worked with me as the co-author of XEP-0301, so I want to write = this to help people understand that RTT is not necessarily always peer-to-p= eer.
-- Federated network-to-network compatible. =A0 =A0Anything federated = will interop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RT= T)

Neat Demonstration of XEP-0301 interoperability= in multiple XMPP clients (including non-RTT)
This is a live demonstration of non-peer-to-peer RTT, but broadcast = RTT sent through the same channels as full messages.

On one account on one computer, run two browser windows simultaneously:
1. Log onto your Google Talk via GMAIL account at http://www.gmail.com=A0
2. Log onto yo= ur Google Talk via Gallaudet University's implementation: http://tap.gallaudet.edu/rtt/ ... (Same ac= count)=A0

On a different account on a different computer:
3. On a separate computer, log using a different, separate Google acc= ount at=A0http://tap.gallaudet.ed= u/rtt/=A0(or use any RTT client such as the RealJabber.org client)<= /div>

Observe the following interoperability:
-- Yo= u can message from any #1, #2, or #3.
-- Completed messages from = #1/#2 (simultaneously logged into same account) will reach #3 and vice-vers= a
-- Messages from #3 will reach both #1 and #2 simultaneously.
-- Real-time text doesn't show up in GMAIL, but does show up in RTT-c= ompatible clients
-- GMAIL keeps working merrily along, log= ging & archiving the completed messages. =A0GMAIL silently ignores the = extraneous RTT XML

Observe that:
-- Everything is routed th= rough unmodified XMPP servers
-- No server modifications =A0
-- Not peer-to-peer. =A0No direct connections. =A0No firewall worries= .=A0
-- If full messages make it through, real-time text also makes it thro= ugh.
-- Federated network-to-network compatible. =A0 =A0Anything = federated will interop with each other for RTT.
-- One end can be= a jabber.org account, another end can be= a Cisco WebEx account (if federated). =A0 An RTT-enhanced Lync client tran= smits RTT to an RTT-enhanced WebEx. =A0 =A0Yes, federation is being abandon= ed by Google -- but others aren't. =A0You can still test RTT over feder= ation between jabber.org and gmail.com using two separate copies of RealJabber.org = client -- it works!

It bridges the mainstream and accessibility= . =A0 I got feedback for my XEP-0301 specification from several people at M= icrosoft (including Bernard Aboba), Facebook (Name requested to be private)= , Cisco (Paul E. Jones), and others. =A0See the names at http://xmpp.org/extensio= ns/xep-0301.html#acknowledgments.=A0 So you see, big names are on real-= time text already on a 10-year roadmap.

It allows text to be used as conversationally as a tele= phone conversation, including in situations where speech is not practical (= e.g. environments that must be quiet, environments too noisy to hear, restr= ictions on phone use, situations where speaking is a privacy or security co= ncern, and/or when participant(s) are deaf or hard of hearing). It is also = used for transmission of live speech transcription. =A0
It can also be turned on/off, for privacy considerations, and when you= 're not in as a chatty mood.

It also proved more popular = and appealing than video: When I did a test among family and friends, when = taught about real-time text ( http://ww= w.fasttext.org -- The International Symbol of Real-Time Text), more peo= ple enabled the RTT feature than the video feature. =A0There is potential f= or RTT to be more popular than video, once people are more fully familiar w= ith the feature, and when it's not intrusive (e.g. easy to turn on/off)=

-- Gunnar Helstrom has also developed a bridge that fil= ls the gap between RFC4103 and XEP-0301
-- Vint Cerf received an = accessibility demonstration involving real-time text demonstration as part = of Raising The Floor, by Gregg Vanderheiden.
-- Real-time text was demonstrated at FCC text-to-911 as a standardize= d add-on to line-by-line SMS text messaging. =A0

I= developed a method of presenting real-time text smoothly (non-bursty) desp= ite only 1 packet every second, or every 2 seconds:
htt= p://www.realjabber.org/anim/real_time_text_demo.gif=A0
Observe that = the key press intervals are successfully (optionally) preserved. =A0(Many d= eafies like the natural typing feel)
It also can support word-at-a-time buffering, for those people who hat= e watching typing mistakes.

Closed captioning was = thought of as a luxury in 1970's. =A0Now it's built into TV's. = =A0Mainstream loves captioning nowadays. =A0 In 10 years from now, this cou= ld become a mainstream feature. =A0It may not happen in 3 years, maybe not = even 5 years. =A0But there is movement behind the scenes. =A0It is importan= t to understand the implications of real-time text and its ability to be 10= 0% seamlessly compatible with existing messaging networks, potentially as a= more popular optional feature than Video.

Sincerely,
Mark Rejhon
--089e0160bf48c4a3fe04de084765-- From bernard_aboba@hotmail.com Fri May 31 12:09:58 2013 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 2439D21F99B3 for ; Fri, 31 May 2013 12:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOAyuSfbk2Nv for ; Fri, 31 May 2013 12:09:54 -0700 (PDT) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by ietfa.amsl.com (Postfix) with ESMTP id A24EF21F92C5 for ; Fri, 31 May 2013 12:09:50 -0700 (PDT) Received: from BLU169-W71 ([65.55.111.137]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 31 May 2013 12:09:49 -0700 X-TMN: [pwaPbZ76iL5kaP0sZGdcBeJqI7ssQCCF] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9b3daf0c-6f59-402c-90b8-0146721b67e1_" From: Bernard Aboba To: Mark Rejhon Date: Fri, 31 May 2013 12:09:49 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 31 May 2013 19:09:49.0607 (UTC) FILETIME=[6C251B70:01CE5E32] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:09:58 -0000 --_9b3daf0c-6f59-402c-90b8-0146721b67e1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks=2C Mark. could you say a few words about the status of the XEP-0301= JavaScript implementation? As I understand it=2C this was done as an exte= nsion to Strophe=2C which now supports the XMPP over Websockets draft in th= e beta builds. =20 =20 From: markybox@gmail.com Date: Fri=2C 31 May 2013 15:03:51 -0400 To: ibc@aliax.net CC: rtcweb@ietf.org Subject: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT= (for future webrtc standardization purposes) Although this is not 100% webrtc related=2C it has implications=2C since Gu= nnar (RFC4103) worked with me as the co-author of XEP-0301=2C so I want to = write this to help people understand that RTT is not necessarily always pee= r-to-peer. =0A= =0A= -- Federated network-to-network compatible. Anything federated will inte= rop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RTT) Neat Demonstration of XEP-0301 interoperability in multiple XMPP clients (i= ncluding non-RTT)=0A= =0A= This is a live demonstration of non-peer-to-peer RTT=2C but broadcast RTT s= ent through the same channels as full messages. On one account on one computer=2C run two browser windows simultaneously:= =0A= =0A= 1. Log onto your Google Talk via GMAIL account at http://www.gmail.com 2. L= og onto your Google Talk via Gallaudet University's implementation: http://= tap.gallaudet.edu/rtt/ ... (Same account) =0A= =0A= On a different account on a different computer:3. On a separate computer=2C= log using a different=2C separate Google account at http://tap.gallaudet.e= du/rtt/ (or use any RTT client such as the RealJabber.org client)=0A= =0A= Observe the following interoperability:-- You can message from any #1=2C #2= =2C or #3.-- Completed messages from #1/#2 (simultaneously logged into same= account) will reach #3 and vice-versa=0A= =0A= -- Messages from #3 will reach both #1 and #2 simultaneously.-- Real-time t= ext doesn't show up in GMAIL=2C but does show up in RTT-compatible clients-= - GMAIL keeps working merrily along=2C logging & archiving the completed me= ssages. GMAIL silently ignores the extraneous RTT XML=0A= =0A= Observe that:-- Everything is routed through unmodified XMPP servers-- No s= erver modifications -- Not peer-to-peer. No direct connections. No firew= all worries. =0A= =0A= -- If full messages make it through=2C real-time text also makes it through= .-- Federated network-to-network compatible. Anything federated will int= erop with each other for RTT.-- One end can be a jabber.org account=2C anot= her end can be a Cisco WebEx account (if federated). An RTT-enhanced Lync= client transmits RTT to an RTT-enhanced WebEx. Yes=2C federation is bei= ng abandoned by Google -- but others aren't. You can still test RTT over f= ederation between jabber.org and gmail.com using two separate copies of Rea= lJabber.org client -- it works!=0A= =0A= It bridges the mainstream and accessibility. I got feedback for my XEP-03= 01 specification from several people at Microsoft (including Bernard Aboba)= =2C Facebook (Name requested to be private)=2C Cisco (Paul E. Jones)=2C and= others. See the names at http://xmpp.org/extensions/xep-0301.html#acknowl= edgments. So you see=2C big names are on real-time text already on a 10-ye= ar roadmap.=0A= =0A= It allows text to be used as conversationally as a telephone conversation= =2C including in situations where speech is not practical (e.g. environment= s that must be quiet=2C environments too noisy to hear=2C restrictions on p= hone use=2C situations where speaking is a privacy or security concern=2C a= nd/or when participant(s) are deaf or hard of hearing). It is also used for= transmission of live speech transcription. =0A= =0A= It can also be turned on/off=2C for privacy considerations=2C and when you'= re not in as a chatty mood. It also proved more popular and appealing than video: When I did a test amo= ng family and friends=2C when taught about real-time text ( http://www.fast= text.org -- The International Symbol of Real-Time Text)=2C more people enab= led the RTT feature than the video feature. There is potential for RTT to = be more popular than video=2C once people are more fully familiar with the = feature=2C and when it's not intrusive (e.g. easy to turn on/off)=0A= =0A= -- Gunnar Helstrom has also developed a bridge that fills the gap between R= FC4103 and XEP-0301-- Vint Cerf received an accessibility demonstration inv= olving real-time text demonstration as part of Raising The Floor=2C by Greg= g Vanderheiden.=0A= =0A= -- Real-time text was demonstrated at FCC text-to-911 as a standardized add= -on to line-by-line SMS text messaging. =20 I developed a method of presenting real-time text smoothly (non-bursty) des= pite only 1 packet every second=2C or every 2 seconds:=0A= =0A= http://www.realjabber.org/anim/real_time_text_demo.gif=20 Observe that the key press intervals are successfully (optionally) preserve= d. (Many deafies like the natural typing feel)=0A= =0A= It also can support word-at-a-time buffering=2C for those people who hate w= atching typing mistakes. Closed captioning was thought of as a luxury in 1970's. Now it's built int= o TV's. Mainstream loves captioning nowadays. In 10 years from now=2C th= is could become a mainstream feature. It may not happen in 3 years=2C mayb= e not even 5 years. But there is movement behind the scenes. It is import= ant to understand the implications of real-time text and its ability to be = 100% seamlessly compatible with existing messaging networks=2C potentially = as a more popular optional feature than Video.=0A= =0A= Sincerely=2CMark Rejhon=0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb = --_9b3daf0c-6f59-402c-90b8-0146721b67e1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks=2C =3BMark. =3B c= ould you say a few words about =3Bthe status of the XEP-0301 JavaScript= implementation? =3B As I understand it=2C this was done as an extensio= n to Strophe=2C which now supports the XMPP over =3BWebsockets draft in= the beta builds. =3B
 =3B
From= : markybox@gmail.com
Date: Fri=2C 31 May 2013 15:03:51 -0400
To: ibc@= aliax.net
CC: rtcweb@ietf.org
Subject: [rtcweb] RTT Education: Neat D= emonstration of NON-peer-to-peer RTT (for future webrtc standardization pur= poses)

Although this is not 100% webrtc related=2C it has implicatio= ns=2C since Gunnar (RFC4103) worked with me as the co-author of XEP-0301=2C= so I want to write this to help people understand that RTT is not necessar= ily always peer-to-peer.
=0A= =0A=
-- Federated network-to-network compatible.  =3B  =3BAnything = federated will interop with each other for RTT. (e.g. Lync RTT reaches Cisc= o WebEx RTT)

Neat Demonstration of XEP-0301 intero= perability in multiple XMPP clients (including non-RTT)
=0A= =0A= This is a live demonstration of non-peer-to-peer RTT=2C but broadcas= t RTT sent through the same channels as full messages.

On one account on one computer=2C run two browser windows simultaneously= :
=0A= =0A=
1. Log onto your Google Talk via GMAIL account at http://www.gmail.com =3B
2. Log onto your Google Talk via Gallaudet University's implementa= tion: http://ta= p.gallaudet.edu/rtt/ ... (Same account) =3B
=0A= =0A=

On a different account on a different computer:
3. On a separate computer=2C log using a different=2C separate Google= account at =3Bhttp://tap.gallaudet.edu/rtt/ =3B(or use any RTT client such as= the RealJabber.org client)
=0A= =0A=

Observe the following interoperability:
-- Yo= u can message from any #1=2C #2=2C or #3.
-- Completed messages f= rom #1/#2 (simultaneously logged into same account) will reach #3 and vice-= versa
=0A= =0A=
-- Messages from #3 will reach both #1 and #2 simultaneously.
-- Real-time text doesn't show up in GMAIL=2C but does show up in RTT-com= patible clients
-- GMAIL keeps working merrily along=2C log= ging &=3B archiving the completed messages.  =3BGMAIL silently ignor= es the extraneous RTT XML
=0A= =0A=

Observe that:
-- Everything is routed th= rough unmodified XMPP servers
-- No server modifications  =3B=
-- Not peer-to-peer.  =3BNo direct connections.  =3BNo f= irewall worries. =3B
=0A= =0A=
-- If full messages make it through=2C real-time text also makes it th= rough.
-- Federated network-to-network compatible.  =3B  = =3BAnything federated will interop with each other for RTT.
=0A= =0A=

It bridges the mainstream and accessibility= .  =3B I got feedback for my XEP-0301 specification from several people= at Microsoft (including Bernard Aboba)=2C Facebook (Name requested to be p= rivate)=2C Cisco (Paul E. Jones)=2C and others.  =3BSee the names at http://xmpp.org/extensions/xep-0301.html#acknowledgments.&n= bsp=3B So you see=2C big names are on real-time text already on a 10-year r= oadmap.
=0A= =0A=

It allows text to be used as conversationally as a tele= phone conversation=2C including in situations where speech is not practical= (e.g. environments that must be quiet=2C environments too noisy to hear=2C= restrictions on phone use=2C situations where speaking is a privacy or sec= urity concern=2C and/or when participant(s) are deaf or hard of hearing). I= t is also used for transmission of live speech transcription.  =3B=0A= =0A=
It can also be turned on/off=2C for privacy considerations=2C and when= you're not in as a chatty mood.

It also proved more popular = and appealing than video: When I did a test among family and friends=2C whe= n taught about real-time text ( http://www.fasttext.org -- The International Symbol of Real= -Time Text)=2C more people enabled the RTT feature than the video feature. =  =3BThere is potential for RTT to be more popular than video=2C once pe= ople are more fully familiar with the feature=2C and when it's not intrusiv= e (e.g. easy to turn on/off)
=0A= =0A=

-- Gunnar Helstrom has also developed a bridge that fil= ls the gap between RFC4103 and XEP-0301
-- Vint Cerf received an = accessibility demonstration involving real-time text demonstration as part = of Raising The Floor=2C by Gregg Vanderheiden.
=0A= =0A=
-- Real-time text was demonstrated at FCC text-to-911 as a standardize= d add-on to line-by-line SMS text messaging.  =3B

<= div>I developed a method of presenting real-time text smoothly (non-bursty)= despite only 1 packet every second=2C or every 2 seconds:
=0A= =0A=
http://www.realjabber.org/anim/real_time_text_demo.gif&n= bsp=3B
Observe that the key press intervals are successfully (optionally= ) preserved.  =3B(Many deafies like the natural typing feel)
=0A= =0A=
It also can support word-at-a-time buffering=2C for those people who h= ate watching typing mistakes.

Closed captioning wa= s thought of as a luxury in 1970's.  =3BNow it's built into TV's.  = =3BMainstream loves captioning nowadays.  =3B In 10 years from now=2C t= his could become a mainstream feature.  =3BIt may not happen in 3 years= =2C maybe not even 5 years.  =3BBut there is movement behind the scenes= .  =3BIt is important to understand the implications of real-time text = and its ability to be 100% seamlessly compatible with existing messaging ne= tworks=2C potentially as a more popular optional feature than Video.
= =0A= =0A=

Sincerely=2C
Mark Rejhon
=0A=
_______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb
= --_9b3daf0c-6f59-402c-90b8-0146721b67e1_-- From pkyzivat@alum.mit.edu Fri May 31 12:11:27 2013 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 ABBFC21F992C for ; Fri, 31 May 2013 12:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw-R6YgPflDz for ; Fri, 31 May 2013 12:11:23 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id EE55421F99C3 for ; Fri, 31 May 2013 12:11:21 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id ihww1l0041vXlb85AjBM3Z; Fri, 31 May 2013 19:11:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id ijBM1l00Q3ZTu2S3djBMid; Fri, 31 May 2013 19:11:21 +0000 Message-ID: <51A8F5D8.8070602@alum.mit.edu> Date: Fri, 31 May 2013 15:11:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> In-Reply-To: <51A880A7.7010908@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370027481; bh=xTVkW5vJqG6mLiC66mSNfz9du5iOXsH905xEXtSl8PM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qVYyM/ci7uBiaBNyPzB0VNhNgg7i+0l0aqWqpiheKzfP2RvhcUZDhbS67kEFFvXTH Kj1kXNjbM7Ag5G+4wjYBn/7OdHR0wsBWYqtfAdZm6xejOVU6NuH3IVojvIaJyJeoEb fMILISWYs7wZDMZMwSjEILqQMvkxvMgMOOY4u24AtsSjOOQeOkMSigl1upE3B4feSN atU8z/kxjDI2Av5jReCReGTCCFSyNBjy4VeHTuRulWRfngCleakDY3zcqLjA26XWe1 BAkX7vYfx6dfDiWEyy/SPZcI3R1nZ5dgB/n31B/9ltcXDH1px7SyZbImdfqJHokiSr 4X5JQfKtJHEMQ== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:11:27 -0000 On 5/31/13 6:51 AM, Emil Ivov wrote: > Hey Paul, > > On 29.05.13, 22:57, Paul Kyzivat wrote: >> Emil, >> >> I'm going to reserve judgment on this pending further discussion. >> I think this *might* work for CLUE, but I want to be certain. > > Sure! > >> I'm concerned with decomposed endpoints that can't manage all the >> streams on the same address/port. They will need multiple independent >> m-lines and/or bundle groups. > > This is obviously open for debate but the general idea of No Plan is > that: Offer/Answer is used for configuring media and RTP stacks and > additional signalling is not the browser's concern. > > Having extra m= lines, particularly when using BUNDLE, is in many ways > just extra signalling. You may be able to argue that adding extra m-lines into an existing bundle is "just extra signaling". But introducing an additional 5-tuple is more substantial. It requires configuring a new RTP stack and media. Thanks, Paul > If you'd like for that signalling to be in SDP, I > don't see any problem with it. However it would be best for this extra > layer of SDP signalling to appear at either the application layer or in > a signalling gateway (that is going to be there anyway). > > Does this make sense? > > Emil > >> >> Further questions: >> >> I presume that you expect bandwidth in the SDP to be an aggregate >> per-m-line, with application specific signaling for bandwidth at the >> per-RTP-stream level? >> >> Thanks, >> Paul >> >> On 5/29/13 2:59 PM, Emil Ivov wrote: >>> Hey all, >>> >>> Based on many of the discussions that we've had here, as well as many >>> others that we've had offlist, it seemed like a good idea to investigate >>> a negotiation alternative that relies on SDP and Offer/Answer just a >>> little bit less. >>> >>> The following "no plan" draft attempts to present one such approach: >>> >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>> >>> The draft relies on conventional use of SDP O/A but leaves the >>> intricacies of multi-source scenarios to application-specific >>> signalling, with potentially a little help from RTP. >>> >>> Hopefully, proponents of Plans A and B would find that the >>> interoperability requirements that concerned them can still be met with >>> "no plan". Of course they would have to be addressed by >>> application-specific signalling and/or signalling gateways. >>> >>> Comments are welcome! >>> >>> Cheers, >>> Emil >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> . >> > From fluffy@cisco.com Fri May 31 12:20:38 2013 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 16AF521F898B for ; Fri, 31 May 2013 12:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+T6EH1cc7kA for ; Fri, 31 May 2013 12:20:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C121F894E for ; Fri, 31 May 2013 12:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1108; q=dns/txt; s=iport; t=1370028032; x=1371237632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TtG74m1hJDDMtGdCXvXA/AYIvG+nvFuosfq6g7a+jBo=; b=mksTymDIhEAPEc9wla0FVoA/4usECbLK69lNN98uWviroJ64R0SEJXeo CrClLABFhnAKWBMim8L5K5yuD9qGaiMVuUdpNAz+uTrTh0p1wmexxj5Rw EPWmBlOxyE6R+AUrs6GqklHFyH2ry9wVgdckH2/CHlof3jzX12V8HKY09 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIFAKz2qFGtJXHA/2dsb2JhbABZgwm/HoEDFnSCIwEBAQMBeQULAgEIDgoKJDIlAgQOBQiHfwa6MI5uAjEHgnZhA4hooBaDD4In X-IronPort-AV: E=Sophos;i="4.87,780,1363132800"; d="scan'208";a="217377243" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 31 May 2013 19:20:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4VJKVqp002947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 19:20:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 31 May 2013 14:20:31 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXiwEjuCu1hdg9k2txPBXuLNWSpkf/00A Date: Fri, 31 May 2013 19:19:29 +0000 Message-ID: References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> In-Reply-To: <51A8EAB7.8080206@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <904A9D00A18F9B469C2D76E78682735C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:20:38 -0000 On May 31, 2013, at 12:23 PM, Emil Ivov wrote: > On 31.05.13, 17:33, Cullen Jennings (fluffy) wrote: >>=20 >> On May 31, 2013, at 4:51 AM, Emil Ivov wrote: >>=20 >>> Having extra m=3D lines, particularly when using BUNDLE, is in many >>> ways just extra signalling. If you'd like for that signalling to be >>> in SDP, I don't see any problem with it. However it would be best >>> for this extra layer of SDP signalling to appear at either the >>> application layer or in a signalling gateway (that is going to be >>> there anyway). >>>=20 >>> Does this make sense? >>=20 >> No. That does no make sense. >>=20 >> Can you please provide an specific example of what you think the SDP >> would look like going across the JS API in the browser and then what >> the SDP at the applications of signaling layer would look like and >> how this would work with CLUE. >=20 > Certainly. Could you please post the SDP that you would like to see trans= lated in a way that's compatible with "No Plan"? >=20 > Emil We can start with the SDP in plan A From adam@nostrum.com Fri May 31 12:22:17 2013 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 21FBF21F8B64 for ; Fri, 31 May 2013 12:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UylYCrtN9wm8 for ; Fri, 31 May 2013 12:22:15 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD2A21F898B for ; Fri, 31 May 2013 12:22:15 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4VJM8NE027813 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 31 May 2013 14:22:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51A8F85F.4090900@nostrum.com> Date: Fri, 31 May 2013 14:22:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mark Rejhon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:22:17 -0000 Mark: This is all very neat. To be clear about what's being shown here: * This does not use RFC 4103 RTT-over-RTP * This text is transmitted over a traditional XMPP client->server->server->client architecture Correct? If so -- and if this is being held out as a preferred technology for RTT -- then this is great news. As is shown by numerous live deployments (Gmail, Facebook, LiveJournal IM, etc), the model of [JS Client]->[Web Server]->[XMPP Server]->[XMPP Client] works quite well, and has been supported by existing web technologies since at least 2006. I'm glad to have a demonstration that this is a solved problem that we don't need to make special provisions for. Thanks. /a On 5/31/13 14:03, Mark Rejhon wrote: > Although this is not 100% webrtc related, it has implications, since > Gunnar (RFC4103) worked with me as the co-author of XEP-0301, so I > want to write this to help people understand that RTT is not > necessarily always peer-to-peer. > -- Federated network-to-network compatible. Anything federated will > interop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RTT) > > Neat Demonstration of XEP-0301 interoperability in multiple XMPP > clients (including non-RTT) > *This is a live demonstration of non-peer-to-peer RTT*, but broadcast > RTT sent through the same channels as full messages. > > On one account on one computer, run two browser windows simultaneously: > *1. Log onto your Google Talk via GMAIL account at http://www.gmail.com * > *2. Log onto your Google Talk via Gallaudet University's > implementation: http://tap.gallaudet.edu/rtt/ ... (Same account) * > > On a different account on a different computer: > *3. On a separate computer, log using a different, separate Google > account at http://tap.gallaudet.edu/rtt/ (or use any RTT client such > as the RealJabber.org client)* > > Observe the following interoperability: > -- You can message from any #1, #2, or #3. > -- Completed messages from #1/#2 (simultaneously logged into same > account) will reach #3 and vice-versa > -- Messages from #3 will reach both #1 and #2 simultaneously. > -- Real-time text doesn't show up in GMAIL, but does show up in > RTT-compatible clients > -- GMAIL keeps working merrily along, logging & archiving the > completed messages. GMAIL silently ignores the extraneous RTT XML > > Observe that: > -- Everything is routed through unmodified XMPP servers > -- No server modifications > -- Not peer-to-peer. No direct connections. No firewall worries. > -- If full messages make it through, real-time text also makes it through. > -- Federated network-to-network compatible. Anything federated will > interop with each other for RTT. > -- One end can be a jabber.org account, another > end can be a Cisco WebEx account (if federated). An RTT-enhanced > Lync client transmits RTT to an RTT-enhanced WebEx. Yes, federation > is being abandoned by Google -- but others aren't. You can still test > RTT over federation between jabber.org and > gmail.com using two separate copies of > RealJabber.org client -- it works! > > It bridges the mainstream and accessibility. I got feedback for my > XEP-0301 specification from several people at Microsoft (including > Bernard Aboba), Facebook (Name requested to be private), Cisco (Paul > E. Jones), and others. See the names at > http://xmpp.org/extensions/xep-0301.html#acknowledgments. So you see, > big names are on real-time text already on a 10-year roadmap. > > It allows text to be used as conversationally as a telephone > conversation, including in situations where speech is not practical > (e.g. environments that must be quiet, environments too noisy to hear, > restrictions on phone use, situations where speaking is a privacy or > security concern, and/or when participant(s) are deaf or hard of > hearing). It is also used for transmission of live speech transcription. > It can also be turned on/off, for privacy considerations, and when > you're not in as a chatty mood. > > It also proved more popular and appealing than video: When I did a > test among family and friends, when taught about real-time text ( > http://www.fasttext.org -- The International Symbol of Real-Time > Text), more people enabled the RTT feature than the video feature. > There is potential for RTT to be more popular than video, once people > are more fully familiar with the feature, and when it's not intrusive > (e.g. easy to turn on/off) > > -- Gunnar Helstrom has also developed a bridge that fills the gap > between RFC4103 and XEP-0301 > -- Vint Cerf received an accessibility demonstration involving > real-time text demonstration as part of Raising The Floor, by Gregg > Vanderheiden. > -- Real-time text was demonstrated at FCC text-to-911 as a > standardized add-on to line-by-line SMS text messaging. > > I developed a method of presenting real-time text smoothly > (non-bursty) despite only 1 packet every second, or every 2 seconds: > http://www.realjabber.org/anim/real_time_text_demo.gif > Observe that the key press intervals are successfully (optionally) > preserved. (Many deafies like the natural typing feel) > It also can support word-at-a-time buffering, for those people who > hate watching typing mistakes. > > Closed captioning was thought of as a luxury in 1970's. Now it's > built into TV's. Mainstream loves captioning nowadays. In 10 years > from now, this could become a mainstream feature. It may not happen > in 3 years, maybe not even 5 years. But there is movement behind the > scenes. It is important to understand the implications of real-time > text and its ability to be 100% seamlessly compatible with existing > messaging networks, potentially as a more popular optional feature > than Video. > > Sincerely, > Mark Rejhon > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri May 31 12:27:32 2013 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 79FE621F9133 for ; Fri, 31 May 2013 12:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rr7O-pkHHji for ; Fri, 31 May 2013 12:27:26 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ECE5D21F8F0C for ; Fri, 31 May 2013 12:27:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-b4-51a8f99c0396 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 16.2F.15700.C99F8A15; Fri, 31 May 2013 21:27:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Fri, 31 May 2013 21:27:24 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: What the plans expect to receive Thread-Index: AQHOXjPbdxnAPsh8f0qlR4WWmEArPg== Date: Fri, 31 May 2013 19:27:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37FF62@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre6cnysCDS7dVrFY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGTcmrWEv6GCr2LnuNmsD402WLkZODgkBE4n7M3YwQ9hiEhfu rWfrYuTiEBI4zCjRvvAFK4SzhFHi/fo5QFUcHGwCFhLd/7RBGkQE1CUuP7zADmILC2hKbG6c AlYiIqAn0fS5DqIEyLw5EWwXi4CqxJ/W5awgNq+Ar8TTvevAWhmB9n4/tYYJxGYWEJe49WQ+ E8Q9AhJL9pyHuk1U4uXjf6wg4yUEFCWW98tBlOtILNj9iQ3C1pZYtvA1M8R4QYmTM5+wTGAU noVk6iwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZgCB/c8lt3B+OpcyKHGKU5WJTEefV4FwcK CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOSIm2RqWHzZ71uLZyPzg5BD9yMr1pa7HhFrqbiv pT5Z6oGIrk9OUXXkv/OfDl6I31XNJWdQH6fRaX+e/1yPTOzmlwZy3qv+zDgiEvRIX9hh4qzL B3NONDd/ntxQWO0b7ZlmX2yg9XqjTuT3qJ7N0fmJbCKznVcvfcHSqfWs/cyau0VSFesnKrEU ZyQaajEXFScCAA19ueQvAgAA Subject: [rtcweb] What the plans expect to receive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:27:32 -0000 Hi, The plans we have on the table describe different ways how a browser will c= reate SDP Offers. My question is: is the assumption also that a browser will also RECEIVE SDP= Offers in that format? =20 For example, if I have a JS APP speaking SIP with a legacy entity, and it r= eceives an SDP Offer on the wire, does the JS APP need to "convert" the SDP= into the "format" described in the whatever-plan-we-will-choose before giv= ing it to the browser? IF so, assuming we go ahead with "No Plan", if my JS APP receives on SDP Of= fer with 2 video m- lines over the wire, the JS APP would somehow have to c= onvert that into a single video m- line, because the "No Plan" draft curren= tly says "one m- line per media type". Regards, Christer From markybox@gmail.com Fri May 31 12:32:21 2013 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 0609221F853A for ; Fri, 31 May 2013 12:32:21 -0700 (PDT) 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=[AWL=1.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beskIn52Snwg for ; Fri, 31 May 2013 12:32:20 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2221F8319 for ; Fri, 31 May 2013 12:32:20 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p13so1296820vbe.26 for ; Fri, 31 May 2013 12:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ARCld37uDJkGRSlZVFmye7vNZDZKGMMdvrfaTdFIP2A=; b=qrSy8DGQGxf2EP2FgAUqzD1sGnmYiFKlbT+CQYq95SaJnBlYw/R5uSFvpLPm0Pmxq8 KcVslK03hAL2ka/3dcf+hPdUdlPDBBthMZpz8ClcIhv9aQ9TsZjrgbH6RoXRbhQEHynP Qr0WUy3V1hoUSxG1AWFUO8ZkGWuU72z+rQqLr0+iRzqTtjUScpk/9ZPlYx9GXvFBlcuq /xsk4XcWHzN4nkmVuffz50gZ3X6pfj3MKFdbC29agxiNxmnJ/u52QuOad0BGuE80l19e mehaxIUKCfK48BTuejnKpZxhceQhzjAYbgmsdyc24/gr1nHmaT+jMuEQtz6fEEa+2ykd HFyg== X-Received: by 10.52.70.20 with SMTP id i20mr4487841vdu.69.1370028738194; Fri, 31 May 2013 12:32:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.163 with HTTP; Fri, 31 May 2013 12:31:57 -0700 (PDT) In-Reply-To: <51A8F85F.4090900@nostrum.com> References: <51A8F85F.4090900@nostrum.com> From: Mark Rejhon Date: Fri, 31 May 2013 15:31:57 -0400 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=20cf307f39b045b60904de08acf0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 19:32:21 -0000 --20cf307f39b045b60904de08acf0 Content-Type: text/plain; charset=ISO-8859-1 Actually, it's not quite that simple. Some countries made RFC4103 part of their government legislation. There are two open real-time text standards that is necessary to make provisions for, to cover world-wide usage. Everytime SIP is used for anything, it should always use RFC4013. If WebRTC implementations touch SIP and not XMPP, and utilize real-time text, then it needs to use RFC4103, even if it has to use the sockets feature. Thus, we need to make sure that it's also usable for RFC4103. So it's not a 100% solved problem; there is still a SIP need. Thanks, Mark Rejhon On Fri, May 31, 2013 at 3:22 PM, Adam Roach wrote: > Mark: > > This is all very neat. To be clear about what's being shown here: > > * This does not use RFC 4103 RTT-over-RTP > * This text is transmitted over a traditional XMPP > client->server->server->client architecture > > Correct? If so -- and if this is being held out as a preferred technology > for RTT -- then this is great news. As is shown by numerous live > deployments (Gmail, Facebook, LiveJournal IM, etc), the model of [JS > Client]->[Web Server]->[XMPP Server]->[XMPP Client] works quite well, and > has been supported by existing web technologies since at least 2006. > > I'm glad to have a demonstration that this is a solved problem that we > don't need to make special provisions for. Thanks. > > /a > --20cf307f39b045b60904de08acf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually, it's not quite that simple.=A0

Some countr= ies made RFC4103 part of their government legislation.
There= are two open real-time text standards that is necessary to make provisions= for, to cover world-wide usage.

Everytime SIP is used for anything, it should alw= ays use RFC4013.
If WebRTC implementations touch SIP and not XMPP= , and utilize real-time text, then it needs to use RFC4103, even if it has = to use the sockets feature. =A0Thus, we need to make sure that it's als= o usable for RFC4103. =A0 So it's not a 100% solved problem; there is s= till a SIP need.

Thanks,
Mark Rejhon

On Fri, May 31, 2013 at 3:22 PM, Adam Roach <adam@nostrum.= com> wrote:
Mark:

This is all very neat. To be clear about what's being shown here:

=A0* This does not use RFC 4103 RTT-over-RTP
=A0* This text is transmitted over a traditional XMPP
=A0 =A0client->server->server->client architecture

Correct? If so -- and if this is being held out as a preferred technology f= or RTT -- then this is great news. As is shown by numerous live deployments= (Gmail, Facebook, LiveJournal IM, etc), the model of [JS Client]->[Web = Server]->[XMPP Server]->[XMPP Client] works quite well, and has been = supported by existing web technologies since at least 2006.

I'm glad to have a demonstration that this is a solved problem that we = don't need to make special provisions for. Thanks.

/a
--20cf307f39b045b60904de08acf0-- From markybox@gmail.com Fri May 31 13:04:23 2013 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 8336821F853A for ; Fri, 31 May 2013 13:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJD7rbxh4wBs for ; Fri, 31 May 2013 13:04:21 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6339921F91B7 for ; Fri, 31 May 2013 13:04:21 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so1471400vea.2 for ; Fri, 31 May 2013 13:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/c2hlNUM8OmTVT6XlVOI7g54Lqg1nb+DwKfAAeVPkZk=; b=x+wWW1hwrrfLO652xsOwhkDk/o9+2t5Z0OlNM8Z248t9vtRf0I9+VT7PU5/egCl4iw FrgdHZBEUGmeD9zufx2NyJYQ7sVYU6JJp8hqXu01XF7AmqNQQze9ZMw194cD8dqbDZ0E lshDbBngdti87hBDvH+WoSMv1z7woLjd5Lwdx/h47BWN/X4VhKkFYXSrBbR3EFx49s9Z qfMP8yTK9vN5M7fVUJ1r+1vFBz8HbgZSZFMtdJmnnr+Ybyf1OW79fPOO4/gkw8EE65A1 BMmwKKqW4+unHBitnFXI0CcukRVLlPU0jGGNxNkuSIxSW+Pvl88mb2nYSOyqgDYWKI8R 9Ong== X-Received: by 10.220.252.66 with SMTP id mv2mr2735505vcb.22.1370030660714; Fri, 31 May 2013 13:04:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.163 with HTTP; Fri, 31 May 2013 13:04:00 -0700 (PDT) In-Reply-To: References: From: Mark Rejhon Date: Fri, 31 May 2013 16:04:00 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e01177443dd055104de091ed4 Cc: Christian Vogler , "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:04:23 -0000 --089e01177443dd055104de091ed4 Content-Type: text/plain; charset=ISO-8859-1 Hello Bernard, Cc: Christian Vogler (who I collaborated with, for his XEP-0301 RTT Javascript) Currently, it is BOSH based. It is easy to modify to make it work over WebSockets. WebSockets helps, but unlike for RFC4103 (which is still necessary to support), it is not necessary to a continuous connection for XEP-0301. XEP-0301 is polled-compatible so works great over BOSH, and still looks like a continuous connection because of the (optional/recommended) keypress interval preservation feature of XEP-0301. It successfully keeps typing completely original-looking, despite intermittent transmission. This is even across a slow satellite connection (with background downloads occuring), between two web browsers on the opposite sides of Earth, running over unpredictable HTTP and XMPP networks. Extreme moments of lag will eventually show through as a momentary pause in conversation, followed by a catchup of text, but reasonable ping variability in transmission (<1 second jitter) become seamlessly invisible. The packet rate is apparent not too much higher than rapid-fire short instant messages such as "Hi" "hey" "sup?" "good" "you?" etc -- that often perpetuate modern chats. Servers are already hardened against this transaction rate, so are pretty XEP-0301 friendly already. That said, this does not replace RFC4103, since some countries have an extensive RFC4103-based infrastructure installed & are part of their law. Thanks, Mark Rejhon On Fri, May 31, 2013 at 3:09 PM, Bernard Aboba wrote: > Thanks, Mark. could you say a few words about the status of the XEP-0301 > JavaScript implementation? As I understand it, this was done as an > extension to Strophe, which now supports the XMPP over Websockets draft in > the beta builds. > > ------------------------------ > From: markybox@gmail.com > Date: Fri, 31 May 2013 15:03:51 -0400 > To: ibc@aliax.net > CC: rtcweb@ietf.org > Subject: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer > RTT (for future webrtc standardization purposes) > > Although this is not 100% webrtc related, it has implications, since > Gunnar (RFC4103) worked with me as the co-author of XEP-0301, so I want to > write this to help people understand that RTT is not necessarily always > peer-to-peer. > -- Federated network-to-network compatible. Anything federated will > interop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RTT) > > Neat Demonstration of XEP-0301 interoperability in multiple XMPP clients > (including non-RTT) > *This is a live demonstration of non-peer-to-peer RTT*, but broadcast RTT > sent through the same channels as full messages. > > On one account on one computer, run two browser windows simultaneously: > *1. Log onto your Google Talk via GMAIL account at http://www.gmail.com * > *2. Log onto your Google Talk via Gallaudet University's implementation: > http://tap.gallaudet.edu/rtt/ ... (Same account) * > > On a different account on a different computer: > *3. On a separate computer, log using a different, separate Google > account at http://tap.gallaudet.edu/rtt/ (or use any RTT client such as > the RealJabber.org client)* > > Observe the following interoperability: > -- You can message from any #1, #2, or #3. > -- Completed messages from #1/#2 (simultaneously logged into same account) > will reach #3 and vice-versa > -- Messages from #3 will reach both #1 and #2 simultaneously. > -- Real-time text doesn't show up in GMAIL, but does show up in > RTT-compatible clients > -- GMAIL keeps working merrily along, logging & archiving the completed > messages. GMAIL silently ignores the extraneous RTT XML > > Observe that: > -- Everything is routed through unmodified XMPP servers > -- No server modifications > -- Not peer-to-peer. No direct connections. No firewall worries. > -- If full messages make it through, real-time text also makes it through. > -- Federated network-to-network compatible. Anything federated will > interop with each other for RTT. > -- One end can be a jabber.org account, another end can be a Cisco WebEx > account (if federated). An RTT-enhanced Lync client transmits RTT to an > RTT-enhanced WebEx. Yes, federation is being abandoned by Google -- but > others aren't. You can still test RTT over federation between jabber.organd > gmail.com using two separate copies of RealJabber.org client -- it works! > > It bridges the mainstream and accessibility. I got feedback for my > XEP-0301 specification from several people at Microsoft (including Bernard > Aboba), Facebook (Name requested to be private), Cisco (Paul E. Jones), and > others. See the names at > http://xmpp.org/extensions/xep-0301.html#acknowledgments. So you see, > big names are on real-time text already on a 10-year roadmap. > > It allows text to be used as conversationally as a telephone conversation, > including in situations where speech is not practical (e.g. environments > that must be quiet, environments too noisy to hear, restrictions on phone > use, situations where speaking is a privacy or security concern, and/or > when participant(s) are deaf or hard of hearing). It is also used for > transmission of live speech transcription. > It can also be turned on/off, for privacy considerations, and when you're > not in as a chatty mood. > > It also proved more popular and appealing than video: When I did a test > among family and friends, when taught about real-time text ( > http://www.fasttext.org -- The International Symbol of Real-Time Text), > more people enabled the RTT feature than the video feature. There is > potential for RTT to be more popular than video, once people are more fully > familiar with the feature, and when it's not intrusive (e.g. easy to turn > on/off) > > -- Gunnar Helstrom has also developed a bridge that fills the gap between > RFC4103 and XEP-0301 > -- Vint Cerf received an accessibility demonstration involving real-time > text demonstration as part of Raising The Floor, by Gregg Vanderheiden. > -- Real-time text was demonstrated at FCC text-to-911 as a standardized > add-on to line-by-line SMS text messaging. > > I developed a method of presenting real-time text smoothly (non-bursty) > despite only 1 packet every second, or every 2 seconds: > http://www.realjabber.org/anim/real_time_text_demo.gif > Observe that the key press intervals are successfully (optionally) > preserved. (Many deafies like the natural typing feel) > It also can support word-at-a-time buffering, for those people who hate > watching typing mistakes. > > Closed captioning was thought of as a luxury in 1970's. Now it's built > into TV's. Mainstream loves captioning nowadays. In 10 years from now, > this could become a mainstream feature. It may not happen in 3 years, > maybe not even 5 years. But there is movement behind the scenes. It is > important to understand the implications of real-time text and its ability > to be 100% seamlessly compatible with existing messaging networks, > potentially as a more popular optional feature than Video. > > Sincerely, > Mark Rejhon > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > --089e01177443dd055104de091ed4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Bernard,

Cc: Christian Vogler (who I collaborated = with, for his XEP-0301 RTT Javascript)

Curren= tly, it is BOSH based.=A0
It is easy to modify to make it work ov= er WebSockets.

WebSockets helps, but unlike for RFC4103 (w= hich is still necessary to support), it is not necessary to a continuous co= nnection for XEP-0301. =A0XEP-0301 is polled-compatible so works great over= BOSH, and still looks like a continuous connection because of the (optiona= l/recommended) keypress interval preservation feature of XEP-0301. =A0It su= ccessfully keeps typing completely original-looking, despite intermittent t= ransmission. =A0This is even across a slow satellite connection (with backg= round downloads occuring), between two web browsers on the opposite sides o= f Earth, running over unpredictable HTTP and XMPP networks. =A0Extreme mome= nts of lag will eventually show through as a momentary pause in conversatio= n, followed by a catchup of text, but reasonable ping variability in transm= ission (<1 second jitter) become seamlessly invisible.

The packet rate is apparent not too much higher t= han rapid-fire short instant messages such as "Hi" "hey"= ; "sup?" "good" "you?" etc -- that often perp= etuate modern chats. =A0Servers are already hardened against this transacti= on rate, so are pretty XEP-0301 friendly already. =A0That said, this does n= ot replace RFC4103, since some countries have an extensive RFC4103-based in= frastructure installed & are part of their law.=A0

Thanks,
Mark Rejhon

<= div class=3D"gmail_quote">On Fri, May 31, 2013 at 3:09 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Thanks,=A0Mark.=A0 could you say a few words about=A0= the status of the XEP-0301 JavaScript implementation?=A0 As I understand it= , this was done as an extension to Strophe, which now supports the XMPP ove= r=A0Websockets draft in the beta builds.=A0
=A0
From: markybox@gmail.com
Date: Fri, 31 May 2013 15:03:51 -0400
To: <= a href=3D"mailto:ibc@aliax.net" target=3D"_blank">ibc@aliax.net
CC: = rtcweb@ietf.org Subject: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT= (for future webrtc standardization purposes)

Although this is not 1= 00% webrtc related, it has implications, since Gunnar (RFC4103) worked with= me as the co-author of XEP-0301, so I want to write this to help people un= derstand that RTT is not necessarily always peer-to-peer.
-- Federated network-to-network compatible. =A0 =A0Anything federated = will interop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RT= T)

Neat Demonstration of XEP-0301 interoperability= in multiple XMPP clients (including non-RTT)
This is a live demonstration of non-peer-to-peer RTT, but broadcast = RTT sent through the same channels as full messages.

On one account on one computer, run two browser windows simultaneously:
1. Log onto your Google Talk via GMAIL account at http://www.gmail.com=A0
2. Log onto your Google Talk via Gallaudet University's implementat= ion: http://tap= .gallaudet.edu/rtt/ ... (Same account)=A0

On a different account on a different computer:
3. On a separate computer, log using a different, separate Google acc= ount at=A0http:= //tap.gallaudet.edu/rtt/=A0(or use any RTT client such as the RealJabbe= r.org client)

Observe the following interoperability:
-- Yo= u can message from any #1, #2, or #3.
-- Completed messages from = #1/#2 (simultaneously logged into same account) will reach #3 and vice-vers= a
-- Messages from #3 will reach both #1 and #2 simultaneously.
-- Real-time text doesn't show up in GMAIL, but does show up in RTT-c= ompatible clients
-- GMAIL keeps working merrily along, log= ging & archiving the completed messages. =A0GMAIL silently ignores the = extraneous RTT XML

Observe that:
-- Everything is routed th= rough unmodified XMPP servers
-- No server modifications =A0
-- Not peer-to-peer. =A0No direct connections. =A0No firewall worries= .=A0
-- If full messages make it through, real-time text also makes it thro= ugh.
-- Federated network-to-network compatible. =A0 =A0Anything = federated will interop with each other for RTT.
-- One end can be= a jabber.org account, = another end can be a Cisco WebEx account (if federated). =A0 An RTT-enhance= d Lync client transmits RTT to an RTT-enhanced WebEx. =A0 =A0Yes, federatio= n is being abandoned by Google -- but others aren't. =A0You can still t= est RTT over federation between jabber.org and gmai= l.com using two separate copies of RealJabber.org client -- it works!

It bridges the mainstream and accessibility= . =A0 I got feedback for my XEP-0301 specification from several people at M= icrosoft (including Bernard Aboba), Facebook (Name requested to be private)= , Cisco (Paul E. Jones), and others. =A0See the names at http:/= /xmpp.org/extensions/xep-0301.html#acknowledgments.=A0 So you see, big = names are on real-time text already on a 10-year roadmap.

It allows text to be used as conversationally as a tele= phone conversation, including in situations where speech is not practical (= e.g. environments that must be quiet, environments too noisy to hear, restr= ictions on phone use, situations where speaking is a privacy or security co= ncern, and/or when participant(s) are deaf or hard of hearing). It is also = used for transmission of live speech transcription. =A0
It can also be turned on/off, for privacy considerations, and when you= 're not in as a chatty mood.

It also proved more popular = and appealing than video: When I did a test among family and friends, when = taught about real-time text ( http://www.fasttext.org -- The International Symbol of Real-Ti= me Text), more people enabled the RTT feature than the video feature. =A0Th= ere is potential for RTT to be more popular than video, once people are mor= e fully familiar with the feature, and when it's not intrusive (e.g. ea= sy to turn on/off)

-- Gunnar Helstrom has also developed a bridge that fil= ls the gap between RFC4103 and XEP-0301
-- Vint Cerf received an = accessibility demonstration involving real-time text demonstration as part = of Raising The Floor, by Gregg Vanderheiden.
-- Real-time text was demonstrated at FCC text-to-911 as a standardize= d add-on to line-by-line SMS text messaging. =A0

I= developed a method of presenting real-time text smoothly (non-bursty) desp= ite only 1 packet every second, or every 2 seconds:
http://www.realjabber.org/anim/real_time_text_demo.gif= =A0
Observe that the key press intervals are successfully (optionally) p= reserved. =A0(Many deafies like the natural typing feel)
It also can support word-at-a-time buffering, for those people who hat= e watching typing mistakes.

Closed captioning was = thought of as a luxury in 1970's. =A0Now it's built into TV's. = =A0Mainstream loves captioning nowadays. =A0 In 10 years from now, this cou= ld become a mainstream feature. =A0It may not happen in 3 years, maybe not = even 5 years. =A0But there is movement behind the scenes. =A0It is importan= t to understand the implications of real-time text and its ability to be 10= 0% seamlessly compatible with existing messaging networks, potentially as a= more popular optional feature than Video.

Sincerely,
Mark Rejhon

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

--089e01177443dd055104de091ed4-- From matthew@matthew.at Fri May 31 13:27:51 2013 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 F3AEC21F90CD for ; Fri, 31 May 2013 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DURoq5UtJ1WS for ; Fri, 31 May 2013 13:27:45 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE46E21F8D90 for ; Fri, 31 May 2013 13:27:44 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 8EB5D1480FA for ; Fri, 31 May 2013 13:27:43 -0700 (PDT) Message-ID: <51A907C2.6040801@matthew.at> Date: Fri, 31 May 2013 13:27:46 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> In-Reply-To: <51A835D7.9060603@omnitor.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] RTT (was Re: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:27:51 -0000 On 5/30/2013 10:32 PM, Gunnar Hellstrom wrote: > I do not understand why modern communication users accept to see a > chat state indication of "composing" instead of really seeing what > text is composed. Perhaps because you haven't done user studies of SMS-style compose-and-send vs. real-time text. I suggest you do that, and then you'll understand the several reasons why most users (perhaps interestingly, excluding those users who are hearing-impaired) prefer the former. > With real-time text you get rid of the frustration that "composing" > creates. And you add the sender's frustration of not being able to edit and rethink their message before sending it, and the expectation on both the sender and the receiver that they remain present for the duration of the conversation rather than using it as a completely asynchronous messaging modality, to reply when convenient. [this is just a subset of what the user studies show, but touches a couple of the most common points] Matthew Kaufman From matthew@matthew.at Fri May 31 13:30:40 2013 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 D062721F9050 for ; Fri, 31 May 2013 13:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgroZ1hvIkBh for ; Fri, 31 May 2013 13:30:34 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F8F21F89EB for ; Fri, 31 May 2013 13:30:34 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id A61D41480FA for ; Fri, 31 May 2013 13:30:34 -0700 (PDT) Message-ID: <51A9086D.6040608@matthew.at> Date: Fri, 31 May 2013 13:30:37 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:30:40 -0000 On 5/31/2013 5:35 AM, IƱaki Baz Castillo wrote: > Facebook, Google+, Twitter and any other website use their own custom > mechanisms for providing chat capabilities to *their own* users > *between them*. I don't expect that they will be interested in a > peer-to-peer (user-to-user) realtime text because they want to log the > messages, inspect them, offer you advertisements based on the content > of your "private" chats, etc. Yes, among other things, text messaging has a completely different set of legal requirements (both for public service providers as well as within regulated industries such as securities trading) than voice communication in many countries, including the US. If real-time-text falls into those requirements, it will need to conform to those requirements... never mind the things like blocking URLs that point to virus downloads. Matthew Kaufman From stpeter@stpeter.im Fri May 31 13:31:49 2013 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 ACC2A21F9121 for ; Fri, 31 May 2013 13:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGIcXGNEE3d2 for ; Fri, 31 May 2013 13:31:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 839E121F89EB for ; Fri, 31 May 2013 13:31:43 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A38B54120B; Fri, 31 May 2013 14:44:38 -0600 (MDT) Message-ID: <51A908AC.2000901@stpeter.im> Date: Fri, 31 May 2013 14:31:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mark Rejhon References: <51A8F85F.4090900@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:31:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/31/13 1:31 PM, Mark Rejhon wrote: > Actually, it's not quite that simple. > > Some countries made RFC4103 part of their government legislation. > There are two open real-time text standards that is necessary to > make provisions for, to cover world-wide usage. > > Everytime SIP is used for anything, it should always use RFC4013. > If WebRTC implementations touch SIP and not XMPP, and utilize > real-time text, then it needs to use RFC4103, even if it has to use > the sockets feature. Thus, we need to make sure that it's also > usable for RFC4103. So it's not a 100% solved problem; there is > still a SIP need. Although I have not read the legislation that mandates use of RFC 4103 (and I'm not particularly interested in the Layer 8 issues), I don't quite agree that one can't use SIP and XMPP in concert. For example, one could use SIP to negotiate use of XMPP with XEP-0301 as the RTT channel, similar to draft-sparks-simple-jabber-sessions from way back in 2002: http://tools.ietf.org/id/draft-sparks-simple-jabber-sessions-00.txt That might not be palatable to the politicians, but it might be an acceptable technical solution. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRqQisAAoJEOoGpJErxa2pCMoP/R4pRxPbfMcP3UF1WWTlYVcN qT+tlq2s4YFH8luttDzFf0V66yBQvPlJ1cedhxqJxlWZeK9xrsGqzVI2LVj4/mhP e64yGToTvdHTuayD+q41gXsrLcpTxaUviSCMOI/zr1Gqv5lfXUV/qXH9V195gmZ8 V0EgRebCHhFPFiEKZknUfhFLrqrLBEQ4xGna+dvWZREMolRLx0qGdtdkWRJbWZEZ VqjG/S5JBQGGfON/Cmww/Rcfzb1nopEGC0ff/k7DgZFaHxX7CcjaFq2b9wOl7udf k8PposwpaZ5KNCpsUB7H7qdrqTUi11JHVUj3DLVmp9fZVwuZfT0+2aLiqYV9NsdJ l0werWpTeGTY8ynq8qlgecBv9LE4Oqh+u6PDoJf9TdmVtetS1vZHH/P77rUZ98Fp mgcXYxOxTDOXTq1/d2TVGylWXIV0kajxr1jKC5G40ksH85b9imkqSzirtLa/Wx3L y5RHiXjO0Uoj3ic65VrPYqNRKLYk1U2NHZ6+YvRVOPBuhsNcq2vTbQ3X2QlIOGk2 FCd0CVxHUt98Ku5ypr1hHgjxDzDsqHvsAo5yyCWuDkHQHKeHGGGeDqasEmwourUt EC8nIcd5s4/Pc78+NPf3iOtLoyXQmSnqnubaWYyzP8lCe+ZhijfKYomYddlIKrzO kB8Vt6gf8mtWnuczRsAj =itx6 -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Fri May 31 14:15:16 2013 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 2C60321F8EAE for ; Fri, 31 May 2013 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW9oPjVBaRCc for ; Fri, 31 May 2013 14:15:10 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEB621F8FEB for ; Fri, 31 May 2013 14:15:08 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id ib951l0031ZXKqc57lF8JK; Fri, 31 May 2013 21:15:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id ilF71l01S3ZTu2S3hlF8Qd; Fri, 31 May 2013 21:15:08 +0000 Message-ID: <51A912DB.5010104@alum.mit.edu> Date: Fri, 31 May 2013 17:15:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A907C2.6040801@matthew.at> In-Reply-To: <51A907C2.6040801@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370034908; bh=n/MDcWUUKuYpgCfV1Ix8LdEerMBqWknHAAo6yrNj9S8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pkJvsormOPefzoKtalYvpa+Crd+O4bM72VUG8UbXPeHw3a3HVF+kG6fxMtJp0AbUB A40ARPqkTulMqNxZo0KbtqJSzStM2ekYCrp5s35sKiaqXvveyvV14ZJdNtIYjqDpQ7 KsiY//DiXf+N8iOjQ+c96OOGj4AnJ1gx5rb5fNIhuEZaa4YO5+QQdW5AqqWEz3mC61 VdhIC5Pr6nidiFm3xKRzjAu7H6yvf/+MzNlYovKFYzy0CJwSVL78X+xlOL5iF8iGun XDF/ieIHZNannpJvzF3BPSGM+nAwcOjiAjmFS3psP9bEjJ68B/e1dnE7mq0wJ2w9HC DKcAtBvQADlBg== Subject: Re: [rtcweb] RTT (was Re: No Plan) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 21:15:16 -0000 I've been through this conversation before. There are no winners. Different strokes for different folks. IMO the texting UI should be as independent as possible of this stylistic difference, and the actual protocol. The session establishment should sort out the "best" compromise between the desires and capabilities of the two ends. Thanks, Paul On 5/31/13 4:27 PM, Matthew Kaufman wrote: > On 5/30/2013 10:32 PM, Gunnar Hellstrom wrote: >> I do not understand why modern communication users accept to see a >> chat state indication of "composing" instead of really seeing what >> text is composed. > > Perhaps because you haven't done user studies of SMS-style > compose-and-send vs. real-time text. > > I suggest you do that, and then you'll understand the several reasons > why most users (perhaps interestingly, excluding those users who are > hearing-impaired) prefer the former. > >> With real-time text you get rid of the frustration that "composing" >> creates. > > And you add the sender's frustration of not being able to edit and > rethink their message before sending it, and the expectation on both the > sender and the receiver that they remain present for the duration of the > conversation rather than using it as a completely asynchronous messaging > modality, to reply when convenient. [this is just a subset of what the > user studies show, but touches a couple of the most common points] > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From gunnar.hellstrom@omnitor.se Fri May 31 15:59:17 2013 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 D0BEE21F8607 for ; Fri, 31 May 2013 15:59:16 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlMmehquSeS4 for ; Fri, 31 May 2013 15:59:12 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 9F7E221F85E0 for ; Fri, 31 May 2013 15:59:09 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 1 Jun 2013 00:58:12 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id BE8A23A10F for ; Sat, 1 Jun 2013 00:58:11 +0200 (CEST) Message-ID: <51A92B07.7030207@omnitor.se> Date: Sat, 01 Jun 2013 00:58:15 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51A8F85F.4090900@nostrum.com> <51A908AC.2000901@stpeter.im> In-Reply-To: <51A908AC.2000901@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 22:59:17 -0000 On 2013-05-31 22:31, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5/31/13 1:31 PM, Mark Rejhon wrote: >> Actually, it's not quite that simple. >> >> Some countries made RFC4103 part of their government legislation. >> There are two open real-time text standards that is necessary to >> make provisions for, to cover world-wide usage. >> >> Everytime SIP is used for anything, it should always use RFC4013. >> If WebRTC implementations touch SIP and not XMPP, and utilize >> real-time text, then it needs to use RFC4103, even if it has to use >> the sockets feature. Thus, we need to make sure that it's also >> usable for RFC4103. So it's not a 100% solved problem; there is >> still a SIP need. > Although I have not read the legislation that mandates use of RFC 4103 > (and I'm not particularly interested in the Layer 8 issues), I don't > quite agree that one can't use SIP and XMPP in concert. For example, > one could use SIP to negotiate use of XMPP with XEP-0301 as the RTT > channel, similar to draft-sparks-simple-jabber-sessions from way back > in 2002: > > http://tools.ietf.org/id/draft-sparks-simple-jabber-sessions-00.txt > > That might not be palatable to the politicians, but it might be an > acceptable technical solution. Well formulated requirements do not say that you must always USE RFC 4103 for real-time text. The requirements rather say that you must SUPPORT RFC 4103 in SIP call control environment, and you must provide real-time text functionality with good flow, sufficiently short delay and sufficient reliability. To support means to be possible to activate through negotiation. So there is room for USING other protocols. Gunnar > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRqQisAAoJEOoGpJErxa2pCMoP/R4pRxPbfMcP3UF1WWTlYVcN > qT+tlq2s4YFH8luttDzFf0V66yBQvPlJ1cedhxqJxlWZeK9xrsGqzVI2LVj4/mhP > e64yGToTvdHTuayD+q41gXsrLcpTxaUviSCMOI/zr1Gqv5lfXUV/qXH9V195gmZ8 > V0EgRebCHhFPFiEKZknUfhFLrqrLBEQ4xGna+dvWZREMolRLx0qGdtdkWRJbWZEZ > VqjG/S5JBQGGfON/Cmww/Rcfzb1nopEGC0ff/k7DgZFaHxX7CcjaFq2b9wOl7udf > k8PposwpaZ5KNCpsUB7H7qdrqTUi11JHVUj3DLVmp9fZVwuZfT0+2aLiqYV9NsdJ > l0werWpTeGTY8ynq8qlgecBv9LE4Oqh+u6PDoJf9TdmVtetS1vZHH/P77rUZ98Fp > mgcXYxOxTDOXTq1/d2TVGylWXIV0kajxr1jKC5G40ksH85b9imkqSzirtLa/Wx3L > y5RHiXjO0Uoj3ic65VrPYqNRKLYk1U2NHZ6+YvRVOPBuhsNcq2vTbQ3X2QlIOGk2 > FCd0CVxHUt98Ku5ypr1hHgjxDzDsqHvsAo5yyCWuDkHQHKeHGGGeDqasEmwourUt > EC8nIcd5s4/Pc78+NPf3iOtLoyXQmSnqnubaWYyzP8lCe+ZhijfKYomYddlIKrzO > kB8Vt6gf8mtWnuczRsAj > =itx6 > -----END PGP SIGNATURE----- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Fri May 31 22:23:11 2013 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 6B30021F86BB for ; Fri, 31 May 2013 22:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V08EydlpR1BB for ; Fri, 31 May 2013 22:23:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE921F85EF for ; Fri, 31 May 2013 22:23:03 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-cc-51a98535f018 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.00.18006.53589A15; Sat, 1 Jun 2013 07:23:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 1 Jun 2013 07:23:01 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Emil Ivov Thread-Topic: [rtcweb] No Plan Thread-Index: AQHOXJ6wvy+3t7Ib3U6qANONjzQMzw== Date: Sat, 1 Jun 2013 05:23:00 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2DB39E@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com> <51A8E434.1020904@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvra5p68pAg5Vr9S3W7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgynhw4QpbwQL1istLZ7E0ML6W72Lk5JAQMJFo uPiOCcIWk7hwbz1bFyMXh5DAYUaJyZ1/GSGcxYwSLzbNYgOpYhMIlNi6bwGYLSIgL9Hdtgis m1lAXeLO4nPsILawgKzEteszoGrkJK7/3Adl60m8efEFqIaDg0VAReL3B0GQMK+Ar8Tmzutg JUIC6RJLrt5lBLEZgQ76fmoN1HhxiVtP5kMdKiCxZM95ZghbVOLl43+sELaSxI8Nl1gg6vUk bkydwgZha0ssW/iaGWKXoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMw Eg5u+a26g/HOOZFDjNIcLErivHq8iwOBPkgsSc1OTS1ILYovKs1JLT7EyMTBKdXAWH8xzVTt RMWbjCUHb3CvtnsasG2KmFhp5/0/MpOC2++1Mwlz/rb/9PZnifXiikVe79tf3D6/4UpS/6m2 GdGbGaM/PldZlJWtNOEfd35son+RbOv+7r3ccbI6Dx02el+9c+R2zBcXO/drOx3mbHF823j/ Q+u11zz6q1ON0rsXrNZ6uevqCsnt+kosxRmJhlrMRcWJAB12ABlSAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 01 Jun 2013 05:23:11 -0000 Hej Emil,=0A= =0A= On 5/31/13 7:56 PM, Emil Ivov wrote:=0A= > Hey Stefan,=0A= >=0A= > On 30.05.13, 11:24, Stefan H=E5kansson LK wrote:=0A= >> Hi Emil,=0A= >>=0A= >> a couple of comments:=0A= >>=0A= >> "1. Expose the SSRCs of all local MediaStreamTrack-s that the=0A= >> application may want to attach to a PeerConnection."=0A= >>=0A= >> I don't think that would be possible, or desirable. SSRC _only_ come=0A= >> into play when a MediaStreamTrack is to be transported over the network= =0A= >> - it is useless in local cases. And, the same local MediaStreamTrack=0A= >> could be sent to several peers (using different PeerConnections) and=0A= >> could have different SSRC's (and even different number of SSRC's) for=0A= >> the different peers.=0A= >>=0A= >> I think SSRCs would only be available for MediaStreamTracks that are=0A= >> attached to a PeerConnection.=0A= >=0A= > I believe Paul already commented on this but just to be clear: yes I=0A= > agree that SSRCs would only make sense for tracks that are actually=0A= > going on the network, so the API methods that give access to them would= =0A= > have to take this into account.=0A= =0A= Yes, I think we're in agreement.=0A= =0A= >=0A= >> One thing I like about Plan A and B is that the naive application=0A= >> developer does not have to deal with things below MediaStream and=0A= >> MediaStreamTrack level.=0A= >=0A= > I don't think this is any different with "No Plan". Is there a=0A= > particular scenario that you think would not work?=0A= =0A= No, it was only that when I read the proposal it was unclear to me if it = =0A= would work this way. Let me put it this way: I like it to work in the =0A= way that the MediaStream's and MediaStreamTrack's on the sending side =0A= are reflected at the receiving side sort of automatically (i.e. apps =0A= should not have to deal with stuff like PTs, SSRCs to make it happen - =0A= just forward opaque blobs).=0A= =0A= >=0A= >> The application would simply add a MediaStream=0A= >> (containing MediaStreamTracks) to the PeerConnection, do the=0A= >> createOffer/setLocal and exchange signaling blobs that it need not look= =0A= >> into, and the MediaStream with MediaStreamTrack's would be reflected at= =0A= >> the remote end. The application would not have to deal with PT's, SSRC's= =0A= >> etc.=0A= >=0A= > Note that No Plan does not suggest that PT's be taken up to the=0A= > application. As for SSRCs, those would just serve as identifiers and=0A= > shouldn't bother developers that don't care about them.=0A= =0A= I probably misunderstood something here.=0A= =0A= >=0A= >> I think that the "No Plan" proposal could be made similar if the info=0A= >> about how MediaStreamTrack's relate to SSRC's (including those for FEC= =0A= >> and RTX) is exchanged using some blobs that the (naive) app can just=0A= >> exchange and need not look into.=0A= >=0A= > I was indeed hoping that we could push FEC and RTX down to the RTP layer= =0A= > for the applications that wouldn't want to be bothered. As for the SSRC,= =0A= > the point of making them available to applications would be so that they= =0A= > could use them so I don't think that putting them into blobs would=0A= > change anything.=0A= >=0A= >=0A= >> If done that way, "No Plan" seems to me to be quite similar to Plan B,= =0A= >=0A= > It definitely has a lot in common with Plan B, and it's all about=0A= > relaxing its constraints so that applications who want to handle=0A= > signalling a bit differently could do so.=0A= =0A= I have nothing against that!=0A= =0A= Cheers,=0A= Stefan=0A= =0A= >=0A= > Cheers,=0A= > Emil=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >> On 2013-05-29 20:59, Emil Ivov wrote:=0A= >>> Hey all,=0A= >>>=0A= >>> Based on many of the discussions that we've had here, as well as many= =0A= >>> others that we've had offlist, it seemed like a good idea to investigat= e=0A= >>> a negotiation alternative that relies on SDP and Offer/Answer just a=0A= >>> little bit less.=0A= >>>=0A= >>> The following "no plan" draft attempts to present one such approach:=0A= >>>=0A= >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan=0A= >>>=0A= >>> The draft relies on conventional use of SDP O/A but leaves the=0A= >>> intricacies of multi-source scenarios to application-specific=0A= >>> signalling, with potentially a little help from RTP.=0A= >>>=0A= >>> Hopefully, proponents of Plans A and B would find that the=0A= >>> interoperability requirements that concerned them can still be met with= =0A= >>> "no plan". Of course they would have to be addressed by=0A= >>> application-specific signalling and/or signalling gateways.=0A= >>>=0A= >>> Comments are welcome!=0A= >>>=0A= >>> Cheers,=0A= >>> Emil=0A= >>>=0A= >>=0A= >> _______________________________________________=0A= >> rtcweb mailing list=0A= >> rtcweb@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>=0A= >=0A= =0A= From emil@sip-communicator.org Fri May 31 22:40:12 2013 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 2F95121F8916 for ; Fri, 31 May 2013 22:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP6GaNaD9eWc for ; Fri, 31 May 2013 22:40:11 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6521F88FB for ; Fri, 31 May 2013 22:40:10 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b57so257177eek.3 for ; Fri, 31 May 2013 22:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=g5KqXuiiKIk9RK+kTTDj+EEru6/WXTy/Lo9Znwnm/Rc=; b=DFj6BEL3Ps4SHOW+i3xylDdK2EYdwNr29+7mcFD7BoEDbrrzjJZoVb2zOCyS67zYFD q8av7FgkiS5COWUrjV0MjmPAV1scAvzHBx76ybGv2HE1hV7e3+HuvihL1nXxjbm7xzeI uKSQIzQyNWQzgHSR3KFP8148Tghs8M2FFsZA5bVVBozN3aJm/Y24Ccn94QFJsz2GigmO 8lKZ4+tQAMgLCZRxu6HQIVnqyLFwa214dRqsFBFe1MlUt9HisO0vhH0yhNlPYK7CwY6t e7BNCmFBd53XgCkg5VOnBWkD/qYGYD+aQHWFm1pAZKMx1Ni6EYmVwtAFdHPkvhFsijb0 eItw== X-Received: by 10.14.174.8 with SMTP id w8mr15761459eel.115.1370065208846; Fri, 31 May 2013 22:40:08 -0700 (PDT) Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id b14sm516790ees.16.2013.05.31.22.40.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 22:40:08 -0700 (PDT) Message-ID: <51A98934.3000103@jitsi.org> Date: Sat, 01 Jun 2013 08:40:04 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> In-Reply-To: <51A8F5D8.8070602@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnuKWvOlEYbdhWBEXGFxFJYj8Cuv5fXi2nRzlQG8VpH8XOd61V6OS2GHqdfw4OHMSbpfKwM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No Plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 01 Jun 2013 05:40:12 -0000 On 31.05.13, 22:11, Paul Kyzivat wrote: > On 5/31/13 6:51 AM, Emil Ivov wrote: >> Hey Paul, >> >> On 29.05.13, 22:57, Paul Kyzivat wrote: >>> Emil, >>> >>> I'm going to reserve judgment on this pending further discussion. >>> I think this *might* work for CLUE, but I want to be certain. >> >> Sure! >> >>> I'm concerned with decomposed endpoints that can't manage all the >>> streams on the same address/port. They will need multiple independent >>> m-lines and/or bundle groups. >> >> This is obviously open for debate but the general idea of No Plan is >> that: Offer/Answer is used for configuring media and RTP stacks and >> additional signalling is not the browser's concern. >> >> Having extra m= lines, particularly when using BUNDLE, is in many ways >> just extra signalling. > > You may be able to argue that adding extra m-lines into an existing > bundle is "just extra signaling". But introducing an additional 5-tuple > is more substantial. It requires configuring a new RTP stack and media. Indeed, this would require BUNDLE to work. Emil > > Thanks, > Paul > >> If you'd like for that signalling to be in SDP, I >> don't see any problem with it. However it would be best for this extra >> layer of SDP signalling to appear at either the application layer or in >> a signalling gateway (that is going to be there anyway). >> >> Does this make sense? >> >> Emil >> >>> >>> Further questions: >>> >>> I presume that you expect bandwidth in the SDP to be an aggregate >>> per-m-line, with application specific signaling for bandwidth at the >>> per-RTP-stream level? >>> >>> Thanks, >>> Paul >>> >>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>> Hey all, >>>> >>>> Based on many of the discussions that we've had here, as well as many >>>> others that we've had offlist, it seemed like a good idea to investigate >>>> a negotiation alternative that relies on SDP and Offer/Answer just a >>>> little bit less. >>>> >>>> The following "no plan" draft attempts to present one such approach: >>>> >>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>> >>>> The draft relies on conventional use of SDP O/A but leaves the >>>> intricacies of multi-source scenarios to application-specific >>>> signalling, with potentially a little help from RTP. >>>> >>>> Hopefully, proponents of Plans A and B would find that the >>>> interoperability requirements that concerned them can still be met with >>>> "no plan". Of course they would have to be addressed by >>>> application-specific signalling and/or signalling gateways. >>>> >>>> Comments are welcome! >>>> >>>> Cheers, >>>> Emil >>>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> . >>> >> > > . > -- https://jitsi.org