Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) (UNCLASSIFIED)

"Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil> Sun, 30 June 2013 13:42 UTC

Return-Path: <radhika.r.roy.civ@mail.mil>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A775921F9A70 for <rtcweb@ietfa.amsl.com>; Sun, 30 Jun 2013 06:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 ExmAkqjhBrkG for <rtcweb@ietfa.amsl.com>; Sun, 30 Jun 2013 06:42:08 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.13]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0921F9A75 for <rtcweb@ietf.org>; Sun, 30 Jun 2013 06:42:08 -0700 (PDT)
Received: from UCOLHP3E.easf.csd.disa.mil (131.64.100.144) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 30 Jun 2013 13:42:00 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.175]) by UCOLHP3E.easf.csd.disa.mil ([131.64.100.144]) with mapi id 14.03.0123.003; Sun, 30 Jun 2013 13:41:57 +0000
From: "Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil>
To: Robin Raymond <robin@hookflash.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) (UNCLASSIFIED)
Thread-Index: AQHOdJE2W6iGgSZ9hkeOJyr4v3GME5lNMRGAgABpiwCAAKa8MA==
Date: Sun, 30 Jun 2013 13:41:54 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B13BC6@ucolhp9b.easf.csd.disa.mil>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1135B686C@xmb-aln-x02.cisco.com> <CALiegf=YjQoAen+u-7wZbxK-r=0ChqdtQCJo58aJJvoBPQ5ZXQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1135B7AEE@xmb-aln-x02.cisco.com> <51CFA5D6.201@hookflash.com>
In-Reply-To: <51CFA5D6.201@hookflash.com>
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_0030_01CE7575.BBA61410"
MIME-Version: 1.0
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) (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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jun 2013 13:42:13 -0000

Classification: UNCLASSIFIED
Caveats: NONE

Is it not the comparison of multi-dimensional intelligence (XML-script) vs.
one-dimensional intelligence (Binary) in expressing the description of a
"multimedia session?"

If it so, why are we waiting for as we know in the very beginning of the
technical debate between H.323 (H.245) and SIP (SDP) where H.245 can
negotiate and evolve a call between the two parties where media bridging is
not needed to a multi-party call that includes the media bridging
automatically (while SDP cannot do so dynamically - that has been another
important limitations of SDP)?

Best regards,
Radhika

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Robin Raymond
Sent: Saturday, June 29, 2013 11:28 PM
To: Cullen Jennings (fluffy)
Cc: <rtcweb@ietf.org>;
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple
sources without encoding them in SDP)


You mean this HTML 5 video tag, right? This one:


<video poster="movie.jpg" controls>
        <source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
        <source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
        <source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E,
mp4a.40.2"'/>
        <p>This is fallback content</p>
</video>
 

Versus this SDP blob that many of us must parse/mangle/generate from our
code if we want to go beyond a basic demo:

v=0
o=- 3572342242 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio data
a=msid-semantic: WMS
m=audio 54680 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4
97.213.43.112
a=rtcp:54680 IN IP4 97.213.43.112
a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host
generation 0
a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host
generation 0 a=ice-ufrag:zFLN0q7y22aeZBhg a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
a=ice-options:google-ice
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=application 54680 RTP/SAVPF 101
c=IN IP4 97.213.43.112
a=rtcp:54680 IN IP4 97.213.43.112
a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host
generation 0
a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host
generation 0 a=ice-ufrag:zFLN0q7y22aeZBhg a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
a=ice-options:google-ice
a=sendrecv
a=mid:data
b=AS:30
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
a=rtpmap:101 google-data/90000
a=ssrc:2838167882 cname:X00v2LuQqKzLnkBs
a=ssrc:2838167882 msid:messaging messaging
a=ssrc:2838167882 mslabel:messaging
a=ssrc:2838167882 label:messaging


Please clarify if I misunderstand you.

-Robin




	
	Cullen Jennings (fluffy) <mailto:fluffy@cisco.com> 
	29 June, 2013 5:10 PM
	On Jun 28, 2013, at 11:23 PM, Iñaki Baz Castillo <ibc@aliax.net>;
<mailto:ibc@aliax.net> 
	

	Uh, the video tag seems pretty popular...
	
	_______________________________________________
	rtcweb mailing list
	rtcweb@ietf.org
	https://www.ietf.org/mailman/listinfo/rtcweb
	
	
	Iñaki Baz Castillo <mailto:ibc@aliax.net> 
	29 June, 2013 2:23 AM

	Cullen, do you think that W3C would ever design a JS API that forces
the developer to deal with an unmanageable blob string? Can somebody point
me to an existing similar "API" in HTML5?

	The problem is that telcos are much more used to IETF processes than
Web people and hence this WG is dominated by telcos proposing their first
API for the W3C, an API to satisfy their existing business model (the
webphone).

	It is time to leave Web experts to design a really useful API for
WebRTC.
	
	

	--
	Iñaki Baz Castillo
	<ibc@aliax.net>;





Classification: UNCLASSIFIED
Caveats: NONE