- From: Peter Thatcher <pthatcher@google.com>
- Date: Wed, 30 Apr 2014 09:32:53 -0700
- To: Emil Ivov <emcho@jitsi.org>
- Cc: Robin Raymond <robin@hookflash.com>, "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUE9EG3E6XrtnFFrUED=8VT4tyinOHGJzny+JyW=xvOEtg@mail.gmail.com>
On Wed, Apr 30, 2014 at 9:25 AM, Emil Ivov <emcho@jitsi.org> wrote: > > > On 30.04.14, 18:18, Peter Thatcher wrote: > >> So, we're all happy with: >> >> 1. You can set the RTCP SSRC. >> 2. The default, if you don't set it, is to choose a random one. >> > > and 3. you need to be able to get it. M y original proposals includes being able to get it. All the settable parameters are also gettable, including this one. > > Don't >> go choosing 1 as the default because that would make some poor old SFU >> setup explode when the JS developer doesn't know he needs to set it. >> > > I think the oldest SFU I am aware of is the one you are using so if this > one survives it, then we are fine and there's no risk of explosions :) > > I'm not sure which SFU you are talking about. > Again, that's not a problem for the SFU. It's a problem for the endpoints. > > And I am also fine with 1, 2 and 3 above. > > Emil > > If you want ssrc=1, it's easy to set :). >> >> I think I'm OK with that. We can always change our mind later if we run >> into a problem :). >> >> >> >> On Wed, Apr 30, 2014 at 9:14 AM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org>> wrote: >> >> >> >> On 30.04.14, 18:04, Peter Thatcher wrote: >> >> >> >> >> On Wed, Apr 30, 2014 at 8:46 AM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org> >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote: >> >> >> >> On 30.04.14, 17:22, Peter Thatcher wrote: >> >> >> >> >> On Tue, Apr 29, 2014 at 10:42 PM, Emil Ivov >> <emcho@jitsi.org <mailto:emcho@jitsi.org> >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>> >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org> >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>> wrote: >> >> Hey folks, >> >> I personally don't see the need to set the SSRC >> (just as >> there is no >> need to do it for bidirectional RTP) but I do >> agree there >> has to be >> a way to obtain it from the API. We actually also >> need that >> in the >> case when we have disparate numbers of multiple >> senders and >> receivers and it can no longer be assymed what >> SSRC is used >> where. >> >> >> I'm pretty sure we need it at least for the 1.0 shim. >> >> >> Could you please explain why? >> >> >> And I'm sure >> there are legacy interop scenarios the JS will need to >> specify >> the RTCP >> SSRC, and letting the browser choose won't be enough. In >> particular, >> I'm thinking of how it will want to correlate the RTCP >> SSRC of an >> RtpReceiver with the RTP SSRC of an RtpSender. I think >> letting >> the JS >> specify the RTCP SSRC in the RtpReceiver is the easiest >> way. >> >> >> Easiest for who? From a web dev's perspective it would >> probably be >> much more intuitive to say "this sender and receiver belong >> to the >> same context" than "you need to extract the value of the >> 'four funky >> letters' in the receiver and set it on the 'four funky >> letter' in >> the sender". >> >> >> I really don't want to start requiring the JS to correlate >> RtpSenders >> and RtpReceivers into "contexts" just to work around the oddities >> of >> RTCP. >> >> >> Generating invalid RT(C)P unless the developer intervenes doesn't >> really sound like an oddity workaround. >> >> >> "contexts" are just going to turn into complex rat holes. For >> the normal/simple cases of using the API, I think just not >> setting it >> and using the default (either ssrc=1 or random) will work fine. >> >> >> If both are fine, then let's just forget about the "1" value and >> resolve the whole thing. As long as you do that, then the majority >> of the cases would neither need to set nor get the SSRC. >> >> Emil >> >> -- >> https://jitsi.org >> >> >> > -- > https://jitsi.org >
Received on Wednesday, 30 April 2014 16:34:04 UTC