[Galene] Re: Building a streaming gateway for Galène

[Alexandre IOOSS <erdnaxe@crans.org>]

On 4/8/21 12:05 AM, Juliusz Chroboczek wrote:
>>> Looking at the Wireshark dump, Galène seems also to use "0" as sender
>>> SSRC, so that might be the issue. I might try to do a dirty hack
>>> somewhere to confirm this hypothesis.
> 
>> Galène doesn't choose the SSRC -- the SSRC is chosen by the offerer.
> 
> You can find out the SSRC that Galène thinks the offerer has chosen by
> adding the following line:
> 
> diff --git a/rtpconn/rtpconn.go b/rtpconn/rtpconn.go
> index eec5d97..6b7e8cb 100644
> --- a/rtpconn/rtpconn.go
> +++ b/rtpconn/rtpconn.go
> @@ -509,6 +509,7 @@ func newUpConn(c group.Client, id string, labels map[string]string, offer string
>         up := &rtpUpConnection{id: id, pc: pc, labels: labels}
>  
>         pc.OnTrack(func(remote *webrtc.TrackRemote, receiver *webrtc.RTPReceiver) {
> +               log.Println("SSID", remote.SSRC())
>                 up.mu.Lock()
>  
>                 mid := getTrackMid(pc, remote)
> 

Ok so everything is fine with SSRC. I was worried because Wireshark does
not seem to decode properly the RTP packets (encryption?).
I also confirm that keyframe requests are received by GStreamer and I
can observe the signal going back to the VP8 encoder.

I did some digging in GStreamer code and from what I understand:

1. PLI are working fine, and I can confirm that Galène manages to ask
for keyframes.

2. NACK are received but ignored because my GStreamer webrtcbin element
doesn't have "RTX" enabled.
   *
<https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/1.18/ext/webrtc/gstwebrtcbin.c#L5310>
is reached,
   *
<https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/1.18/ext/webrtc/gstwebrtcbin.c#L5324>
is never reached.

This implies that `transport_stream_get_pt(stream, "RTX")=0`, which
should not happen. I don't really understand why it's happening but
maybe it has something to do with the SDP response of Galène not
including the "a=rtpmap:100 rtx/90000"?

> The purpose of the sender RTX object is to keep a history of RTP
> packets up to a configurable limit [...]. It will listen for upstream
> custom retransmission events (GstRTPRetransmissionRequest) that comes
> from downstream (#GstRtpSession). When receiving a request it will
> look up the requested seqnum in its list of stored packets. If the
> packet is available, it will create a RTX packet according to RFC 4588
> and send this as an auxiliary stream. RTX is SSRC-multiplexed.
--
https://gstreamer.freedesktop.org/documentation/rtpmanager/rtprtxsend.html

Do you confirm that "RTX" (https://tools.ietf.org/html/rfc4588) is the
feature missing?

-- 
Alexandre
erdnaxe@crans.org