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

["Roy, Radhika R CIV USARMY (US)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Robin Raymond
Sent: Saturday, June 29, 2013 11:28 PM
To: Cullen Jennings (fluffy)
Cc: <[e-mail]>
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:[e-mail]> 
	29 June, 2013 5:10 PM
	On Jun 28, 2013, at 11:23 PM, Iñaki Baz Castillo <[e-mail]>
<mailto:[e-mail]> 
	

	Uh, the video tag seems pretty popular...
	
	_______________________________________________
	rtcweb mailing list
	[e-mail]
	https://www.ietf.org/mailman/listinfo/rtcweb
	
	
	Iñaki Baz Castillo <mailto:[e-mail]> 
	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
	<[e-mail]>





Classification: UNCLASSIFIED
Caveats: NONE