Hello,
Version: Asterisk 19.1.0
Goal: Enable Asterisk bundle configuration in order to utilize SFU for conference video calls.
I am not using WebRTC “https” connection, rather I configured a ps_endoint(s) with WebRTC compatible settings.
This is done so I can utilize a WebBrowser and an Android App with same account. Note: I have a SIP Proxy which converts WebRTC “https” connection to a standard TLS SIP Connection prior to routing to Asterisk.
ps_endpoint:
media_encryption => dtls
max_audio_streams => 10
max_video_streams => 10
extension:
[music]
exten => 1000,1,NoOp(1)
exten => 1000,n,Answer()
exten => 1000,n,StreamEcho(4)
Audio works well, I hear echo in the audio stream.
However, when I change my endpoint configuration to set bundle => true, I get audio demultiplex issues with Linphone.
Investigating this, I see Linphone sends “a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid” within the INVITE payload.
Looking into Asterisk code, the server utilizes extmap:“docs/native-code/rtp-hdrext/abs-send-time - src - Git at Google” and “http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01”.
When debugging the issue, I see the server drops Linphone’s extmap. Also, I see in logs, the server sends: “a=group:BUNDLE as”.
In same environment setting, I tested using SIPML5 WebRTC Browser Application and I am able to successfully receive audio. SIPML5 sends the following extmap:
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 docs/native-code/rtp-hdrext/abs-send-time - src - Git at Google
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
Per Linphone Team:
From my understanding, Asterisk is not compliant with RFC8285 because it is not setting the urn:ietf:params:rtp-hdrext:sdes:mid extension header numbering in its SDP answer.
For that reason, Linphone does not know what is the RTP extension header number for the “mid” information, and hence is not able to demultiplex RTP streams in the bundle.
See RFC 8285 - A General Mechanism for RTP Header Extensions
Also, Bundle mode RFC gives an example of a SDP answer, where a=extmap attribute appears as expected:
Is being non-compliant with the RFCs accurate? If so, are there plans in to be RFC Compliant?
SIP Logs:
INVITE sip:1000@domain.com SIP/2.0
Via: SIP/2.0/TCP domain.com:PORT;branch=z9hG4bK21a5.b55a00d5.0;i=2a69f401
From: “DISPLAY_NAME” sip:USER_NAME@domain.com;tag=8jXstI-sU
To: “1000” sip:1000@domain.com
CSeq: 21 INVITE
Call-ID: DLGCH_OkQrXgcCNjl6IA–
Max-Forwards: 69
Supported: replaces, outbound, gruu, path
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 1052
Contact: sip:USER_NAME@domain.com:PORT;transport=tcp;did=395.c67a7875
User-Agent: Android
v=0
o=USER_NAME 3838 3799 IN IP4 192.168.0.37
s=Talk
c=IN IP4 HHH.HHH.HHH.HHH
t=0 0
a=ice-pwd:f2ba8b9ba193ea2ce23dd3a5
a=ice-ufrag:7bcf887d
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
a=group:BUNDLE as
m=audio 47026 UDP/TLS/RTP/SAVPF 96 97 101 98
c=IN IP4 HHH.HHH.HHH.HHH
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 speex/8000
a=fmtp:97 vbr=on
a=rtpmap:101 telephone-event/48000
a=rtpmap:98 telephone-event/8000
a=setup:actpass
a=fingerprint:SHA-256 31:C4:82:7C:4D:8D:6E:49:1F:6F:08:F1:1E:15:E0:6D:70:F7:DE:9E:8A:22:84:25:53:CC:74:7E:15:C3:05:9E
a=rtcp-mux
a=mid:as
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 2130706303 192.168.0.37 47026 typ host
a=candidate:1 2 UDP 2130706302 192.168.0.37 47027 typ host
a=candidate:2 1 UDP 1694498687 HHH.HHH.HHH.HHH 47026 typ srflx raddr 192.168.0.37 rport 47026
a=candidate:2 2 UDP 1694498686 HHH.HHH.HHH.HHH 47027 typ srflx raddr 192.168.0.37 rport 47027
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* ccm tmmbr
<— Transmitting SIP response (1476 bytes) to TCP:ZZZ.ZZZ.ZZZ.ZZZ:55499 —>
SIP/2.0 200 OK
Via: SIP/2.0/TCP domain.com:PORT;rport=55499;received=ZZZ.ZZZ.ZZZ.ZZZ;branch=z9hG4bK21a5.b55a00d5.0;i=2a69f401
Call-ID: DLGCH_OkQrXgcCNjl6IA–
From: “DISPLAY_NAME” sip:USER_NAME@domain.com;tag=8jXstI-sU
To: “1000” sip:1000@domain.com;tag=a7a8807e-63c6-46e3-83e2-15bbbf9b4317
CSeq: 21 INVITE
Server: PBX
Contact: sip:YYY.YYY.YYY.YYY:PORT;transport=TCP
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 808
v=0
o=PBX 3838 3801 IN IP4 XXX.XXX.XXX.XXX
s=SIP Call
c=IN IP4 XXX.XXX.XXX.XXX
t=0 0
a=group:BUNDLE as
m=audio 10942 UDP/TLS/RTP/SAVPF 96 97 98
a=connection:new
a=setup:active
a=fingerprint:SHA-256 2A:16:33:22:33:5A:5D:97:78:E0:F1:71:B6:C0:F6:D6:BE:F4:61:09:32:07:32:EE:6F:46:89:45:FC:9B:BB:FD
a=ice-ufrag:117738e82fea451d2384b5b104aaf606
a=ice-pwd:174e450a196e39615c9129747d76f55e
a=candidate:Ha000a1e 1 UDP 2130706431 YYY.YYY.YYY.YYY 10942 typ host
a=candidate:Sd429c46 1 UDP 1694498815 XXX.XXX.XXX.XXX 10942 typ srflx raddr YYY.YYY.YYY.YYY rport 10942
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 speex/8000
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:299971184 cname:30edb432-3937-41b5-8242-7fd280d7c3e3
a=mid:as
<— Received SIP request (726 bytes) from TCP:ZZZ.ZZZ.ZZZ.ZZZ:55499 —>
ACK sip:YYY.YYY.YYY.YYY:PORT;transport=TCP SIP/2.0
Via: SIP/2.0/TCP domain.com:PORT;branch=z9hG4bK21a5.b55a00d5.2;i=3a69f401
From: “DISPLAY_NAME” sip:USER_NAME@domain.com;tag=8jXstI-sU
To: “1000” sip:1000@domain.com;tag=a7a8807e-63c6-46e3-83e2-15bbbf9b4317
CSeq: 21 ACK
Call-ID: DLGCH_OkQrXgcCNjl6IA–
Max-Forwards: 69
Proxy-Authorization: Digest realm=“domain.com”, nonce=“iaGqQq92rq/IwjEJa78cYFAcnojrNLH0JrD7p3FKABMA”, username=“USER_NAME”, uri="sip:1000@domain.com", response=“063d3c5f1e6323734ece6100f2a0ae91”
User-Agent: Android
Content-Length: 0
<— Received SIP request (782 bytes) from TCP:ZZZ.ZZZ.ZZZ.ZZZ:55499 —>
BYE sip:YYY.YYY.YYY.YYY:PORT;transport=TCP SIP/2.0
Via: SIP/2.0/TCP domain.com:PORT;branch=z9hG4bKf0a5.00e89371.0;i=3a69f401
From: “DISPLAY_NAME” sip:USER_NAME@domain.com;tag=8jXstI-sU
To: “1000” sip:1000@domain.com;tag=a7a8807e-63c6-46e3-83e2-15bbbf9b4317
CSeq: 22 BYE
Call-ID: DLGCH_OkQrXgcCNjl6IA–
Max-Forwards: 69
User-Agent: Android
Proxy-Authorization: Digest realm=“domain.com”, nonce=“iaGqQq92rq/IwjEJa78cYFAcnojrNLH0JrD7p3FKABMA”, username=“USER_NAME”, uri=“sip:domain.com:5061;transport=tls;did=395.c67a7875”, response=“9b8d04935eeae8b9bb46af77f259eb92”
Content-Length: 0
<— Transmitting SIP response (427 bytes) to TCP:ZZZ.ZZZ.ZZZ.ZZZ:55499 —>
SIP/2.0 200 OK
Via: SIP/2.0/TCP domain.com:PORT;rport=55499;received=ZZZ.ZZZ.ZZZ.ZZZ;branch=z9hG4bKf0a5.00e89371.0;i=3a69f401
Call-ID: DLGCH_OkQrXgcCNjl6IA–
From: “DISPLAY_NAME” sip:USER_NAME@domain.com;tag=8jXstI-sU
To: “1000” sip:1000@domain.com;tag=a7a8807e-63c6-46e3-83e2-15bbbf9b4317
CSeq: 22 BYE
Server: PBX
Content-Length: 0
Thanks,
Carlos