Double call "onGetUserMediaSuccess" and "createAnswer". Sipml5 can't answer on some calls and sends BYE.

[GoogleCodeExporter]

What steps will reproduce the problem?

The problem is reproduced unstable. The series of calls can be successful 
before failure.

What is the expected output? What do you see instead?

Expected output:

SIPml-api.js:1 State machine: s0000_Ringing_2_Connected_X_Accept
SIPml-api.js:1 onSignalingstateChange:have-remote-offer
SIPml-api.js:1 onGetUserMediaSuccess
SIPml-api.js:1 createAnswer
SIPml-api.js:1 onSetRemoteDescriptionSuccess
SIPml-api.js:1 onCreateSdpSuccess
SIPml-api.js:1 __on_add_stream
SIPml-api.js:1 onNegotiationNeeded
SIPml-api.js:1 onSignalingstateChange:stable
SIPml-api.js:1 onSetLocalDescriptionSuccess
10SIPml-api.js:1 onIceCandidate = gathering
SIPml-api.js:1 onIceCandidate = complete
SIPml-api.js:1 ICE GATHERING COMPLETED!
SIPml-api.js:1 onIceGatheringCompleted
SIPml-api.js:1 State machine: tsip_transac_ist_Proceeding_2_Accepted_X_2xx
SIPml-api.js:1 SEND: SIP/2.0 200 OK
Via: SIP/2.0/WSS 54.84.102.56:5260;rport=5260;branch=z9hG4bKNFeScNQ7NjS6m
From: "1003"<sip:[email protected]>;tag=vSFFagK514rHQ
To: 
<sip:[email protected];rtcweb-breaker=no;transport=wss;received=5.17.143
.16:52708>;tag=hiJ7p9x8rJoqedka963W
Contact: <sips:[email protected];transport=wss>
Call-ID: 2e1733cf-28cf-1233-ddad-1276e53d47fc
CSeq: 71287245 INVITE
Content-Type: application/sdp
Content-Length: 2426
Allow: ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE

Failure:

SIPml-api.js:1 State machine: s0000_Ringing_2_Connected_X_Accept
SIPml-api.js:1 onGetUserMediaSuccess
SIPml-api.js:1 createAnswer
SIPml-api.js:1 onSetRemoteDescriptionSuccess
SIPml-api.js:1 onCreateSdpSuccess
SIPml-api.js:1 onSignalingstateChange:have-remote-offer
SIPml-api.js:1 onGetUserMediaSuccess
SIPml-api.js:1 createAnswer
SIPml-api.js:1 __on_add_stream
SIPml-api.js:1 onNegotiationNeeded
SIPml-api.js:1 onSetLocalDescriptionSuccess
SIPml-api.js:1 onCreateSdpSuccess
SIPml-api.js:1 onSignalingstateChange:stable
SIPml-api.js:1 onSetLocalDescriptionError
SIPml-api.js:1 State machine: x0000_Any_2_Trying_X_oBYE
SIPml-api.js:1 SEND: BYE sip:[email protected]:5260 SIP/2.0
Via: SIP/2.0/WSS 
df7jal23ls0d.invalid;branch=z9hG4bKuOWOFM7bGNknvFCiPg9wTXeisIDmprfA;rport
From: <sip:[email protected]>;tag=gprwcPxgP4aAhps65HMF
To: "1003"<sip:[email protected]>;tag=QaZ0F58H9XQ7Q
Call-ID: 5416e4a6-28cb-1233-ddad-1276e53d47fc
CSeq: 14627 BYE
Content-Length: 0
Max-Forwards: 70
Accept-Contact: *;+g.oma.sip-im
Accept-Contact: *;+sip.ice
Accept-Contact: *;language="en,fr"
Accept-Contact: *;+g.oma.sip-im
Accept-Contact: *;+sip.ice
Accept-Contact: *;language="en,fr"
User-Agent: IM-client/OMA1.0 sipML5-v1.0.0.0

What version of the product are you using? On what operating system?
SIPML5 version = 1.5.222
Client's OS:  Windows 7 Enterprise, MAC OS X Yosemite 
Browsers: Chrome (40.0.2214.111)

Please provide any additional information below.
See attached full SIP logs:  failure.log and success.log
Also please notice that in failure case we can see double call 'createAnswer' 
method for an unknown reason.

Please advise. Thanks in advance.

Original issue reported on code.google.com by [email protected] on 9 Feb 2015 at 11:09

Attachments:

• failure.log
• success.log

[GoogleCodeExporter]

I research this flying trouble and  make hack-patch for it. Test in 
Chrome-Chrome , Chrome-FF, FF-Chrome p2p call.

tmedia_session_jsep01.onGetUserMediaSuccess = function (o_stream, _This) {
    tsk_utils_log_info("onGetUserMediaSuccess");
    var This = (tmedia_session_jsep01.mozThis || _This);
    if (This && This.o_pc && This.o_mgr) {
        if(!This.b_sdp_lo_pending){
            tsk_utils_log_warn("onGetUserMediaSuccess but no local sdp request is pending");
            return;
        }

     if(This.my_mutex){tsk_utils_log_warn("onGetUserMediaSuccess already executed!"); return;}
     This.my_mutex=true;

        if (o_stream) {
            // HACK: patch for Firefox and others
            // https://groups.google.com/group/discuss-webrtc/browse_thread/thread/e30f0ffc267bce5f
            if (!o_stream.videoTracks || !o_stream.audioTracks) {
                var b_support_audio = !!(This.e_type.i_id & tmedia_type_e.AUDIO.i_id);
                var b_support_video = !!(This.e_type.i_id & tmedia_type_e.VIDEO.i_id);
                o_stream.audioTracks = o_stream.getAudioTracks ? o_stream.getAudioTracks() : { length: b_support_audio ? 1 : 0 };
                o_stream.videoTracks = o_stream.getVideoTracks ? o_stream.getVideoTracks() : { length: b_support_video ? 1 : 0 };
            }

            // save stream other next calls
            if (o_stream.audioTracks.length > 0 && o_stream.videoTracks.length == 0) {
                __o_jsep_stream_audio = o_stream;
            }
            else if (o_stream.audioTracks.length > 0 && o_stream.videoTracks.length > 0) {
                __o_jsep_stream_audiovideo = o_stream;
            }

            if (!This.o_local_stream) {
                This.o_mgr.callback(tmedia_session_events_e.STREAM_LOCAL_ACCEPTED, this.e_type);
            }

            // HACK: Firefox only allows to call gum one time
            if (tmedia_session_jsep01.mozThis) {
                __o_jsep_stream_audiovideo = __o_jsep_stream_audio = o_stream;
            }

            This.o_local_stream = o_stream;
            This.o_pc.addStream(o_stream);
        }
        else {
            // Probably call held
        }
        This.o_mgr.set_stream_local(o_stream);

        var b_answer = ((This.b_sdp_ro_pending || This.b_sdp_ro_offer) && (This.o_sdp_ro != null));
        if (b_answer) {
            tsk_utils_log_info("createAnswer");
            This.o_pc.createAnswer(
                tmedia_session_jsep01.mozThis ? tmedia_session_jsep01.onCreateSdpSuccess : function(o_offer){ tmedia_session_jsep01.onCreateSdpSuccess(o_offer, This); },
                tmedia_session_jsep01.mozThis ? tmedia_session_jsep01.onCreateSdpError : function(s_error){ tmedia_session_jsep01.onCreateSdpError(s_error, This); },
                This.o_media_constraints,
                false // createProvisionalAnswer
            );
        }
        else {
            tsk_utils_log_info("createOffer");
            This.o_pc.createOffer(
                tmedia_session_jsep01.mozThis ? tmedia_session_jsep01.onCreateSdpSuccess : function(o_offer){ tmedia_session_jsep01.onCreateSdpSuccess(o_offer, This); },
                tmedia_session_jsep01.mozThis ? tmedia_session_jsep01.onCreateSdpError : function(s_error){ tmedia_session_jsep01.onCreateSdpError(s_error, This); },
                This.o_media_constraints
            );
        }
    }
}

Original comment by [email protected] on 18 Feb 2015 at 1:48

[GoogleCodeExporter]

@[email protected]

Wow, guy, that's just the solution I were looking for, and just the time it was 
about to hit the fan!
Problem with sipml5 + chrome 40-41 + asterisk 11.15-11.16.

I'd gladly buy a chicken and sacrifice it for deity of your choice.

Original comment by [email protected] on 19 Feb 2015 at 11:05

[GoogleCodeExporter]

What do you think will be this patch-update in the next official release?

We rolled back to the stable version 1.4.217. But most likely we need the 
additional support for the FF browser. Looking forward to the FF-36 release, 35 
doesn't work for us.

In any case, thank you for support and answers in this post!

Original comment by [email protected] on 19 Feb 2015 at 11:37

[GoogleCodeExporter]

Original comment by [email protected] on 18 Mar 2015 at 9:03

• Changed state: Accepted

[GoogleCodeExporter]

wonderful ! I've also came to conclusion to that createAnswer happens twice 
ONLY and ALWAYS in faulty calls, but failed to understand, why in the sake of 
heaven does it lead to 

Failed to set local answer sdp: Called in wrong state: STATE_SENTACCEPT

Fortunately, this tiny fix seems to do the job, I wonder if there're any 
side-effects possible ? 

Once again: cheers to patch author !!

Original comment by [email protected] on 12 Aug 2015 at 1:13