[jitsi-dev] Why does meet.jit.si run through offer-answer twice


#1

What is the reason that meet.jit.si runs through offer-answer twice?

addStream
addStream
onRenegotiationNeeded
onRenegotiationNeeded
setRemoteDescription
signalingStateChange
onAddStream
setRemoteDescriptionOnSuccess
createAnswer
createAnswerOnSuccess
setLocalDescription
signalingStateChange
iceConnectionStateChange
setLocalDescriptionOnSuccess
iceGatheringStateChange
onIceCandidate
onIceCandidate
onIceCandidate
onIceCandidate
iceGatheringStateChange
iceConnectionStateChange
onRemoteDataChannel

Shouldn't we be set up at this point?

setRemoteDescription
signalingStateChange
onAddStream
setRemoteDescriptionOnSuccess
createAnswer
createAnswerOnSuccess
setLocalDescription
signalingStateChange
setLocalDescriptionOnSuccess


#2

Hi,

What is the reason that meet.jit.si runs through offer-answer twice?

addStream

addStream

onRenegotiationNeeded

onRenegotiationNeeded

setRemoteDescription

signalingStateChange

onAddStream

setRemoteDescriptionOnSuccess

createAnswer

createAnswerOnSuccess

setLocalDescription

signalingStateChange

iceConnectionStateChange

setLocalDescriptionOnSuccess

iceGatheringStateChange

onIceCandidate

onIceCandidate

onIceCandidate

onIceCandidate

iceGatheringStateChange

iceConnectionStateChange

onRemoteDataChannel

Shouldn't we be set up at this point?

Here you have connection with the JVB. In the meantime the 2nd
participant is connecting to the JVB as well. 2nd participant's
streams are unknown yet.

setRemoteDescription

2nd participant streams have been signalled.

signalingStateChange

onAddStream

This is 2nd participant's remote stream added.

setRemoteDescriptionOnSuccess

createAnswer

createAnswerOnSuccess

setLocalDescription

signalingStateChange

setLocalDescriptionOnSuccess

sRD/sLD cycle finished

Regards,
Pawel

···

On Wed, Oct 26, 2016 at 8:42 PM, Oliver Hausler <oliver@closeup.cc> wrote:


#3

Hi Pawel,

Thank you for your response.

- So you are signaling every participant who enters a conference to all existing participants? I assumed the bridge would do ssrc rewriting, and I only needed to set up both directions once per participant.
- Is this only active when using last-n? Or do I also need to signal new streams to existing participants when using last-n?

Oliver.

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Pawel Domas
Sent: Wednesday, October 26, 2016 18:49
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] Why does meet.jit.si run through offer-answer twice

Hi,

On Wed, Oct 26, 2016 at 8:42 PM, Oliver Hausler <oliver@closeup.cc> wrote:

What is the reason that meet.jit.si runs through offer-answer twice?

addStream

addStream

onRenegotiationNeeded

onRenegotiationNeeded

setRemoteDescription

signalingStateChange

onAddStream

setRemoteDescriptionOnSuccess

createAnswer

createAnswerOnSuccess

setLocalDescription

signalingStateChange

iceConnectionStateChange

setLocalDescriptionOnSuccess

iceGatheringStateChange

onIceCandidate

onIceCandidate

onIceCandidate

onIceCandidate

iceGatheringStateChange

iceConnectionStateChange

onRemoteDataChannel

Shouldn't we be set up at this point?

Here you have connection with the JVB. In the meantime the 2nd participant is connecting to the JVB as well. 2nd participant's streams are unknown yet.

setRemoteDescription

2nd participant streams have been signalled.

signalingStateChange

onAddStream

This is 2nd participant's remote stream added.

setRemoteDescriptionOnSuccess

createAnswer

createAnswerOnSuccess

setLocalDescription

signalingStateChange

setLocalDescriptionOnSuccess

