Re: [discuss-webrtc] "SetLocalDescription failed."

Nick Foster

unread,

Dec 20, 2012, 10:16:14 AM12/20/12

to discuss...@googlegroups.com

Just looking at the SDP there are no a=candidate lines, therefore no way to use ICE to determine the best path between the two endpoints. This is just a guess so far. The Chrome team is working on adding better error messaging in the console for future versions of chrome. For now check the the chrome debug logs for any hints as to what might be going on..

https://plus.google.com/u/0/103619602351433955946/posts/NTwabYKd15U

- Nick

On Wed, Dec 19, 2012 at 5:09 PM, Ken Smith <smit...@gmail.com> wrote:

I'm scratching my head on this one. When I receive an offer over my signaling channel, I handle it like so (this is TypeScript, so it looks a bit funky, sorry about that):

connection.peerConnection.setRemoteDescription(sessionDescription, () => {
 
    // Answer the call by sending a JsepAnswer message.
    connection.peerConnection.createAnswer(
        answer => {
            connection.peerConnection.setLocalDescription(answer, () => {
                var signalState: mData.SignalState = {
                    FromSessionId: connection.localSessionId,
                    ToSessionId: connection.remoteSessionId,
                    Message: JSON.stringify(answer)
                };
                me.roomHub.server.jsepAnswer(signalState);
                mUtil.log("Sent JSEP answer: " + signalState.Message);
                connection.readyForIceCandidates.resolve();
            },
            error => {
                mUtil.error("Error setting local description from created answer: " + error + "; answer=" + JSON.stringify(answer));
            });
        },
    error => {
        mUtil.error("Error creating answer: " + error);
    }, me.mediaConstraints);
},
error => {
    mUtil.error('Error setting remote description: ' + error);
});

But when I call "setLocalDescription()", the error callback gets triggered, with the error message "SetLocalDescription failed."

That sounds odd to me, given that all I'm doing is just passing in the object I got handed from "createAnswer()", but perhaps I'm missing something.

Here's the SDP from createAnswer() that's triggering the error:

v=0 o=- 197570408 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcX m=audio 1 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:lXoUv2JUfztu+2jr a=ice-pwd:aMHrNyi06JUpGnr2CbANoz9i a=sendrecv a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:DKnnAG7n9kfq7Y54DpyHEZbG2tJTa7Eb1h+41ICt a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:111 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 CN/48000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=ssrc:80113139 cname:L2mrEXlF3k/OJECT a=ssrc:80113139 msid:XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcX a0 a=ssrc:80113139 mslabel:XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcX a=ssrc:80113139 label:XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcXa0 m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:lXoUv2JUfztu+2jr a=ice-pwd:aMHrNyi06JUpGnr2CbANoz9i a=sendrecv a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:DKnnAG7n9kfq7Y54DpyHEZbG2tJTa7Eb1h+41ICt a=rtpmap:100 VP8/90000 a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:4140472875 cname:L2mrEXlF3k/OJECT a=ssrc:4140472875 msid:XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcX v0 a=ssrc:4140472875 mslabel:XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcX a=ssrc:4140472875 label:XHFWEaGdJP1bPOPJkzCMy874B6jlXC0Z2kcXv0

Any thoughts about what might be going on here, or how to troubleshoot it?

I've posted the code for my demo out here:

https://bitbucket.org/smithkl42/signalr.webrtc

And the critical WebRTC stuff is here:

https://bitbucket.org/smithkl42/signalr.webrtc/src/tip/SignalR.WebRTC/Scripts/Media/WebRTC.ts?at=default

Thanks in advance.

Ken Smith

--

Ken Smith

unread,

Dec 20, 2012, 12:53:15 PM12/20/12

to discuss...@googlegroups.com

Thanks, Nick. I've turned on logging in Chrome, and this is what the debug log looks like:

[6584:340:1220/091303:ERROR:rtc_video_capture_delegate.cc(88)] NOT IMPLEMENTED

[6584:340:1220/091341:ERROR:rtc_video_capture_delegate.cc(57)] NOT IMPLEMENTED

