User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:23.0) Gecko/20130415 Firefox/23.0 Build ID: 20130415030812 Steps to reproduce: Attempted a WebRTC call from Chrome (Canary 28.0.1478.0) to Firefox Nightly (23.0a1 (2013-04-15)). Actual results: The call was rejected some of the time. Expected results: The calls should've been accepted. It would appear that when this problem occurs it coincides with the <sess-id> in the o= field of the offer SDP being > ~ 2^63. In the error callback from setRemoteDescription() I'm seeing the following error in the console: setRemoteDesc failed: {"name":"INVALID_SESSION_DESCRIPTION","message":"Could not process offer SDP; cause = ERR | SDP Parsing Error: Invalid owner session id specified for o=."} In this case the SDP looks like this: {"sdp":"v=0\r\no=- 16700715529380444573 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnK\r\nm=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:w5p9/A0+TOPCxorH\r\na=ice-pwd:zuM1FCsEpCOTBgMOFRdXgxa4\r\na=ice-options:google-ice\r\na=fingerprint:sha-256 9C:5B:C5:D2:B9:C3:6B:27:8A:7C:4F:2A:AF:FC:75:A0:08:4B:60:EF:53:60:79:E7:A4:04:20:6C:0F:6C:E0:2D\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:TXVAldaxJaB4eJB6udE/z04mdXfKvQexFxhXNTIw\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:107 CN/48000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:126 telephone-event/8000\r\na=maxptime:60\r\na=ssrc:3988243186 cname:nCL+9Zz3khQMv3d4\r\na=ssrc:3988243186 msid:EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnK EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnKa0\r\na=ssrc:3988243186 mslabel:EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnK\r\na=ssrc:3988243186 label:EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnKa0\r\nm=video 1 RTP/SAVPF 100 116 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:w5p9/A0+TOPCxorH\r\na=ice-pwd:zuM1FCsEpCOTBgMOFRdXgxa4\r\na=ice-options:google-ice\r\na=fingerprint:sha-256 9C:5B:C5:D2:B9:C3:6B:27:8A:7C:4F:2A:AF:FC:75:A0:08:4B:60:EF:53:60:79:E7:A4:04:20:6C:0F:6C:E0:2D\r\na=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:TXVAldaxJaB4eJB6udE/z04mdXfKvQexFxhXNTIw\r\na=rtpmap:100 VP8/90000\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack \r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\na=ssrc:1796189338 cname:nCL+9Zz3khQMv3d4\r\na=ssrc:1796189338 msid:EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnK EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnKv0\r\na=ssrc:1796189338 mslabel:EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnK\r\na=ssrc:1796189338 label:EvMbmWcQOr8qjMitEo80VpPoSqoxf9MPExnKv0\r\n","type":"offer","seqNum":0} When the sess-id is < ~ 2^63 then this error is not raised. I cannot see anything in RFC4566 that specifies a maximum length of the session ID.

Also, see: http://code.google.com/p/webrtc/issues/detail?id=1628 That suggest that Chrome might reduce the length of the sess-id

Ethan - Any ideas?

I believe this is the same issue as bug 859303

The spec says: The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. I believe the session id in the example above 16700715529380444573 is bigger than that. Looks like a 64bit unsigned int.

Per the comment added in sdp_token.c, sessionid is a 64-bit *signed* value, not 63 bits or 64-bit unsigned. RFC 3264: The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (2**62)-1, to avoid rollovers. RFC 4566 says it must be parsed as 1*DIGIT (without *any* maximum length), which implies unsigned values only are valid. The combination says only values from 0 - 2^63-1 pass both tests. That said, I can easily believe people have interpreted it as 0 - 2^64-1. So it may be wise to expand the limits to that, though to only generate max 2^63-1.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:22.0) Gecko/20100101 Firefox/22.0 I am able to reproduce this on Firefox 22 beta 6 (buildID: 20130617145905), latest Nightly (buildID: 20130618031335). Sometimes when trying to make a call it simply does not connect.

(In reply to Bogdan Maris [QA] [:bogdan_maris] from comment #6) > Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:22.0) Gecko/20100101 > Firefox/22.0 > > I am able to reproduce this on Firefox 22 beta 6 (buildID: 20130617145905), > latest Nightly (buildID: 20130618031335). Sometimes when trying to make a > call it simply does not connect. There can be many reasons why a call fails. What does your web console say when the call fails?

I am getting something like Warning: In RTCConfiguration passed to RTCPeerConnection constructor: Credentials not yet implemented. Omitting "turn:192.158.30.24:3478?transport=udp" Source File: https://apprtc.appspot.com/?r=06593630

(In reply to Bogdan Maris [QA] [:bogdan_maris] from comment #8) > I am getting something like > > Warning: In RTCConfiguration passed to RTCPeerConnection constructor: > Credentials not yet implemented. Omitting > "turn:192.158.30.24:3478?transport=udp" > Source File: https://apprtc.appspot.com/?r=06593630 That's already a known issue fixed for Fx23 or later. That shouldn't be causing the call to fail on Fx22 though.

suspect it's still there... should be an easy fix if so.

As far as I can tell, we're compliant with the spec here. There was a time when we would reject SDP versions greater than 2^62 - 1 (the limit on the _initial_ version), but that was fixed quite a while ago. I suspect that this was the cause of most of this trouble.