Latching is not working for RTSP stream

[ololobster]

See #1218 and 49416c2.

Janus uses wrong IP 0.0.0.0 to send UDP packages. Log:

RTSP video latching: 0.0.0.0:20008
  -- RTCP: 0.0.0.0:20009

Janus receives c=IN IP4 0.0.0.0 from the camera, which is the cause of IP 0.0.0.0.
So there are no UDP packages from the camera (I am looking with wireshark). Log:

[WARN] [rtsp-test] 5s passed with no media, trying to reconnect the RTSP stream

I tried to hardcode real ip into source->rtsp_vhost here and it worked: UDP packages from the camera started flowing.

I am using branch master.

[lminiero]

Looks like a problem in the RTSP server, not Janus. If 0.0.0.0 is what they put in the SDP, then clearly our latching packet will not reach the destination. They should insert a valid IP instead. Closing.

[vashi]

Yes its maybe server bug. But its a plain web camera that can't fixed anyway. Moreover VLC plays this stream without any doubt. So, I think is better to create small workaround in Janus.

[lminiero]

We can't "invent" the remote address, so not sure which workaround we should create here... if you share (in a gist/pastebin) the SDP coming from the camera we can check if the address is available in some other field.

[ololobster]

Check out RFC 4317:

but the answer from Bob contains the connection address 0.0.0.0 and a random port
number, which means that Alice can not send media to Bob (the media
stream is "black holed" or "bh")

So camera's behaviour is correct.

We can't "invent" the remote address

We already have the remote address, we are sending DESCRIBE, SETUP and PLAY somehow.

[lminiero]

So camera's behaviour is correct.

I think you're confusing a bit of concepts and putting them together. The excerpt you mentioned described the hold functionality, which is typically used in SIP when you want to temporarily put a call on hold: it has nothing to do with RTSP. In this case, yes, the camera is saying that it doesn't want any media in, which is exactly why we can't do latching.

We already have the remote address, we are sending DESCRIBE, SETUP and PLAY somehow.

There is absolutely no guarantee in RTSP that the address sending the media will be the same as the address used for signalling: DNS may even resolve it to a completely different one.

[vovapolu]

@ololobster @lminiero Any progress on this issue? I'm also experiencing freezes every ~1 minute.

@ololobster Is there any version of janus-gateway with your fix? I would try it.

[lminiero]

There's nothing to fix in Janus in that regard, for the reasons already explained in all my answers above.

[gcbartlett]

We can't "invent" the remote address, so not sure which workaround we should create here... if you share (in a gist/pastebin) the SDP coming from the camera we can check if the address is available in some other field.

In my case (pastebin), the camera's remote address (1.2.3.4 in the pastebin) appears in two places: an origin attribute unicast-address field in the SDP, and in the RTSP SETUP answer's Transport header as a source field. Would either of these make for a suitable fallback if the SDP connection data attribute is 0.0.0.0?

According to RFC2326's discussion of the Transport header:

source:
If the source address for the stream is different than can be
derived from the RTSP endpoint address (the server in playback
or the client in recording), the source MAY be specified.

 This information may also be available through SDP. However, since
 this is more a feature of transport than media initialization, the
 authoritative source for this information should be in the SETUP
 response. 

e.g. prior to checking for ;server_port= in plugins/janus_streaming.c:

/* If the SDP does not contain a valid host address, check for an RTSP 'source' address */
if(strcmp(vhost, "0.0.0.0") == 0) {
    /* Get the RTSP 'source' address, which we'll need for the latching packet */
    const char *source = strstr(curldata->buffer, ";source=");
    if(source != NULL) {
        const char *start = source+strlen(";source=");
        const char *semicolon = strchr(start, ';');
        const size_t source_len = semicolon ? (size_t)(semicolon-start) : strlen(start);
        if (source_len < sizeof(vhost)) {
            strncpy(vhost, start, source_len);
            vhost[source_len] = '\0';
            JANUS_LOG(LOG_VERB, "  -- RTSP host (video): %s\n", vhost);
        }
    }
}

[lminiero]

The origin header not for sure. I guess the source property may be used for that, instead, even though I'm not familiar enough with the RTSP specification to know which one between source and c attribute takes the precedence when they're both there. You may want to experiment with your snippet above to see if that gets media flowing with your camera, as the RTSP camera I have always works so I can't replicate: in case, I'd be glad to review a pull request if you're willing to prepare one.

[gcbartlett]

The snippet worked for me, and got the media flowing from the camera. I submitted a pull request, thanks.

[lminiero]

I prepared a new patch to fix latching: please test.