[6584:340:1220/091343:ERROR:rtc_video_capture_delegate.cc(88)] NOT IMPLEMENTED

[6584:7308:1220/091350:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null.

[6584:340:1220/091356:ERROR:rtc_video_capture_delegate.cc(88)] NOT IMPLEMENTED

[6584:7308:1220/091356:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null.

(and lots more of those)

I'm not sure if the "native session description is null" error is more the cause of the result of the setLocalDescription() error.

Agreed that there's no "a=candidate" lines - but I don't see any of those lines in the SDP generated for either the offer or the answer in the working demo at http://apprtc.appspot.com/ either; nor in the working demo I created earlier at http://demo.alanta.com/.

The main other thing I've observed over the last several days is that the error is inconsistent. Although I'm not changing anything, sometimes the initiating browser throws the error, when I'm setting the local description after having created the offer. And sometimes it's the responding browser that throws the error when it's setting the local description after having created the answer. And sometimes neither browser throws an error, but it still doesn't work. And occasionally (maybe one out of 10 times) I'll see remote video on one browser but not the other; once or twice I've seen audio but no video; and very occasionally (maybe once out of 20 or 30 times), it'll work flawlessly both directions.

I've pushed the code I'm running into trouble with out to http://srdemo.alanta.com/. I'd certainly appreciate any additional advice.

Ken Smith
Cell: 425-443-2359
Email: smit...@gmail.com

Blog: http://blog.wouldbetheologian.com/

--

Ken Smith

unread,

Dec 20, 2012, 6:33:05 PM12/20/12

to discuss...@googlegroups.com

Well, I've managed to narrow down the problem, though I'm still scratching my head. I've put together two different demo sites, one using a technology called XSockets.NET for the signaling layer (see http://xsockets.net/), the other using a technology called SignalR (http://signalr.net/). The two backends are fundamentally identical, differing only at the points where they (obviously) have different ways of sending data down to the client. The TypeScript/JavaScript WebRTC code on the two clients is also basically identical, only differing at the points where it needs to interact with the signaling layer.

XSockets site: http://xsockets.demo.alanta.com/

SignalR site: http://signalr.demo.alanta.com/

And the XSockets site works consistently, while the SignalR site fails (mostly consistently, though not completely), typically (though not always) while calling setLocalDescription().

Does that make sense to anybody else? Is it possible, for instance, that the SignalR version is (I dunno) sending Unicode strings down, which is making WebRTC barf? Or have I managed to overlook something incredibly obvious to everyone else?

Ken Smith
Cell: 425-443-2359
Email: smit...@gmail.com

Blog: http://blog.wouldbetheologian.com/

Nick Foster

unread,

Dec 20, 2012, 9:54:56 PM12/20/12

to discuss...@googlegroups.com

The appspot demo app certainly does have candidate lines in the SDP. These are required for ICE, and ICE is required for WebRTC to function since almost guaranteed at least one endpoint needs to do NAT traversal.

Have you tried wireshark to see if any messages are being blocked by your firewall? The app needs to make a request to a STUN server to obtain candidates to put in the SDP. Sounds like this might not be happening. Anything in the logs about ICE failing?

- Nick

On Thu, Dec 20, 2012 at 9:53 AM, Ken Smith <smit...@gmail.com> wrote:

--

Ken Smith

unread,

Dec 21, 2012, 12:47:07 AM12/21/12

to discuss...@googlegroups.com

It's quite possible I'm misunderstanding something. So here's the SDP answer on my app that's typically tripping things up:

v=0 o=- 80808742 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6 m=audio 1 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:Wz+9CgISvt5LJso7 a=ice-pwd:mPmN3v9TdICxgGowQOfezh9x a=sendrecv a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WH1e+TmkZ5TZiZO5IL5ACnn6eFPBxAZ31j/WV47u a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:111 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 CN/48000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=ssrc:525737257 cname:tMhCMlDcHPQ9YT+r a=ssrc:525737257 msid:Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6 a0 a=ssrc:525737257 mslabel:Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6 a=ssrc:525737257 label:Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6a0 m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:Wz+9CgISvt5LJso7 a=ice-pwd:mPmN3v9TdICxgGowQOfezh9x a=sendrecv a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WH1e+TmkZ5TZiZO5IL5ACnn6eFPBxAZ31j/WV47u a=rtpmap:100 VP8/90000 a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:4012809449 cname:tMhCMlDcHPQ9YT+r a=ssrc:4012809449 msid:Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6 v0 a=ssrc:4012809449 mslabel:Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6 a=ssrc:4012809449 label:Aof1QTxlu2LvqTNwYyYdfa5RMzUERdRYmoZ6v0

And here's the SDP answer on the apprtc.appspot.com app:

v=0 o=- 4077486141 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS 0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aq m=audio 1 RTP/SAVPF 103 104 111 0 8 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:lrpzntqi73wNelp7 a=ice-pwd:7lCZnQMvPn0obRFRpCoF/2th a=sendrecv a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0K59McpfX6vMgkuWVzB+FcWy1n84OAQqPC76PLcf a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:111 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=ssrc:2275117928 cname:DCpJuXVVvU5hvplx a=ssrc:2275117928 msid:0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aq a0 a=ssrc:2275117928 mslabel:0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aq a=ssrc:2275117928 label:0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aqa0 m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:lrpzntqi73wNelp7 a=ice-pwd:7lCZnQMvPn0obRFRpCoF/2th a=sendrecv a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0K59McpfX6vMgkuWVzB+FcWy1n84OAQqPC76PLcf a=rtpmap:100 VP8/90000 a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:3607793023 cname:DCpJuXVVvU5hvplx a=ssrc:3607793023 msid:0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aq v0 a=ssrc:3607793023 mslabel:0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aq a=ssrc:3607793023 label:0dYpIlv8NmtCRBioTjX0FxuBwHQBoQHCn5Aqv0

Neither of those have "a=candidate" lines in them.

That said, I do see that there are "a=candidate" lines in the ICE candidates that get sent back and forth - but both of mine have those as well, both the one that's working (http://xsockets.demo.alanta.com/) and the one that's failing (http://signalr.demo.alanta.com/):

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 13811 typ host generation 0\r\n"}

I'm reasonably sure that nothing is getting blocked by my firewall, or at least, nothing interesting: because I've got virtually identical applications, one of which is working, and one of which is failing, and the only difference - like, down to the byte level - between the two is that one is using XSockets.NET for its signaling layer (which uses WebSockets behind the scenes), and the other uses SignalR (which is using long polling behind the scenes).

At this point, I'm becoming more and more convinced that this is an honest-to-goodness bug somewhere in Chrome's WebRTC implementation. I just don't know exactly where.

Ken Smith
Cell: 425-443-2359
Email: smit...@gmail.com

Blog: http://blog.wouldbetheologian.com/

Nick Foster

unread,

Dec 21, 2012, 1:07:09 AM12/21/12

to discuss...@googlegroups.com

I have only dealt with putting the candidate lines in the SDP. Based on what you are showing it seems that you can also deal with the candidates being passed to each other by other means. It looks like this is what apprtc is now doing, not sure but I don't think it always did. I think at some point in the past it put the candidate lines in the SDP but this may not be true.

Based on your email about the two apps with different transport i agree it seems like there could be an issue with how the sdp is sent. Can you check in wireshark to see if the right newlines are being sent in both versions?

- Nick

--

Ken Smith

unread,

Dec 21, 2012, 4:41:58 AM12/21/12

to discuss...@googlegroups.com

OK, got it figured out. It was a bug, but not in WebRTC.

Turns out that SignalR 1.0 RC1 has a bug in it that changes any "+" in a string into a space. So lines in the SDP that looked like this:

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2+z

Were getting changed into this:

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2 z

But because not every SDP had a "+" in it on a critical line, sometimes it would work. Everything explained.

The bug has been reported to the good folks working on SignalR (see https://github.com/SignalR/SignalR/issues/1194), and in the meantime, a simple `encodeURIComponent()` and `decodeURIComponent()` around the strings in question fixed it.

Ken Smith
Cell: 425-443-2359
Email: smit...@gmail.com

Blog: http://blog.wouldbetheologian.com/

--

Reply all

Reply to author

Forward