- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 6 Aug 2014 15:07:04 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: Bernard Aboba <Bernard.Aboba@microsoft.com>, Robin Raymond <robin@hookflash.com>, "public-ortc@w3.org" <public-ortc@w3.org>
On Aug 6, 2014, at 7:14 AM, "Peter Thatcher" <pthatcher@google.com> wrote: > > If the JS chooses not to specify SSRCs, then the browser can pick a > new one, but doesn't need to fire an event. [BA] Question: SSRC not present in send.RTCRtpParameters.RTCRtpEncodingParameters means "browser chooses". For receive it means "wildcard". Correct? > If choosing SSRCs is to hard for the app, then it won't choose them in the first place. [BA] With "muxId" the application won't need to choose them on the sender or specify them on the receiver. Correct? > Further, if it chooses to specify SSRCs, > it probably doesn't want the browser to start sending packets that it > never told it to send. [BA] So media sending would be interrupted until send() is called again with the new SSRC? > >> >> ________________________________________ >> From: Robin Raymond [robin@hookflash.com] >> Sent: Tuesday, August 05, 2014 7:33 PM >> To: Peter Thatcher; Bernard Aboba >> Cc: public-ortc@w3.org >> Subject: Re: Issue 143: SSRC Conflict >> >> Over all it’s a good strategy. >> >> I would also be okay if the browser just picked a new SSRC and evented the old failed SSRC and the new SSRC. But I can appreciate if a JS developer may want to allocate their own new SSRC from JS and then signal that before attempting to send with it. >> >> -- >> Robin Raymo
Received on Wednesday, 6 August 2014 15:07:51 UTC