- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 6 Aug 2014 19:25:10 +0000
- To: Robin Raymond <robin@hookflash.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>, Peter Thatcher <pthatcher@google.com>
- Message-ID: <8a31aed27c914079817742b1fd1630fe@SN2PR03MB031.namprd03.prod.outlook.com>
I think Peter’s point is that if muxId isn’t being used on the sender and receiver, then when the SSRC is changed by the sender, an RtpUnhandledEvent will be thrown on the receiver, and until the receiver can figure out what RTCRtpReceiver the newly chosen SSRC corresponds to (which it might not know until it is signaled) then media will be interrupted anyway.
When the JS on the sender gets the SSRC conflict event, it needs to set SSRCnew = random32(type) as described in RFC 3550 Section A.6 (see below). Then it needs to substitute SSRCnew for the conflicting SSRCold in RTCRtpParameters, and call send(RTCRtpParameters) again. Not sure how long all of this would take.
In the WebRTC 1.0, I don’t think there is a way for the application to know when a conflict occurs.
Section A.6
The following subroutine generates a random 32-bit identifier using
the MD5 routines published in RFC 1321<http://tools.ietf.org/html/rfc1321> [32<http://tools.ietf.org/html/rfc3550#ref-32>]. The system routines may
not be present on all operating systems, but they should serve as
hints as to what kinds of information may be used.
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC 1321<http://tools.ietf.org/html/rfc1321> */
#include "md5.h" /* from RFC 1321<http://tools.ietf.org/html/rfc1321> */
#define MD_CTX MD5_CTX
#define MDInit MD5Init
#define MDUpdate MD5Update
#define MDFinal MD5Final
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
MDInit (&context);
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if
* you need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
/* also: system uptime */
return md_32((char *)&s, sizeof(s));
} /* random32 */
From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Wednesday, August 6, 2014 10:54 AM
To: Peter Thatcher; Bernard Aboba
Cc: public-ortc@w3.org
Subject: Re: Issue 143: SSRC Conflict
The issue is less about who picks and more about the time it takes to pick. There can be a delay between the conflict and the time the JS has time to respond and start sending again. That will cause an interruption in the media. That’s one of the reason I favour the browser picking for conflicts. But I don’t have a strong opinion and I can appreciate that some developers might want full control before sending.
I think really it should come down to the use cases. When an SSRC conflict happens in the use cases where the JS set the SSRC manually, what does the JS need to do in the conflict case? Do we know? can we guess? Seems like legacy use cases where we should be able to know the expected usage(s) since muxId is the forward looking solution here.
Curious, in WebRTC 1.0, what happen in SSRC conflict? “re-invite required”? We also need to shim so I’m curious what is required.
--
Robin Raymond
On August 6, 2014 at 12:23:42 PM, Peter Thatcher (pthatcher@google.com<mailto:pthatcher@google.com>) wrote:
On Wed, Aug 6, 2014 at 8:07 AM, Bernard Aboba
<Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
> On Aug 6, 2014, at 7:14 AM, "Peter Thatcher" <pthatcher@google.com<mailto: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?
Correct. Although, "wildcard" when used with muxId means "any SSRC
with the given muxId, including latching behavior", and even without
muxId still means "demux by payload type if necessary".
>
>> 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?
Correct. If they still do, what was the point of muxId?
>
>
>> 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?
Yes, but if you're signalling SSRCs for demux, the receiver probably
isn't going to handle the media into the new SSRCs are signalled
anyway, so I don't see there being a big loss here. And as I've
stated a few times, I think an SSRC collision will be a very unlikely
event. You'll much more likely see media interrupted for many other
reasons.
>
>>
>>>
>>> ________________________________________
>>> From: Robin Raymond [robin@hookflash.com]
>>> Sent: Tuesday, August 05, 2014 7:33 PM
>>> To: Peter Thatcher; Bernard Aboba
>>> Cc: public-ortc@w3.org<mailto: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 19:25:43 UTC