Android-based Video Call on the SRS Server (1) : ENABLE HTTPS on the SRS server (2) : The Android terminal pulls WebRTC streams from the SRS server To implement Android-based Web video calls based on the SRS server (3) : The Android terminal pushes WebRTC streams to the SRS server

Installation environment: Linux Version 5.8.0-63-generic (buildd@lgw01-amd64-035) (GCC (Ubuntu 9.3.0-17Ubuntu1 20.04) 9.3.0, GNU LD (GNU Binutils for Ubuntu) 2.34) #71 20.04.1-Ubuntu SMP Thu Jul 15 17:46:08 UTC 2021

Source, if github access speed is too slow, you can go to the mirror address. Downloading files is not explained.

Note: If you want to use WebRTC, you need to use SRS version 4.0.

The official document, it’s full. The Web page needs to use HTTPS or localhost to invoke the camera and microphone. Therefore, HTTPS is required to enable the communication between Android and Web. SRS supports HTTP and HTTPS traffic exchange. You can request HTTP from the Android terminal (if HTTPS is used and there is no valid certificate, you can ignore the certificate request) and HTTPS from the Web terminal.

After compiling, take a look at the conf directory, which is used to start the configuration file used by the service.

root@ubuntu:/home/shencoder/srs/trunk/conf# ls bandwidth.conf exec.conf http.hls.conf push.flv.conf clion.conf ffmpeg.transcode.conf http.hooks.callback.conf push.mpegts.over.udp.conf clion-ingest.conf forward.master.conf http.mp3.live.conf push.rtsp.conf compatible.conf forward.slave.conf http.server.conf realtime.conf console.conf full.conf https.flv.live.conf regression-test.conf dash.conf go-oryx-edge2.conf https.hls.conf rtc2rtmp.conf demo.19350.conf go-oryx-edge.conf https.hooks.callback.conf rtc.conf demo.conf hds.conf https.rtc.conf rtmp.conf docker.conf hls.conf http.ts.live.conf security.deny.publish.conf dvr.mp4.conf hls.realtime.conf ingest.conf server.crt dvr.path.conf http.aac.live.conf ingest.rtsp.conf server.key dvr.segment.conf http.api.raw.conf origin.cluster.edge.conf  srs.conf dvr.session.conf http.flv.live.conf origin.cluster.serverA.conf srt2rtc.conf edge2.conf http.flv.live.edge1.conf origin.cluster.serverB.conf srt.conf edge.conf http.flv.live.edge2.conf origin.cluster.serverC.conf transcode2hls.audio.only.conf edge.token.traverse.conf http.heartbeat.conf origin.conf transform.edge.confCopy the code

Conf: related to videos HTTPS. Xxx. conf: related to HTTPS rtcxxx.conf: Related to WebRTC

We can also customize configuration files to suit our needs.

For example, if we want to satisfy an HTTPS, WebRTC, RTMP, video recording function, something like this (https.rtc2rtmp.dvr.

listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_server { enabled on; listen 8080; dir ./objs/nginx/html; https { enabled on; listen 8088; key ./conf/server.key; cert ./conf/server.crt; } } http_api { enabled on; listen 1985; https { enabled on; listen 1990; key ./conf/server.key; cert ./conf/server.crt; } } stats { network 0; } rtc_server { enabled on; # Listen at udp://8000 listen 8000; # # The $CANDIDATE means fetch from env, if not configed, use * as default. # # The * means retrieving server IP automatically, from all network interfaces, # @see https://github.com/ossrs/srs/wiki/v4_CN_RTCWiki#config-candidate candidate $CANDIDATE; } vhost __defaultVhost__ { rtc { enabled on; rtc_to_rtmp on; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } dvr { enabled on; dvr_path ./objs/nginx/html/[app]/[stream].[timestamp].flv; dvr_plan session; }}Copy the code

Note that HTTPS pages on the Web cannot invoke HTTP requests, and push and pull flows must be HTTPS addresses. Note the ports.

There is another operation, which is equivalent to forwarding, to see how it works.

One problem is that some Chrome browsers do not work properly with WebRTC. Also hope to know the old iron to tell the reason.