856927 - Trying to do two handshakes in a row with a single addStream at the beginning results in INTERNAL_ERROR on setRemoteDescription

Status: RESOLVED DUPLICATE of bug 857115

(Core :: WebRTC, defect)

Description

[Jason Smith [:jsmith]]

Attachment: Mochitest

STR - Run the attached mochitest.

Expected:

If we try to do two handshakes in a row, my initial thoughts is that we shouldn't fail in this case. But this needs to double checked.

Actual:

We fail at one of the setRemoteDescription callbacks with:

Unexpected error callback with name = 'INTERNAL_ERROR', message = 'Unspecified Error processing setRemoteDescription'

Comment 1

[Jason Smith [:jsmith]]

Attachment: Console Output

Comment 2

[Jason Smith [:jsmith]]

And those useful error callback messages finally pay off.

Anyways - Adam - Any ideas?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

I believe this is trying to add two audio streams (or two audio and two video streams) to the same peerconnection.  We don't support multiple streams of the same type yet.

Comment 4

[Adam Roach [:abr]]

(In reply to Jason Smith [:jsmith] from comment #2)
> And those useful error callback messages finally pay off.

What we thought was important for 22 was that the interface was fixed to return the right kind of response to the content js (modulo bug 842531) even if we couldn't hook it up to more useful information yet.  Plumbing through actual causes with useful reason phrases remains a priority.

I'm deferring to jesup on the cause of the bug.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #3)
> I believe this is trying to add two audio streams (or two audio and two
> video streams) to the same peerconnection.  We don't support multiple
> streams of the same type yet.

Nope, this isn't right. addStream is only getting called once in this workflow. If that was the case, NS_ERROR_FAILURE would have fired.

So this is different flow. Reopening.

Comment 6

[Jason Smith [:jsmith]]

FWIW, there's only a single audio stream involved in this entire workflow added only once. It's just that the handshake happens twice in a row.

Comment 7

[Jason Smith [:jsmith]]

Commands per console log:

1. PC_LOCAL_GUM
2. PC_REMOTE_GUM
3. PC_LOCAL_CREATE_OFFER
4. PC_LOCAL_SET_DESCRIPTION
5. PC_REMOTE_SET_DESCRIPTION
6. PC_REMOTE_CREATE_ANSWER
7. PC_LOCAL_SET_REMOTE_DESCRIPTION
8. PC_REMOTE_SET_LOCAL_DESCRIPTION
9. PC_LOCAL_CHECK_MEDIA
10. PC_REMOTE_CHECK_MEDIA
11. PC_LOCAL_CREATE_OFFER
12. PC_LOCAL_SET_LOCAL_DESCRIPTION
13. PC_REMOTE_SET_REMOTE_DESCRIPTION

Comment 8

[Jason Smith [:jsmith]]

Looking at the logs:

0[12eafc98]: [GSM Task|fsm_sm] fsmdef.c:3309: SIPCC-FSM: fsmdef_ev_setremotedesc: Renegotiation not currently supported.

So I'm guessing the reason why this test is actually failing isn't a streams issue, it's the fact renegotiation isn't supported.

Comment 9

[Jason Smith [:jsmith]]

Apparently we don't support renegotiation yet, so that's why this is failing with the error callback. I've filed bug 857115 to track the work to implement this, so I'm duping on that bug.