RTCMultiConnection v3 (Muaz Khan)
Scenario :
A opens connection with B
B joins connection with A
Note : Above scenario is perfect
A opens connection with C
C joins connection with A
Function which generates the error:
this.addRemoteSdp = function(remoteSdp, cb) {
console.log(remoteSdp, "before")
remoteSdp.sdp = connection.processSdp(remoteSdp.sdp);
console.log(remoteSdp, "after")
peer.setRemoteDescription(new RTCSessionDescription(remoteSdp), cb || function() {}, function(error) {
if (!!connection.enableLogs) {
console.error(JSON.stringify(error, null, '\t'), '\n', remoteSdp.type, remoteSdp.sdp);
}
});
};
Error generated by the function:
RTCMultiConnection.js:2669 {}
answer v=0
o=- 290917982199254640 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE data
a=msid-semantic: WMS
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:J7UX
a=ice-pwd:ED+zJrLHxUmKjqquaYENgvS5
a=fingerprint:sha-256 33:A9:C3:0D:F6:E6:B6:81:4A:5C:FF:C6:A0:40:93:1F:07:9A:03:9B:7E:71:8F:BC:5F:0A:F8:73:58:1A:0C:7A
a=setup:active
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024
Related
I'm trying to execute the sdm.devices.commands.CameraLiveStream.GenerateWebRtcStream command on a Nest Battery Cam which only support WebRTC streams and not RTSP anymore:
curl -X POST \
'https://smartdevicemanagement.googleapis.com/v1/enterprises/FOO/devices/BAR:executeCommand' \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $AT" \
--data-raw '{
"command" : "sdm.devices.commands.CameraLiveStream.GenerateWebRtcStream",
"params" : {
"offerSdp" : "v=0\r\no=- 3846095231 3846095231 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0\r\na=msid-semantic:WMS *\r\nm=video 52697 UDP/TLS/RTP/SAVPF 97 98 99 100 101 102\r\nc=IN IP4 192.168.178.30\r\na=sendrecv\r\na=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=mid:0\r\na=msid:da672441-0269-4c8d-a30f-690e81947987 d7634d8f-f452-455c-bd6e-c5aa890b3433\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=rtcp-mux\r\na=ssrc-group:FID 3144836330 4019375712\r\na=ssrc:3144836330 cname:a5ec0936-9faa-48c5-9d06-e61020812f0b\r\na=ssrc:4019375712 cname:a5ec0936-9faa-48c5-9d06-e61020812f0b\r\na=rtpmap:97 VP8/90000\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 goog-remb\r\na=rtpmap:98 rtx/90000\r\na=fmtp:98 apt=97\r\na=rtpmap:99 H264/90000\r\na=rtcp-fb:99 nack\r\na=rtcp-fb:99 nack pli\r\na=rtcp-fb:99 goog-remb\r\na=fmtp:99 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001f\r\na=rtpmap:100 rtx/90000\r\na=fmtp:100 apt=99\r\na=rtpmap:101 H264/90000\r\na=rtcp-fb:101 nack\r\na=rtcp-fb:101 nack pli\r\na=rtcp-fb:101 goog-remb\r\na=fmtp:101 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42e01f\r\na=rtpmap:102 rtx/90000\r\na=fmtp:102 apt=101\r\na=candidate:b5a862d0ae1ed7334dea68b94dfa8e6f 1 udp 2130706431 192.168.178.30 52697 typ host\r\na=candidate:7f6336d9b24b4d36e0c8e622fd79e141 1 udp 1694498815 79.20.79.217 52697 typ srflx raddr 192.168.178.30 rport 52697\r\na=end-of-candidates\r\na=ice-ufrag:6Uh1\r\na=ice-pwd:cLKAgmaZAA5i1Tw7BHJkLD\r\na=fingerprint:sha-256 18:34:6E:4B:DC:6E:3D:00:49:28:24:AB:F5:CB:7F:FC:3E:4A:AD:A7:DE:D9:29:6D:5A:7C:A3:0F:76:C8:BD:E4\r\na=setup:actpass\r\n"
}
}'
and I'm always receiving a generic error:
{
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT"
}
}
Does anyone have any idea what i'm doing wrong?
Solution
The fact is that I was missing the data channel (myPeerConnection.createDataChannel("dataSendChannel");) and the correct createOffer parameters ({offerToReceiveAudio:!0,offerToReceiveVideo:!0}).
The following code generates a correct SDP offer which is accepted by Google.
const myPeerConnection = new RTCPeerConnection
myPeerConnection.createDataChannel("dataSendChannel");
myPeerConnection.createOffer({offerToReceiveAudio:!0,offerToReceiveVideo:!0}).then(function(offer) {
return myPeerConnection.setLocalDescription(offer);
})
.then(function() {
console.log(myPeerConnection.localDescription.sdp + "\n");
})
.catch(function(reason) {
console.log("An error occurred, so handle the failure to connect");
});
Also pay attention: if you don't send the newline character in the end of the offer string, you will get the following error:
{
"error": {
"code": 500,
"message": "Internal error encountered.",
"status": "INTERNAL"
}
}
WEBRTC - while setting answer into setLocalDescription getting below error in firefox beta version .63
this.soc.setLocalDescription(answer, function(){}, function(error){ co.handleAnswerLoacalDescError(error); } );
SWRTCAnswerPConn.prototype.handleAnswerLoacalDescError = function (error) {
console.log("error SWRTCAnswerPConn.prototype.handleAnswerLoacalDescError "+error);
}
Below one is the local sdp
"v=0\r\no=mozilla...THIS_IS_SDPARTA-63.0 6779639364423913043 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\n
a=ice-options:trickle\r\n
a=msid-semantic:WMS *\r\nm=audio 9 RTP/SAVPF 0\r\nc=IN IP4 0.0.0.0\r\n
a=sendrecv\r\n
a=ice-pwd:0c25b6011567fa002a87fw6d36d0c32e\r\n
a=ice-ufrag:9cba9881\r\n
a=msid:{342671bf-c92f-4d7e-add6-37228fcaffc4} {6876af26-691b-4beb-9fed-a18e27ea0fe0}\r\n
a=rtcp-mux\r\n
a=rtpmap:0 PCMU/8000\r\n
a=setup:active\r\n
a=ssrc:127692948 cname:{f7d3d74d-86e0-4a27-a143-79f4703d32cf}\r\n"
*
InvalidSessionDescriptionError: Local descriptions must have a=mid attributes
*
Please, anyone, help to resolve this issue.
Webrtc SDP Audio is not working on sender side but receiver can listen sender voice.
Video is working fine both side
Answer SDP:-
v=0\r\no=mozilla...THIS_IS_SDPARTA-61.0 6227063584330165543 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=sendrecv\r\na=fingerprint:sha-256 5B:EE:F9:8B:A4:77:24:AF:C8:1F:7A:12:75:1C:4B:6F:33:45:D9:3B:BB:05:F5:18:03:32:9D:2D:AB:BC:FC:01\r\na=group:BUNDLE sdparta_0 sdparta_1\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=audio 9 UDP/TLS/RTP/SAVPF 109 101\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1\r\na=fmtp:101 0-15\r\na=ice-pwd:4c2cb9a31321054e816200974f041439\r\na=ice-ufrag:408ddefb\r\na=mid:sdparta_0\r\na=msid:{d83c16a6-8c6b-48a6-9df5-a0e26ca801f7} {f1388817-3547-4e77-aca1-da974eaa0dd3}\r\na=rtcp-mux\r\na=rtpmap:109 opus/48000/2\r\na=rtpmap:101 telephone-event/8000\r\na=setup:active\r\na=ssrc:711252568 cname:{83856f3b-3e35-4fff-8bd1-5c3a0a0b0cce}\r\nm=video 9 UDP/TLS/RTP/SAVPF 120\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:5 urn:ietf:params:rtp-hdrext:toffset\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=ice-pwd:4c2cb9a31321054e816200974f041439\r\na=ice-ufrag:408ddefb\r\na=mid:sdparta_1\r\na=msid:{d83c16a6-8c6b-48a6-9df5-a0e26ca801f7} {37ab4190-689d-4607-b031-5855790d6c10}\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:120 goog-remb\r\na=rtcp-mux\r\na=rtpmap:120 VP8/90000\r\na=setup:active\r\na=ssrc:984964499 cname:{83856f3b-3e35-4fff-8bd1-5c3a0a0b0cce}\r\n
I'm using WebRtcPeerSendrecv object to build a communication with WebRTC endpoint with kurento server. I want to select a video input as it is made here: https://webrtc.github.io/samples/src/content/devices/input-output/
The problem I have is that adding a property video/deviceId is not working.
options = {
audio : false,
localVideo : videoInput,
remoteVideo : videoOutput,
video: {
deviceId: {exact: devcs[0]}
},
onicecandidate : onIceCandidate,
onerror : onError
}
The only thing which is made in other way, is that I'm building my WebRtc connection with WebRtcPeerSendrecv from Kurento-utils, and originally it is made with using navigator.getUserMedia(...).
As far as I know, WebRtcPeerSendrecv is calling getUserMedia, but I'm not sure that all properties are copied one to one. I took a look here for source code of https://github.com/Kurento/kurento-utils-js/blob/master/lib/WebRtcPeer.js but I'm not sure of it. Have anyone faced with a simmilar problem?
Edit:
There is wider sourcecode which is containing a webRTCPeer creation (with tetsting another options):
var options;
console.log(devcs);
if(devcs.length == 2){
console.log("CAMERA ID SET");
options = {
audio : false,
localVideo : videoInput,
remoteVideo : videoOutput,
video: {
optional: [{sourceId: devcs[0]}]
//deviceId: {exact: devcs[0]}
},
onicecandidate : onIceCandidate,
onerror : onError
}
}
else{
console.log("THERE ARE NO 2 CAMERAS");
options = {
audio : false,
localVideo : videoInput,
remoteVideo : videoOutput,
onicecandidate : onIceCandidate,
onerror : onError
}
}
webRtcPeer = new kurentoUtils.WebRtcPeer.WebRtcPeerSendrecv(options,
function(error) {
if (error) {
return console.error(error);
}
webRtcPeer.generateOffer(onOfferIncomingCall);
});
I have tried with both options with both IDs which I'm getting in a devcs array, and both are not working- I have always a front camera. As I checked, the devcs contains IDs. There is way in which I obtain them.
There are some log, but not too much (log from android- I'm building it in WebView (chromium)):
12-21 12:21:39.985 25173-25173/eu.kros.t_medapp I/chromium:
[INFO:CONSOLE(70)] "Received message:
{"id":"incomingCall","from":"Qwe"}", source:
https://192.168.137.1:8443/tmedserver/resources/demo-console/js/index.js
(70) 12-21 12:21:42.374 25173-25173/eu.kros.t_medapp I/chromium:
[INFO:CONSOLE(70)]
"1a8c3f3af9469f0c9e89adf8324f03cc9300abee4a283499cfc0bc5161d0bd7b,8fb6f256ea855f26c5d3f6c02048a83472839e33f9b36f0f5af03750f0ea0693",
source:
https://192.168.137.1:8443/tmedserver/resources/demo-console/js/index.js
(70) 12-21 12:21:42.376 25173-25173/eu.kros.t_medapp I/chromium:
[INFO:CONSOLE(70)] "CAMERA ID SET", source:
https://192.168.137.1:8443/tmedserver/resources/demo-console/js/index.js
(70) 12-21 12:21:42.580 25173-25173/eu.kros.t_medapp I/chromium:
[INFO:CONSOLE(274)] "constraints:
{"mandatory":{"OfferToReceiveAudio":true,"OfferToReceiveVideo":true},"optional":[{"DtlsSrtpKeyAgreement":true}]}",
source:
https://192.168.137.1:8443/tmedserver/resources/kurento-utils/kurento-utils.js (274) 12-21 12:21:42.582 25173-25460/eu.kros.t_medapp W/chromium:
[WARNING:mediasession.cc(350)] Duplicate id found. Reassigning from
101 to 127 12-21 12:21:42.674 25173-25461/eu.kros.t_medapp E/chromium:
[ERROR:voe_audio_processing_impl.cc(774)] SetTypingDetectionStatus:
not supported 12-21 12:21:42.675 25173-25461/eu.kros.t_medapp
W/chromium: [WARNING:webrtcvoiceengine.cc(820)]
SetTypingDetectionStatus(0) failed, err=8003 12-21 12:21:42.683
25173-25461/eu.kros.t_medapp E/chromium:
[ERROR:voe_audio_processing_impl.cc(774)] SetTypingDetectionStatus:
not supported 12-21 12:21:42.684 25173-25461/eu.kros.t_medapp
W/chromium: [WARNING:webrtcvoiceengine.cc(820)]
SetTypingDetectionStatus(0) failed, err=8003 12-21 12:21:42.697
25173-25173/eu.kros.t_medapp I/chromium: [INFO:CONSOLE(276)] "Created
SDP offer", source:
https://192.168.137.1:8443/tmedserver/resources/kurento-utils/kurento-utils.js (276) 12-21 12:21:42.737 25173-25173/eu.kros.t_medapp I/chromium:
[INFO:CONSOLE(281)] "Local description set", source:
https://192.168.137.1:8443/tmedserver/resources/kurento-utils/kurento-utils.js (281) 12-21 12:21:42.742 25173-25173/eu.kros.t_medapp I/chromium:
[INFO:CONSOLE(70)] "Senging message:
{"id":"incomingCallResponse","from":"Qwe","callResponse":"accept","sdpOffer":"v=0\r\no=-
5220787002804162488 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0
0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS
3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx\r\nm=audio 9 UDP/TLS/RTP/SAVPF
111 103 9 0 8 105 13 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4
0.0.0.0\r\na=ice-ufrag:wXPX\r\na=ice-pwd:VXRwTn0RLvzpFqC3uk58oanh\r\na=fingerprint:sha-256
FC:85:C8:8A:29:71:CB:7D:DE:02:EE:47:1A:5A:0B:E2:EE:FD:58:5B:2D:F1:65:A6:DC:2B:34:5E:E7:25:5A:12\r\na=setup:actpass\r\na=mid:audio\r\na=extmap:1
urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3
http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111
opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111
minptime=10;useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:9
G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8
PCMA/8000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13
CN/8000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:854056653
cname:0AmhreG6mVDgfHOl\r\na=ssrc:854056653
msid:3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx
71667887-1f6b-475d-8c80-4fbd58f5ce3c\r\na=ssrc:854056653
mslabel:3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx\r\na=ssrc:854056653
label:71667887-1f6b-475d-8c80-4fbd58f5ce3c\r\nm=video 9
UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98\r\nc=IN IP4
0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:wXPX\r\na=ice-pwd:VXRwTn0RLvzpFqC3uk58oanh\r\na=fingerprint:sha-256
FC:85:C8:8A:29:71:CB:7D:DE:02:EE:47:1A:5A:0B:E2:EE:FD:58:5B:2D:F1:65:A6:DC:2B:34:5E:E7:25:5A:12\r\na=setup:actpass\r\na=mid:video\r\na=extmap:2
urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3
http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:4
urn:3gpp:video-orientation\r\na=extmap:5
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:6
http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=sendrecv\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:100
VP8/90000\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100
nack\r\na=rtcp-fb:100 nack pli\r\na=rtcp-fb:100
goog-remb\r\na=rtcp-fb:100 transport-cc\r\na=rtpmap:101
VP9/90000\r\na=rtcp-fb:101 ccm fir\r\na=rtcp-fb:101
nack\r\na=rtcp-fb:101 nack pli\r\na=rtcp-fb:101
goog-remb\r\na=rtcp-fb:101 transport-cc\r\na=rtpmap:116
red/90000\r\na=rtpmap:117 ulpfec/90000\r\na=rtpmap:96
rtx/90000\r\na=fmtp:96 apt=100\r\na=rtpmap:97 rtx/90000\r\na=fmtp:97
apt=101\r\na=rtpmap:98 rtx/90000\r\na=fmtp:98
apt=116\r\na=ssrc-group:FID 2811430131 2273108000\r\na=ssrc:2811430131
cname:0AmhreG6mVDgfHOl\r\na=ssrc:2811430131
msid:3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx
d9810401-c8be-4f49-9453-35646b1842d0\r\na=ssrc:2811430131
mslabel:3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx\r\na=ssrc:2811430131
label:d9810401-c8be-4f49-9453-35646b1842d0\r\na=ssrc:2273108000
cname:0AmhreG6mVDgfHOl\r\na=ssrc:2273108000
msid:3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx
d9810401-c8be-4f49-9453-35646b1842d0\r\na=ssrc:2273108000
mslabel:3Rq4qyKWshfM1wF6rXu3OZ0sNxq7Fus0qJUx\r\na=ssrc:2273108000
label:d9810401-c8be-4f49-9453-35646b1842d0\r\n"}", source:
https://192.168.137.1:8443/tmedserver/resources/demo-console/js/index.js
(70)
The solution is not connected with kurento client.
Video properties must be added through a mediaConstraint option:
var constraints = {
audio:true,
video:{
deviceId: {exact: devcs[1]}
}
};
options = {
audio : false,
localVideo : videoInput,
remoteVideo : videoOutput,
mediaConstraints:constraints,
onicecandidate : onIceCandidate,
onerror : onError
}
The other problem which I'm facing right now is that camera is working well with only one video id : with devcs[0]. Whith second camera (devcs[1]) there is black video element and error in logs:
12-21 13:09:12.562 9704-9757/eu.kros.t_medapp W/CameraBase: An error
occurred while connecting to camera: 0
12-21 13:09:12.5629704-9757/eu.kros.t_medapp E/cr_VideoCapture: allocate: Camera.open:
java.lang.RuntimeException: Fail to connect to camera service
12-21 13:09:12.568 9704-9757/eu.kros.t_medapp E/cr_VideoCapture:
stopCapture: mCamera is null
When I will solve it I will update this post.
I've been googling a way to change codec in Chrome's implementation of WebRTC, but there doesn't seem to be a way.
How can I change the default codec used(audio or video) in a WebRTCpeer connection in Chrome?
Yes, you can change the codec to be anything you want...as long as Chrome supports it. Right now, audio wise, the only supported codecs are PCMA, PCMU, ISAC, and OPUS(the default). For Video you have VP8(also H264 on some systems with FireFox).
To use any of these codecs as default, you must modify your SDP before setting it locally in your peerconnection and sending your offer/answer. I have tested successfully forcing Chrome to send PCMA instead of OPUS by default.
As an example:
Say you have your default audio SDP section that looks like the following(notes are in brackets are are not part of the sdp)
m=audio<media> 49353<port> RTP/SAVPF<proto> 111 103 104 0 8 106 105 13 126 <rtpformats>
c=IN<nettype> IP4<addrtype> 192.168.0.13<address>
a=rtcp:49353<port> IN<nettype> IP4<addresstype> privateIP<connection address>
a=candidate:1204296370 1 udp 2122260223 privateIP 49353 typ host generation 0 <audioIceCandidate>
a=candidate:1204296370 2 udp 2122260223 privateIP 49353 typ host generation 0
a=candidate:155969090 1 tcp 1518280447 privateIP 0 typ host generation 0
a=candidate:155969090 2 tcp 1518280447 privateIP 0 typ host generation 0
a=ice-ufrag:E7VFzFythTIOaQ6X <ice username>
a=ice-pwd:ZMHFqqXEA8JLjItZcRN4FZDJ <ice-password>
a=ice-options:google-ice <iceoptions>
a=fingerprint:sha-256<encryptType> 66:2D:43:3A:31:7B:46:56:50:D7:CC:75:80:79:5D:88:7D:5D:1B:0E:C7:E6:F9:C4:68:6D:51:7F:4B:32:97:A1<print>
a=setup:actpass <dtls setup mode>
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level <extention map>
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv <mediamode>
a=rtcp-mux <says rtcp mux>
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
If you wanted to ONLY use PCMA, you would change the m=audio line to the following:
m=audio 49353 RTP/SAVPF 8 this way only the PCMA payload is considered. Then you need to remove all the rtpmap lines that do not correspond with that payload, i.e. any a=rtpmap: where the next character is NOT an 8. If you set that modified sdp locally and send it to your peer(and if they SUPPORT PCMA...does not have to be default for them as the negotiation will force PCMA if you only offer it), then PCMA will be your audio codec and not OPUS.
Couple of asides:
The SDP I am talking about is the one generated and passed through the success callback of the createOffer and createAnswer functions of the peerconnection
This type of idea will work for ADDING codecs that you know are supported by the underlaying systems(H264, SPEEX, etc.). Just make sure to add the payload and the appropriate mappings and options(fmtp is needed for h264 as profiles are important and possibly sprop-parameter-sets).
This will work with any appropriately coded WebRTC system, i.e. Firefox, Opera, etc. Not just chrome.
As browsers start to support setCodecPreferences, you can check for the mimetype of the codec you want to use by default to set the codec preference. For example if you want to prefer opus for audio you can check for the "audio/opus" mimetype and set your codec preferences to opus codecs:
let tcvr = pc.getTransceivers()[0];
let codecs = RTCRtpReceiver.getCapabilities('audio').codecs;
let opus_codecs = [];
// iterate over supported codecs and pull out the codecs we want
for(let i = 0; i < codecs.length; i++)
{
if(codecs[i].mimeType == "audio/opus")
{
opus_codecs .push(codecs[i]);
}
}
// currently not all browsers support setCodecPreferences
if(tcvr.setCodecPreferences != undefined)
{
tcvr.setCodecPreferences(opus_codecs);
}
Or for video you can fix the codec to vp9:
// note the following should be called before before calling either RTCPeerConnection.createOffer() or createAnswer()
let tcvr = pc.getTransceivers()[0];
let codecs = RTCRtpReceiver.getCapabilities('video').codecs;
let vp9_codecs = [];
// iterate over supported codecs and pull out the codecs we want
for(let i = 0; i < codecs.length; i++)
{
if(codecs[i].mimeType == "video/VP9")
{
vp9_codecs.push(codecs[i]);
}
}
// currently not all browsers support setCodecPreferences
if(tcvr.setCodecPreferences != undefined)
{
tcvr.setCodecPreferences(vp9_codecs);
}
Code adapted from this Pericror blog post to force audio/video codecs.