sRD/sLD cycle finished

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Ssrc rewriting is just used to make all simulcast streams coming from a
single client look like a single stream, so when the bridge switches from,
say, the 720p layer to the 360p layer, it's transparent to the receiver
(from an rtp perspective). Other than that, all clients need to be aware
of the ssrcs of the other clients in the call (this is especially true for
the non-last-n case on the bridge, where clients receive all streams from
all other clients all the time, so there need to be distinct streams for
each client).

-brian

···

On Wed, Oct 26, 2016 at 7:43 PM, Oliver Hausler <oliver@closeup.cc> wrote:

Hi Pawel,

Thank you for your response.

- So you are signaling every participant who enters a conference to all
existing participants? I assumed the bridge would do ssrc rewriting, and I
only needed to set up both directions once per participant.
- Is this only active when using last-n? Or do I also need to signal new
streams to existing participants when using last-n?

Oliver.

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Pawel Domas
Sent: Wednesday, October 26, 2016 18:49
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] Why does meet.jit.si run through offer-answer
twice

Hi,

On Wed, Oct 26, 2016 at 8:42 PM, Oliver Hausler <oliver@closeup.cc> wrote:
> What is the reason that meet.jit.si runs through offer-answer twice?
>
>
>
> addStream
>
> addStream
>
> onRenegotiationNeeded
>
> onRenegotiationNeeded
>
> setRemoteDescription
>
> signalingStateChange
>
> onAddStream
>
> setRemoteDescriptionOnSuccess
>
> createAnswer
>
> createAnswerOnSuccess
>
> setLocalDescription
>
> signalingStateChange
>
> iceConnectionStateChange
>
> setLocalDescriptionOnSuccess
>
> iceGatheringStateChange
>
> onIceCandidate
>
> onIceCandidate
>
> onIceCandidate
>
> onIceCandidate
>
> iceGatheringStateChange
>
> iceConnectionStateChange
>
> onRemoteDataChannel
>
>
>
> Shouldn't we be set up at this point?

Here you have connection with the JVB. In the meantime the 2nd participant
is connecting to the JVB as well. 2nd participant's streams are unknown yet.

>
> setRemoteDescription

2nd participant streams have been signalled.

> signalingStateChange
>
> onAddStream

This is 2nd participant's remote stream added.

> setRemoteDescriptionOnSuccess
>
> createAnswer
>
> createAnswerOnSuccess
>
> setLocalDescription
>
> signalingStateChange
>
> setLocalDescriptionOnSuccess

sRD/sLD cycle finished

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi Pawel,

Thank you for your response.

- So you are signaling every participant who enters a conference to all
existing participants? I assumed the bridge would do ssrc rewriting, and I
only needed to set up both directions once per participant.

No, we don't re-write SSRCs in that case. We only do so for simulcast.

- Is this only active when using last-n? Or do I also need to signal new
streams to existing participants when using last-n?

We never rewrite participant SSRCs.

Emil

···

On Wednesday, 26 October 2016, Oliver Hausler <oliver@closeup.cc> wrote:

Oliver.

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org <javascript:;>] On Behalf Of
Pawel Domas
Sent: Wednesday, October 26, 2016 18:49
To: Jitsi Developers <dev@jitsi.org <javascript:;>>
Subject: Re: [jitsi-dev] Why does meet.jit.si run through offer-answer
twice

Hi,

On Wed, Oct 26, 2016 at 8:42 PM, Oliver Hausler <oliver@closeup.cc> wrote:
> What is the reason that meet.jit.si runs through offer-answer twice?
>
>
>
> addStream
>
> addStream
>
> onRenegotiationNeeded
>
> onRenegotiationNeeded
>
> setRemoteDescription
>
> signalingStateChange
>
> onAddStream
>
> setRemoteDescriptionOnSuccess
>
> createAnswer
>
> createAnswerOnSuccess
>
> setLocalDescription
>
> signalingStateChange
>
> iceConnectionStateChange
>
> setLocalDescriptionOnSuccess
>
> iceGatheringStateChange
>
> onIceCandidate
>
> onIceCandidate
>
> onIceCandidate
>
> onIceCandidate
>
> iceGatheringStateChange
>
> iceConnectionStateChange
>
> onRemoteDataChannel
>
>
>
> Shouldn't we be set up at this point?

