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>
>
> 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 <mailto:ibc@aliax.net>>
>
>

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

Attachment: postbox-contact.jpg

Attachment: postbox-contact.jpg