RTSP authentication problem?
Hi,
I am playing with an RTSP camera (Tapo C210) that is on the local network.
The path to the stream is with credential obfuscated as and .
I tested the endpoint with VLC and it works and I can see the stream so the credentials are good.
I wanted to obtain some information from the camera so I wanted to get information about the session as per the RTSP documentation:
However, I received:
So I reproduced the steps that are taken by the library to see where the error could happen:
So far so good, userinfo is set correctly.
I read the comment that the default authentication is "basic" (https://github.com/membraneframework/membrane_rtsp/blob/master/lib/membrane_rtsp/rtsp.ex#L53).
VLC by default utilises Digest and ommits Basic authentication.
Am I setting something wrong or missing opts somewhere?
Is there any place you could recommend to look at when trying to view all available opts and their values (or examples of them)?
Thank you!
GitHub
membrane_rtsp/lib/membrane_rtsp/rtsp.ex at master · membraneframewo...
RTSP client for Elixir. Contribute to membraneframework/membrane_rtsp development by creating an account on GitHub.
11 Replies
cc @blazpie @Noarkhh
HI @Wojciech Orzechowski, would you be able to determine what call caused this
{:error, {:invalid_addrtype, "o=- 14665860 31787219 1 IN IP4 192.168.1.10"}}
error?hi @Noarkhh I came up with a way of testing what the problem is to some extend. I run an VLC RTSP stream that has no required auth (I guess the example stream you provide in the server starting script could be used as well) vs the TP-Link camera which required auth and there is no way of turning that off. I will have more info later in the evening / latest tomorrow when I organize my notes. Thank you guys!
hi again @Noarkhh , I think I found the issue (I am more than happy to create a PR as I would love to contribute, just let me know if you are happy with my suggestion and what approach to follow with a PR). I attach my Livebook with my investigation and solution.
Long story short, there was an issue with parsing the SDP's origin. I am a noobie in terms of protocols (I learned a lot during this investigation), but read the RFC8866 and RFC4566 and I don't see why the extra character "1" is there.
Hi @Wojciech Orzechowski, we've seen this issue with TP-link cameras before. Take a look here: https://discord.com/channels/464786597288738816/1101469757204615198
Apparently, TP-link support feels like this "isn't a problem", so it's unlikely that their products will start to adhere to the RFC...
@sgfn that is my issue exactly, what a shame that is the approach from them. Any ideas how to tackle that issue in the future? I would like avoid forking the library as it might get outdated. Maybe an option of a custom parser?
I think we did consider several potential solutions in the past, though I can't remember the details. @Łukasz Kita could you lend a helping hand? 🙂
Hello! Indeed, we have already seen that problem 😉 I can suggest a similar solution as I have proposed back when we encountered the problem for the first time - we could add an option to
ExSDP
parser that would allow us to run the parser in a special mode. In that mode, the parser wouldn't raise in case of not being able to parse the SDP's field - instead it would continue on parsing further fields, even if given field is marked as "necessary" by RFC. It is a similar behaviour to the one we have observed with FFmpeg and it should be applicable if you don't need information from the origin
(o=
) field of your SDP (as far as I know the RTSP plugin does not make use of that information). Alternatively, we could add a special case of parsing the o=
field with an additiona "1" as the problem with TP-Link cameras seems to be quite common and no more I would expect it to stop appearing.That sounds like a good idea. In the meanwhile, I just forked exSDP and used github mix install, but I would love to support the development of the original repo.
I played a little bit more with your RTSP example and I have a new problem: despite providing the correct authentication information, I receive 400 when I want to setup session. I put my suspicion in the notebook, but excuse my newbie understanding of the requirements of the RTSP protocol, but my investigation will find something, sooner or later. Am I missing something? @Łukasz Kita @sgfn @Noarkhh
Hi @Wojciech Orzechowski, SETUP Message doesn't need to have Session Id set. You can try debugging by basing on our rtsp_to_hls demo and by monitoring your network traffic using tools like Wireshark. Should you have any more questions feel free to ask :)
Hi @Noarkhh thank you for the confirmation. My notebook is based on the example, albeit ripped apart for more details. I will come back with more information. Thank you