WebRTC SIP Call: init audio call and receive both audio and video

[Javier Delgado]

I'm working on a web app which uses SIP video calls. To support these calls over WebRTC I'm using Asterisk 19.3 as a SIP server with WebRTC support and [SIPML5][1] as a Javacsript SIP client.

With my current set up I can perform bidirectional audio calls, and bidirectional videocalls perfectly. However, one the use cases I need to solve is when the user calling doesn't have a video input (i.e., a webcam) and therefore the can only send audio.
In that case, I would like the user to send audio but receive both audio and video.

SIPML5 offers two ways of starting a call: one called 'call-audio' and one 'call-audiovideo', which are self-explanatory. The problem is that a user with no webcam can't use 'call-audiovideo'; and a 'call-audio' call doesn't receive video, at least when first starting.

If a 'call-audio' is made and the called SIP agent enables the video (once in the call) the caller can reveive the video too, but that is not the behaviour I'm looking for.
After speding some time trying to figure this out I have arrived at the following conclussions:
- The initial state of the call, which does not include video, is due to the caller not having a video source and therefore not including a way to receive video on its SDP offer message.
- When the called SIP agent enables video, SDP is re-negotiated, and therefore video is included.

To solve this, I have found that the WebRTC [createOffer][2] method can be used to specify offerToReceiveVideo. In fact, I have checked that offerToReceiveVideo is enabled when a 'call-audiovideo' is performed with SIPML5.
I have modified the library by forcing 'offerToReceiveVideo' to be always true by changing [this line][3]

Using some console logs I can check that now, when making an audio call, both parameters are set to true, but no video is received. In fact, when checking the SDP messages, there is no video included.

The SDP offer (with no video):
```
SEND: INVITE sip:axis_...@192.168.0.32 SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKehxIP2HcdwRfgArEuaG1rBBFTTW9StqV;rport
From: <sip:web_c...@192.168.0.32>;tag=RXVwDUfwQzpnku05c3C4
To: <sip:axis_...@192.168.0.32>
Contact: <sip:web_c...@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr"
Call-ID: dc7e97a0-18a7-5647-c89b-1f65e89e2122
CSeq: 12883 INVITE
Content-Type: application/sdp
Content-Length: 1756
Max-Forwards: 70
Authorization: Digest username="web_client",realm="asterisk",nonce="1657553424/0f867d3a89fd9fa02efa9b2f5e534b39",uri="sip:axis_...@192.168.0.32",response="147b75ccbd4688c58e4f97223de0c124",algorithm=md5,cnonce="70e42a1664647ece843cbf237bd3e085",opaque="3ab6606978aa2d79",qop=auth,nc=00000001
User-Agent: IM-client/OMA1.0 sipML5-v1.2016.03.04
Organization: Doubango Telecom

v=0
o=- 7126635236133347000 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS XDSp9VxyuQEwDsFloVsFABsryNJhnLGSbR7q
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 127.0.0.1
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:4285824471 1 udp 2113937151 8aa45d1b-d584-4e2e-8d65-a947ca92b151.local 35327 typ host generation 0 network-cost 999
a=ice-ufrag:wDtb
a=ice-pwd:dK2N4RD1gPRbSL97RgEb1AFj
a=ice-options:trickle
a=fingerprint:sha-256 8C:C7:86:42:1E:0C:AA:26:4A:69:EF:7B:85:B5:66:D5:BF:4D:F4:47:EF:BB:2E:1D:91:8E:71:09:B9:08:F1:48
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:XDSp9VxyuQEwDsFloVsFABsryNJhnLGSbR7q 6b74201e-d5f7-4e77-8403-c9088a7b7e4e
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
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:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:2091861979 cname:am0/193LU7s+OyI2
a=ssrc:2091861979 msid:XDSp9VxyuQEwDsFloVsFABsryNJhnLGSbR7q 6b74201e-d5f7-4e77-8403-c9088a7b7e4e
a=ssrc:2091861979 mslabel:XDSp9VxyuQEwDsFloVsFABsryNJhnLGSbR7q
a=ssrc:2091861979 label:6b74201e-d5f7-4e77-8403-c9088a7b7e4e
```

The SDP answer:
```
recv=SIP/2.0 200 OK
Via: SIP/2.0/WS df7jal23ls0d.invalid;rport=40662;received=192.168.0.12;branch=z9hG4bKehxIP2HcdwRfgArEuaG1rBBFTTW9StqV
From: <sip:web_c...@192.168.0.32>;tag=RXVwDUfwQzpnku05c3C4
To: <sip:axis_...@192.168.0.32>;tag=17f6bba9-1687-41fc-b492-d7d6fe318d64
Contact: <sip:192.168.0.32:8088;transport=ws>
Call-ID: dc7e97a0-18a7-5647-c89b-1f65e89e2122
CSeq: 12883 INVITE
Content-Type: application/sdp
Content-Length: 940
Server: Asterisk PBX 19.3.0
Allow: OPTIONS,REGISTER,SUBSCRIBE,NOTIFY,PUBLISH,INVITE,ACK,BYE,CANCEL,UPDATE,PRACK,REFER,MESSAGE
Supported: 100rel,timer,replaces,norefersub

v=0
o=- 495099576 4 IN IP4 192.168.0.32
s=Asterisk
c=IN IP4 192.168.0.32
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0
m=audio 16936 UDP/TLS/RTP/SAVPF 111 0 8 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 BE:40:02:D5:24:F3:BF:4A:AA:76:27:C0:03:6F:EF:4C:53:20:0B:8B:FE:D2:03:96:84:55:7D:D3:13:88:25:36
a=ice-ufrag:7a249bf27f4f4683088dc5b102c92458
a=ice-pwd:2971645d61d7f05b66059d3e2e1e2112
a=candidate:Hc0a80020 1 UDP 2130706431 192.168.0.32 16936 typ host
a=candidate:H68935337 1 UDP 2130706431 fe80::a00:27ff:fed8:9e35 16936 typ host
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:268598391 cname:3b3c206b-6255-42c1-b2d9-b8402fa739f6
a=msid:f4d7f441-e7bb-40d4-a37a-6331ab3d916c bd31165f-ab74-46a4-b2c6-7832ddd490a1
a=rtcp-fb:* transport-cc
a=mid:0
```

There is also one more thing that I can't manage to understand: On chrome this works as an audio call, and it gives no errors. However, on Opera, when a 'call-audio' is performed with `'offerToReceiveVideo': true`, I get the following exception, although the SDP message is the one shown previously. There is just one media and one m-entry on each SDP message, how can the order not match?
```
tsk_utils.js?svn=252:128 DOMException: Failed to set remote answer sdp: The order of m-lines in answer doesn't match order in offer. Rejecting answer.
tsk_utils_log_error @ tsk_utils.js?svn=252:128
tmedia_session_jsep01.onSetRemoteDescriptionError @ tmedia_session_jsep.js?svn=252:547
(anonymous) @ tmedia_session_jsep.js?svn=252:730

```
If a videocall is performed, it doens't give this error and it works as usual.

Obviously there is something I have misunderstood about the 'offerToReceiveVideo' option, or something more I have to modify to implement the desired behaviour, but I have spent several hours trying to figure it out and I haven't find something.
Are my assumptions right? Does somebody know what could be happening?

Thanks a lot!


  [1]: https://www.doubango.org/sipml5/
  [2]: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createOffer
  [3]: https://github.com/DoubangoTelecom/sipml5/blob/66811b166b3351f06a91893a21ae76a92b45f0cd/src/tinyMEDIA/src/tmedia_session_jsep.js#L414