Here you have connection with the JVB. In the meantime the 2nd participant
is connecting to the JVB as well. 2nd participant's streams are unknown yet.

>
> setRemoteDescription

2nd participant streams have been signalled.

> signalingStateChange
>
> onAddStream

This is 2nd participant's remote stream added.

> setRemoteDescriptionOnSuccess
>
> createAnswer
>
> createAnswerOnSuccess
>
> setLocalDescription
>
> signalingStateChange
>
> setLocalDescriptionOnSuccess

sRD/sLD cycle finished

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org <javascript:;>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org <javascript:;>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
sent from my mobile


#6

I see you are communicating the whole ssrc package to other clients, with cname, msid, etc.

a=ssrc:1553632356 cname:X4D3HtZhdlifhKJH
a=ssrc:1553632356 msid:92c32f79-b75a-44d1-b5e5-ea1c877d8956 ca9c8608-f811-4177-bef7-1af9373ad628
a=ssrc:1553632356 mslabel:92c32f79-b75a-44d1-b5e5-ea1c877d8956
a=ssrc:1553632356 label:ca9c8608-f811-4177-bef7-1af9373ad628

Doesn't colibri only support patching the SSRC? I assume you keep the other information in a separate structure outside Jitsi? Is this correct?

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Brian Baldino
Sent: Wednesday, October 26, 2016 21:21
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] Why does meet.jit.si run through offer-answer twice

Ssrc rewriting is just used to make all simulcast streams coming from a single client look like a single stream, so when the bridge switches from, say, the 720p layer to the 360p layer, it's transparent to the receiver (from an rtp perspective). Other than that, all clients need to be aware of the ssrcs of the other clients in the call (this is especially true for the non-last-n case on the bridge, where clients receive all streams from all other clients all the time, so there need to be distinct streams for each client).

-brian

On Wed, Oct 26, 2016 at 7:43 PM, Oliver Hausler <oliver@closeup.cc<mailto:oliver@closeup.cc>> wrote:
Hi Pawel,

Thank you for your response.

- So you are signaling every participant who enters a conference to all existing participants? I assumed the bridge would do ssrc rewriting, and I only needed to set up both directions once per participant.
- Is this only active when using last-n? Or do I also need to signal new streams to existing participants when using last-n?

Oliver.

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>] On Behalf Of Pawel Domas
Sent: Wednesday, October 26, 2016 18:49
To: Jitsi Developers <dev@jitsi.org<mailto:dev@jitsi.org>>
Subject: Re: [jitsi-dev] Why does meet.jit.si<http://meet.jit.si> run through offer-answer twice

Hi,

On Wed, Oct 26, 2016 at 8:42 PM, Oliver Hausler <oliver@closeup.cc<mailto:oliver@closeup.cc>> wrote:

What is the reason that meet.jit.si<http://meet.jit.si> runs through offer-answer twice?

addStream

addStream

onRenegotiationNeeded

onRenegotiationNeeded

setRemoteDescription

signalingStateChange

onAddStream

setRemoteDescriptionOnSuccess

createAnswer

createAnswerOnSuccess

setLocalDescription

signalingStateChange

iceConnectionStateChange

setLocalDescriptionOnSuccess

iceGatheringStateChange

onIceCandidate

onIceCandidate

onIceCandidate

onIceCandidate

iceGatheringStateChange

iceConnectionStateChange

onRemoteDataChannel

Shouldn't we be set up at this point?

Here you have connection with the JVB. In the meantime the 2nd participant is connecting to the JVB as well. 2nd participant's streams are unknown yet.

setRemoteDescription

2nd participant streams have been signalled.

signalingStateChange

onAddStream

