Problem setting WebRTC connection between GStreamer and FreeSwitch
daniel at poradnik-webmastera.com
daniel at poradnik-webmastera.com
Wed Mar 28 10:14:15 UTC 2018
W dniu 2018-03-28 10:27, Matthew Waters napisał(a):
> On 28/03/18 00:48, daniel at poradnik-webmastera.com wrote:
>> Hi,
>> I am trying to establish WebRTC connection between GStreamer and
>> FreeSwitch. FreeSwitch itself works - I am able to connect to it using
>> Blink VoIP client, and with WebRTC using Chrome+SIP.js.
>>
>> I started with
>> https://github.com/centricular/gstwebrtc-demos/blob/master/sendrecv/gst/webrtc-sendrecv.c
>> example, and modified it to talk with JS script running on node.js,
>> which uses SIP.js to communicate with FreeSwitch.
>>
>> My pipeline is simplified to use audio only, and no STUN:
>> pipe1 = gst_parse_launch("webrtcbin name=sendrecv "
>> "audiotestsrc wave=red-noise ! queue ! opusenc ! rtpopuspay !
>> "
>> "queue ! " RTP_CAPS_OPUS "97 ! sendrecv. ",
>> &error);
>>
>> This is SDP created by GST, with ICE candidates added:
>>
>> v=0
>> o=- 8118924877098511175 0 IN IP4 0.0.0.0
>> s=-
>> t=0 0
>> a=ice-options:trickle
>> m=audio 9 UDP/TLS/RTP/SAVPF 97
>> c=IN IP4 0.0.0.0
>> a=setup:actpass
>> a=ice-ufrag:uAfKhCDTPsXL7o0pB1K2AZ6sTtqbmFt+
>> a=ice-pwd:RD0/zeks78Ix5jmeb7qKuPA14tRd1GNG
>> a=sendrecv
>> a=rtcp-mux
>> a=rtcp-rsize
>> a=rtpmap:97 OPUS/48000/2
>> a=rtcp-fb:97 nack
>> a=rtcp-fb:97 nack pli
>> a=mid:audio0
>> a=fingerprint:sha-256
>> CA:3D:48:EC:90:39:83:2C:C4:99:4B:1E:16:0A:6E:B4:82:A4:F9:8D:2A:E5:61:0C:E2:22:AA:3A:25:53:64:A3
>> a=candidate:10 1 UDP 2013266428 192.168.100.20 38669 typ host
>> a=candidate:11 1 TCP 1015022591 192.168.100.20 9 typ host tcptype
>> active
>> a=candidate:12 1 TCP 1010828287 192.168.100.20 33547 typ host tcptype
>> passive
>> a=candidate:10 2 UDP 2013266427 192.168.100.20 42780 typ host
>> a=candidate:11 2 TCP 1015022590 192.168.100.20 9 typ host tcptype
>> active
>> a=candidate:12 2 TCP 1010828286 192.168.100.20 37994 typ host tcptype
>> passive
>> a=end-of-candidates
>>
>> FreeSwitch accepts it, and sends following one in reply:
>>
>> v=0
>> o=FreeSWITCH 1522134060 1522134061 IN IP4 192.168.100.20
>> s=FreeSWITCH
>> c=IN IP4 192.168.100.20
>> t=0 0
>> a=msid-semantic: WMS 2TtM3ayYJHI44bvP2idZ8jCOcfQVNm4G
>> m=audio 19410 UDP/TLS/RTP/SAVPF 97 101
>> a=rtpmap:97 OPUS/48000/2
>> a=fmtp:97 useinbandfec=1; minptime=10; maxptime=40
>> a=rtpmap:101 telephone-event/8000
>> a=ptime:20
>> a=fingerprint:sha-256
>> 95:66:C4:94:4B:DD:8B:BD:06:29:DD:0B:96:9C:C2:D2:57:81:B3:61:8A:D9:4E:42:36:17:BB:9D:E3:BF:A8:B7
>> a=setup:active
>> a=rtcp-mux
>> a=rtcp:19410 IN IP4 192.168.100.20
>
> This a=rtcp line is problematic if FreeSwitch is expecting RTCP packets
> to appear on port 19410. RTCP is transmitted through the ICE
> connection
> and thus is not generally signalled through the SDP.
The same IP and port for RTCP are implied by a=rtcp-mux line above, so
this line looks redundant for me. Or am I missing something?
>> a=ice-ufrag:lR5j1yY3DFPhRJNO
>> a=ice-pwd:WWDathYxuGwIKbOVTK5K9UDD
>> a=candidate:5323758004 1 udp 659136 192.168.100.20 19410 typ host
>> generation 0
>> a=end-of-candidates
>> a=ssrc:1792117166 cname:6niZnGNXemS9odOg
>> a=ssrc:1792117166 msid:2TtM3ayYJHI44bvP2idZ8jCOcfQVNm4G a0
>> a=ssrc:1792117166 mslabel:2TtM3ayYJHI44bvP2idZ8jCOcfQVNm4G
>> a=ssrc:1792117166 label:2TtM3ayYJHI44bvP2idZ8jCOcfQVNm4Ga0
>
> Does FreeSwitch require the msid/cname handling because that's
> currently
> not implemented by webrtcbin.
I do not know yet, I am checking this now.
>> I send it in set-remote-description as in example code, but GST is not
>> able to establish SRTP session. In Wireshark capture I see that
>> FreeSwitch sent few STUN Binding Requests (GST responded to them) and
>> RTCP packets with Receiver Report and Source description.
>>
>> GST debug logs are very verbose and it was hard for me to find some
>> useful info there. I tried to filter them a bit, and found following
>> entries there:
>>
>> 0:00:01.611202908 542 0x1b5b4a0 WARN structure
>> gststructure.c:1832:priv_gst_structure_append_to_gstring: No value
>> transform to serialize field 'srtp-key' of type 'buffer'
>>
>>
>> 0:00:05.670806044 542 0x1bd1190 DEBUG GST_SCHEDULING
>> gstpad.c:4277:gst_pad_chain_data_unchecked:<dtlssrtpdec0:sink> calling
>> chainfunction &gst_proxy_pad_chain_default with buffer buffer:
>> 0x7f6c10005040, pts 0:00:04.151691973, dts 0:00:04.151691973, dur
>> 99:99:99.999999999, size 92, offset none, offset_end none, flags 0x40
>> 0:00:05.670825393 542 0x1bd1190 DEBUG GST_SCHEDULING
>> gstpad.c:4277:gst_pad_chain_data_unchecked:<dtlssrtpdemux0:sink>
>> calling chainfunction &sink_chain with buffer buffer: 0x7f6c10005040,
>> pts 0:00:04.151691973, dts 0:00:04.151691973, dur 99:99:99.999999999,
>> size 92, offset none, offset_end none, flags 0x40
>> 0:00:05.670856500 542 0x1bd1190 LOG dtlssrtpdemux
>> gstdtlssrtpdemux.c:129:sink_chain:<dtlssrtpdemux0> pushing rtp packet
>> 0:00:05.671088870 542 0x1bd1190 WARN dtlssrtpdec
>> gstdtlssrtpdec.c:412:on_decoder_request_key:<dtlssrtpdec0> no srtp key
>> available yet
>> 0:00:05.671104066 542 0x1bd1190 WARN srtpdec
>> gstsrtpdec.c:818:request_key_with_signal:<srtpdec0> Could not get caps
>> for stream with SSRC 1792117166
>> 0:00:05.671115242 542 0x1bd1190 WARN srtpdec
>> gstsrtpdec.c:1262:gst_srtp_dec_chain:<srtpdec0> Invalid buffer,
>> dropping
>> 0:00:05.671154906 542 0x1bd1190 DEBUG GST_SCHEDULING
>> gstpad.c:4283:gst_pad_chain_data_unchecked:<dtlssrtpdemux0:sink>
>> called chainfunction &sink_chain with buffer 0x7f6c10005040, returned
>> ok
>> 0:00:05.671166503 542 0x1bd1190 DEBUG GST_SCHEDULING
>> gstpad.c:4283:gst_pad_chain_data_unchecked:<dtlssrtpdec0:sink> called
>> chainfunction &gst_proxy_pad_chain_default with buffer 0x7f6c10005040,
>> returned ok
>
> This usually means that something's not quite right with what GStreamer
> expects.
In the meantime I found
https://lists.freedesktop.org/archives/gstreamer-devel/2018-March/067319.html
. It looks that GStreamer for some reason does not perform DTSL
handshake. BTW, it seems that FreeSwitch started its part - in its log I
found this:
ccba5a1c-31b9-11e8-a1d0-adc4cccadd8b 2018-03-27 14:24:30.860282 [INFO]
switch_rtp.c:3752 Changing audio DTLS state from OFF
to HANDSHAKE
Here is one of STUN Binding Request packets sent by FreeSwitch. It was
captured during other test, so its contents does not match SDP pasted
earlier:
Frame 90: 196 bytes on wire (1568 bits), 196 bytes captured (1568 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.100.20, Dst: 192.168.100.20
User Datagram Protocol, Src Port: 24012, Dst Port: 45557
Session Traversal Utilities for NAT
[Response In: 91]
Message Type: 0x0001 (Binding Request)
Message Length: 132
Message Cookie: 2112a442
Message Transaction ID: 364e4d535879554441354a61
Attributes
USERNAME: cTbSKF2IVx3uDYZcJ0cCI+nuNS8eMHJn:uU7o0ZMkTQxjxEpF
Attribute Type: USERNAME (0x0006)
Attribute Length: 49
Username: cTbSKF2IVx3uDYZcJ0cCI+nuNS8eMHJn:uU7o0ZMkTQxjxEpF
Padding: 3
PRIORITY
Attribute Type: PRIORITY (0x0024)
Attribute Length: 4
Priority: 2013266428
SOFTWARE
Attribute Type: SOFTWARE (0x8022)
Attribute Length: 19
Software: FreeSWITCH ( 64bit)
Padding: 1
ICE-CONTROLLED
Attribute Type: ICE-CONTROLLED (0x8029)
Attribute Length: 8
Tie breaker: 3967545348314432
MESSAGE-INTEGRITY
Attribute Type: MESSAGE-INTEGRITY (0x0008)
Attribute Length: 20
HMAC-SHA1: 4ad3e5f5ef40ee8793d7c5a278043db73b36b2ca
FINGERPRINT
Attribute Type: FINGERPRINT (0x8028)
Attribute Length: 4
CRC-32: 0xbd08d97e
I hope it will help you.
Regards,
Daniel
>> Any ideas how to fix this?
>
> Depends very much on what FreeSwitch is expecting and producing :).
>
> Cheers
> -Matt
>
>> My FreeSwitch is installed on CentOS from official RPMs, and (mostly)
>> with default config. GStreamer 1.14 is compiled from sources there.
>>
>> Regards,
>> Daniel
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list