Re: [rtcweb] New Draft - WebRTC JS Object API Model

[Bossiel thioriguel <[e-mail]>]

You have said: "For example, the only thing that should be needed is a flag that says FEC is available in the signaling for the the RTP layer. "

I don't really think and this is why I already said the job is MUCH harder than you think.
- You also need to say which king of FEC you want to use. Let's say it's ulpfec (RFC 5109)
If we are using ulpfec:
A- It is allowed to send FEC packets in the same stream as the protected one or not.
B- When FEC uses different stream then, it is possible to secure it or not regardless the protect stream is secure or not. (e.g SRTP/FEC and RTP/Protected stream). All combinations are possible. When both are encrypted they even could use different keys (if different channels).
C- FEC could be bundled with RED or not
D- When FEC use different channel then, it could use different rate than the protected stream if bundled with RED
E- Say which media (audio, video, application...) and stream you want to protect
F-Whether only one level of protection will be used ("onelevelonly" parameter)
G- etc etc...

SDP already allow all these use-cases. Depending on the  implementations, signalling [A-F] could be mandatory.

Good luck...


________________________________
 De : Robin Raymond <[e-mail]>
À : Tim Panton <[e-mail]> 
Cc : "[e-mail]" <[e-mail]> 
Envoyé le : Mardi 2 juillet 2013 14h22
Objet : Re: [rtcweb] New Draft - WebRTC JS Object API Model
 



You are absolutely, there are  a lot of details. But splitting the 
details into logical separate components reduces the overall complexity 
greatly. Plus many of those details are only needed because of a lack 
ability to properly describe the concept of "streams" at the lower level
 RTP layer (which really only supports tracks at best, and lacks 
sufficient details to coordinate any information between them to 
reassembly remotely as a "stream"). So we are left in a situation where 
the high layers must coordinate a lot of information to be capable of 
reassembling the streams when they really should be just negotiating the
 capabilities of the RTP layer itself.

For example, the only thing that should be needed is a flag that says 
FEC is available in the signaling for the the RTP layer. If it is set 
then that would imply the engine supports this feature and thus FEC 
streams may be created by the sending party. Alas, because RTP lacks 
sufficient depth for such concepts like FEC, you have to signal it. RTP 
doesn't even have enough information to reassemble tracks into stream, 
let allow do things like FEC between them.

Having said that, by making a scoped object that understands there is 
some definition of what a stream means needs to be describes, but 
perhaps that the "future' may not require such crazy definitions like 
all the stream/ssrc/track mappings, it allows for a short/long-term 
temporary situation where stream definitions are passed until we are 
able move to a model where that is no longer needed. When a theoretical 
next-gen RTP transport is capable of sending entire streams and 
reassembling them without explicit signaling from an upper layer, we can
 stop defining all that mapping stuff in signaling and remove that 
complexity.

Basically, it's about scoping the objects, and limiting the requirements
 needed to exchange per object, and defining exactly what is 
expected/required in those definitions and allowing for future 
alternative objects that could replace current ones (if they should 
become available). The other important aspect is removing the definition
 how this information must be coordinated and exchanged to allow for a 
variety of signaling scenarios and alternative state machines. And 
keeping it relatively simple is important for the simple use cases too 
so the burden is low. We are well on our way to producing such a draft 
in short order that does exactly that.

All we ask is that people keep an open mind. We have no desire to 
prevent SDP or offer/answer, just not mandate its usage as an API model.

Make sense?

-Robin


Tim Panton
>2 July, 2013 4:31 AM
>
>
>On 2 Jul 2013, at 08:21, Stefan Håkansson LK wrote:
>
>Conversely we 
shouldn't underestimate (again) the difficulty of describing all the
>nitty gritty details in SDP. 
>
>
>I have the sense that 
we may have pushed the flexibility of SDP beyond it's elastic limit.
>
>
>I think that over the last year we have discovered that a dynamically 
programmable browser
>is a fundamentally different beast from a deskphone and that what suits one may well not suit the other.
>
>
>Tim.
>
>
>_______________________________________________
>rtcweb
 mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>
_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb