When a call is made respect the video or audio setting for each party independently

[atsakiridis]

Currently if a call is started as audio and the remote party answers with video then both media streams only carry audio. Instead, it would be more efficient if the video setting of the answering party was respected and the answering party sent video to the calling party

This goes the other way around as well: if the caller started a video call and the receiver answers with audio then the caller should send video while the receiver send just audio.

[jaimecasero]

Reproduced. Both Invite and 200Ok looks good with proper M lines (video&audio for bob). There is an error at then end " jain-sip.js:25514:4
12:23:28.351 "WebRTCommCall:onPrivateCallConnectorRemoteSdpAnswerEvent()" WebRTComm.js:3275:4
12:23:28.357 "WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionSuccessEvent()" WebRTComm.js:3947:8
12:23:28.358 "WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionSuccessEvent(): this.peerConnection.signalingState=stable" WebRTComm.js:3950:12
12:23:28.358 "WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionSuccessEvent(): this.peerConnection.iceGatheringState=complete" WebRTComm.js:3951:12
12:23:28.358 "WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionSuccessEvent(): this.peerConnection.iceConnectionState=new" WebRTComm.js:3952:12
12:23:28.358 "WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionSuccessEvent(): this.peerConnectionState=answer-received" WebRTComm.js:3953:12
12:23:28.359 "WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionSuccessEvent(): this.peerConnectionState=established" WebRTComm.js:3958:2
12:23:28.366 "delivered" Object { id: String[13], webRTCommClient: Object, calleePhoneNumber: "bob@telestax.com", callerPhoneNumber: "alice", callerDisplayName: undefined, incomingCallFlag: false, configuration: Object, connector: Object, peerConnection: mozRTCPeerConnection, peerConnectionState: "established", 8 more… } room.js:392:4
12:23:28.368 "Error: Argument 1 is not valid for any of the 2-argument overloads of URL.createObjectURL.
@http://192.168.183.128:8080/olympus/resources/js/controllers/room.js:398:54
$RootScopeProvider/this.$get</Scope.prototype.$eval@http://192.168.183.128:8080/olympus/lib/angular/angular.js:14388:16
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://192.168.183.128:8080/olympus/lib/angular/angular.js:14487:18
@http://192.168.183.128:8080/olympus/resources/js/controllers/room.js:393:1
$RootScopeProvider/this.$get</Scope.prototype.$broadcast@http://192.168.183.128:8080/olympus/lib/angular/angular.js:14707:15
this.onWebRTCommCallOpenedEvent@http://192.168.183.128:8080/olympus/resources/js/services.js:54:5
WebRTCommCall.prototype.onRtcPeerConnectionSetRemoteDescriptionSuccessEvent/<@http://192.168.183.128:8080/olympus/resources/js/mobicents-libs/WebRTComm.js:3965:29
" angular.js:11598:17

I'll have a look to that..

[jaimecasero]

Apparently offer flags in sdpContraints are initiated using CallConfiguration:
var sdpConstraints = {
mandatory:
{
OfferToReceiveAudio: this.configuration.audioMediaFlag,
OfferToReceiveVideo: this.configuration.videoMediaFlag
},
optional: []
};

So, if initiator calls without video, the code assumes OfferToReceiveVideo=false

[jaimecasero]

Testing with SDPcontraints setting offerReceiveVideo to true made the trick.
The initial assumption that an audioCall should not offerToReceive video could make sense in some scenarios.
Strangely enough, when alice makes an audioCall, the M lines for video are still populated, since the user allowed for localmediastream, so bob wil receive video anyway (if bob answers with videoCall).

Actual implementation for "audio" call only "works" when both users select audio call.

Whatever behaviour we want to introduce, the sdpcontraints will limit the URL created for the stream webrtc will use.

I kindly ask for opinions here, since this is really up to the user to decide, in my opinion.

[deruelle]

Being implemented in #8