This is 2nd participant's remote stream added.

setRemoteDescriptionOnSuccess

createAnswer

createAnswerOnSuccess

setLocalDescription

signalingStateChange

setLocalDescriptionOnSuccess

sRD/sLD cycle finished

Regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Yes msid, mslabel and label are managed in jicofo and don't reach jitsi-videobridge.

Boris

···

On 27/10/16 10:10, Oliver Hausler wrote:

I see you are communicating the whole ssrc package to other clients,
with cname, msid, etc.

a=ssrc:1553632356 cname:X4D3HtZhdlifhKJH

a=ssrc:1553632356 msid:92c32f79-b75a-44d1-b5e5-ea1c877d8956
ca9c8608-f811-4177-bef7-1af9373ad628

a=ssrc:1553632356 mslabel:92c32f79-b75a-44d1-b5e5-ea1c877d8956

a=ssrc:1553632356 label:ca9c8608-f811-4177-bef7-1af9373ad628

Doesn't colibri only support patching the SSRC? I assume you keep the
other information in a separate structure outside Jitsi? Is this correct?


#8

Is there anything that needs to be synchronized externally?

- When a new participant enters, I create an offer.
- The participant will answer and I add the streams to Jitsi.

Let's say 2 participants enter at the same time. Will I need to finish processing the first and then the second, or is it irrelevant in which order the answers are patched?

In other words: Do we need to complete full offer-answer cycles, or can I generate offers as participants enter and patch answers in any order?

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: Thursday, October 27, 2016 08:16
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] Why does meet.jit.si run through offer-answer twice

On 27/10/16 10:10, Oliver Hausler wrote:

I see you are communicating the whole ssrc package to other clients,
with cname, msid, etc.

a=ssrc:1553632356 cname:X4D3HtZhdlifhKJH

a=ssrc:1553632356 msid:92c32f79-b75a-44d1-b5e5-ea1c877d8956
ca9c8608-f811-4177-bef7-1af9373ad628

a=ssrc:1553632356 mslabel:92c32f79-b75a-44d1-b5e5-ea1c877d8956

a=ssrc:1553632356 label:ca9c8608-f811-4177-bef7-1af9373ad628

Doesn't colibri only support patching the SSRC? I assume you keep the
other information in a separate structure outside Jitsi? Is this correct?

Yes msid, mslabel and label are managed in jicofo and don't reach jitsi-videobridge.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

When do I need to patch the new ssrcs into colibri?

- when I create the second offer sdp,
- or when I receive the answer?

The client won't add any further send ssrcs anymore during the second exchange. Is there any reason to patch colibri a second time, after I receive the second answer?

Is there anything that needs to be synchronized externally?

- When a new participant enters, I create an offer.
- The participant will answer and I add the streams to Jitsi.

Let's say 2 participants enter at the same time. Will I need to finish processing the first and then the second, or is it irrelevant in which order the answers are patched?

In other words: Do we need to complete full offer-answer cycles, or can I generate offers as participants enter and patch answers in any order?

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: Thursday, October 27, 2016 08:16
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] Why does meet.jit.si run through offer-answer twice

On 27/10/16 10:10, Oliver Hausler wrote:

I see you are communicating the whole ssrc package to other clients,
with cname, msid, etc.

a=ssrc:1553632356 cname:X4D3HtZhdlifhKJH

a=ssrc:1553632356 msid:92c32f79-b75a-44d1-b5e5-ea1c877d8956
ca9c8608-f811-4177-bef7-1af9373ad628

a=ssrc:1553632356 mslabel:92c32f79-b75a-44d1-b5e5-ea1c877d8956

a=ssrc:1553632356 label:ca9c8608-f811-4177-bef7-1af9373ad628

Doesn't colibri only support patching the SSRC? I assume you keep the
other information in a separate structure outside Jitsi? Is this correct?

Yes msid, mslabel and label are managed in jicofo and don't reach jitsi-videobridge.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev