1196701 - setLocalDescription/setRemoteDescription with modified SDP doesn't work for Hold, Unhold(v38+)

Status: RESOLVED INVALID

(Core :: WebRTC: Signaling, defect, P2)

Description

[rajkumaradass]

Attachment: Hold_UnholdFailure_Logs.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.46 Safari/537.36

Steps to reproduce:

Steps to reproduce:

1. Make webRTC - webRTC audio+video call .
2. Call connected and two way media path is successful
3. If user tries hold by modifiying the initial generated offer SDP to have "a=inactive" for audio & video media types and applies with setLocalDescription.
4. Remote SDP is modified to have "a=inactive" for audio & video media types and applied with setRemoteDescription.





Actual results:

Steps 3 fails with below error( from nspr.log)

2015-08-20 11:15:47.708000 UTC - 0[2911140]: [main|PeerConnectionImpl] PeerConnectionImpl.cpp:1527: mozilla::PeerConnectionImpl::SetLocalDescription: pc = cdfd30188083d84e, error = Calling SetLocal without first calling CreateOffer/Answer is not supported.

Steps 3 fails with below error( from nspr.log)
2015-08-20 09:30:22.606000 UTC - 0[2911140]: [main|PeerConnectionImpl] PeerConnectionImpl.cpp:1626: mozilla::PeerConnectionImpl::SetRemoteDescription: pc = b04b4ad38477b65a, error = Cannot set remote answer in state stable



Expected results:

Both step3 and step4 should be successful.

Comment 1

[Byron Campen [:bwc]]

You cannot reuse SDP on a subsequent offer/answer exchange. You must create a new SDP using CreateOffer/CreateAnswer as appropriate. Also, you cannot modify the direction attribute like this. You can, however, remove the track and renegotiate to stop sending. I am not aware of a way to force the other side to do the same under the current JSEP spec, since it requires the offerer to always offer to receive on m-sections that were receiving before.

Comment 2

[rajkumaradass]

This appears to be different from how it is in chrome currently. Chrome does allow SDP mangling and re-apply regardless of createOffer/CreateAnswer sequence. Also i remember Firefox does not have removeTrack support yet in it? Could you please confirm

Comment 3

[rajkumaradass]

I meant this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1103188

Comment 4

[Byron Campen [:bwc]]

We support this: http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-removeTrack-void-RTCRtpSender-sender

We support some amount of SDP mangling, but not mangling of direction really (it _might_ work, but I would not bet on it, since this is not something we ever intended to support, nor did the working group as far as I know). What SDP mangling is supposed to be supported is not really defined at all right now, and there isn't even an issue open on the tracker (http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-setLocalDescription-Promise-void--RTCSessionDescription-description)

According to the w3c spec, an SDP generated by createOffer/Answer is only guaranteed to be valid until the success callback returns, meaning that you should probably be using it immediately. In Firefox it currently remains valid until offer/answer concludes. This could shorten in the future due to things like codec reservation.

Lastly, there is an issue open for hold that maybe you can watch for developments, but I don't know if that's in scope for 1.0: https://github.com/w3c/webrtc-pc/issues/142