Turn by turn publishing problem

1

Hello,

Here is the use case scenario we’re trying to achieve:

  1. User 1 broadcasts a stream.
  2. User 2 receives that stream.
  3. User 1 stops broadcasting.
  4. User 2 broadcasts his stream.
  5. User 1 receives that stream.

It’s turn by turn publishing and subscribing.

We have problems on step 3 and onward. Here’s our technical implementation:

  1. Create room → OK.
  2. Users 1 and 2 join and get tokens → OK.
  3. User 1 publishes → OK.
  4. User 2 subscribes → OK.
  5. User 1 unpublishes → User 2 stops receiving the stream, and user 1
    gets an “Uncaught Error in RoapOnJsep: Dazed and confused in state
    offer-sent, stopping here”.
  6. User 2 publishes → no effect. Nothing happens.
  7. If user 1 tries to republish again, nothing happens.

We’re currently unable to get a robust publish / unpublish behavior.
BTW, we frequently get the “Dazed and confused” console log while user 1 is
broadcasting and yet, the broadcast is successful and user 2
still receives user 1’s stream.

It is important for the user experience that we get fault tolerance and
exceptions management. If for whatever reason a user stops streaming
unintentionally, we should be able to automagically republish his stream,
and all subscribing users would be kept up to date.

Did you ever get this use case scenario?
Do you have some advice or tips on how to achieve a robust turn by turn
publishing pattern?

Thank you,
Achraf.

2

Hi,

I’m trying to duplicate the error but I can’t. The only idea that I have is
that you are not using the last version of erizoClient.

Note that is not enough with a git pull, you also need to compile
erizoClient (executing lynckia / erizo_controller / erizoClient / tools
/compile.sh) and serve the resulting file ( lynckia / erizo_controller /
erizoClient / dist / erizo.js) in your application (if you are using the
basic_example copy erizo.js to its public folder).

Another option is to follow again the steps in the installation
instructions.

Regards,
Álvaro2013/2/28 Achraf Kassioui achrafkassioui@gmail.com

Oh I forgot to mention that with the second method, user 2 can publish a
stream and user 1 does subscribe to that stream. Whereas with method 1,
user 1 can no longer receive any stream.

–
You received this message because you are subscribed to the Google Groups
“lynckia” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lynckia+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

Álvaro

3

Hi Álvaro,

We are using the latest version of Lynckia… the one before your update
for Chrome 25 this morning.

For the publish/unpublish/republish pattern, we were using:

var room = Erizo.Room({token: some-token});
room.connect();
room.publish(localStream);

Then for unpublishing:

room.unpublish(localStream);

Here we got the dizziness and confusion error, and if we:

room.publish(localStream);

The subscriber on the other end does not receives a stream.

We managed to get rid of the confusion error log using the stream.stop()
method:

room.publish(localStream);
localStream.stream.stop();

But in both cases, we’re still unable to republish user 1 stream. We are
currently trying various methods.
What do you think?

Thank you,
Achraf.

4

Thanks Álvaro, we recompiled the relevant files and that solved the problem.

Best,
Achraf.

5

Hi Achraf,

are you using the last version of Lynckia? We solve a problem related
with “Dazed
and confused” log that you say some time ago. I don’t discard that it might
happend because another reason but I can’t reproduce the error publishing
and unpublishing streams.

Regards,
Álvaro2013/2/26 Achraf Kassioui achrafkassioui@gmail.com

Hello,

Here is the use case scenario we’re trying to achieve:

  1. User 1 broadcasts a stream.
  2. User 2 receives that stream.
  3. User 1 stops broadcasting.
  4. User 2 broadcasts his stream.
  5. User 1 receives that stream.

It’s turn by turn publishing and subscribing.

We have problems on step 3 and onward. Here’s our technical implementation:

  1. Create room → OK.
  2. Users 1 and 2 join and get tokens → OK.
  3. User 1 publishes → OK.
  4. User 2 subscribes → OK.
  5. User 1 unpublishes → User 2 stops receiving the stream, and user 1
    gets an “Uncaught Error in RoapOnJsep: Dazed and confused in state
    offer-sent, stopping here”.
  6. User 2 publishes → no effect. Nothing happens.
  7. If user 1 tries to republish again, nothing happens.

We’re currently unable to get a robust publish / unpublish behavior.
BTW, we frequently get the “Dazed and confused” console log while user 1
is broadcasting and yet, the broadcast is successful and user 2
still receives user 1’s stream.

It is important for the user experience that we get fault tolerance and
exceptions management. If for whatever reason a user stops streaming
unintentionally, we should be able to automagically republish his stream,
and all subscribing users would be kept up to date.

Did you ever get this use case scenario?
Do you have some advice or tips on how to achieve a robust turn by turn
publishing pattern?

Thank you,
Achraf.

–
You received this message because you are subscribed to the Google Groups
“lynckia” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lynckia+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

Álvaro

6

Oh I forgot to mention that with the second method, user 2 can publish a
stream and user 1 does subscribe to that stream. Whereas with method 1,
user 1 can no longer receive any stream.