• Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    RLC-523WA

    Reolink
    2
    6
    560
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      will last edited by

      I am using Monocle for several Reolink models. E1, E1-Pro E1-Zoom, and RLC-523WA.

      No issues with any E1 model. However, RLC-523WA returns a ‘track1’ at the end of the RTSP URL returned from SETUP (I see this in Monocle log below). It then fails since the URL is bogus.

      [SETUP] rtsp://127.0.0.1:8554/STREAM:713e7a58-bfb9-421a-a8a3-dd297fa15088/track1

      also with Tunnel

      [SETUP] rtsp://192.168.7.104/h264Preview_01_sub/track1

      I have tried @proxy, @tunnel, @fake-fmtp, @fakefmtp, @ntpnow. All to no avail.

      I am running Monocle-gateway on a Raspberry 64bit.

      Help?

      Monocle 1 Reply Last reply Reply Quote 0
      • Monocle
        Monocle @will last edited by Monocle

        @will

        The track1 is automatically getting added to the RTSP request because it gets defined in the [DESCRIBE] response from the camera. Take a look in the example log below and you will find a line “a=control:trackID=0” in the video channel description received from the camera. If you look lower in the log you will see this gets appended to the URL that makes the [SETUP] request to the camera. This is all normal and part of the RTSP specification. So if you check your log for the DESCRIBE response data from the camera, I suspect you will see a line that says “a=control:track1” .

        [TRACE] [10.1.42.97:53147 <Izq4sEPVj>] [CLIENT RESPONSE] <-- [BODY]
         v=0
         o=- 2251942545 2251942545 IN IP4 0.0.0.0
         s=Media Server
         c=IN IP4 0.0.0.0
         t=0 0
         a=control:*
         a=range:npt=now-
         m=video 0 RTP/AVP 96
         a=rtpmap:96 H264/90000
         a=fmtp:96 packetization-mode=1;profile-level-id=4D4032;
         a=control:trackID=0
         a=recvonly
         m=audio 0 RTP/AVP 8
         a=rtpmap:8 PCMA/8000
         a=control:trackID=1                        <---------------------------------HERE
         a=recvonly
        [DEBUG] [10.1.42.97:53147 <Izq4sEPVj>] [CLIENT REQUEST]  --> [SETUP] rtsp://amcrest-camera.mydomain.com:554/cam/realmonitor?channel=1&subtype=0/trackID=0
        [TRACE] [10.1.42.97:53147 <Izq4sEPVj>] [CLIENT REQUEST]  --> [HEADERS] {
           "transport": "RTP/AVP/TCP;interleaved=0-1",
           "user-agent": "stagefright/1.2 (Linux;Android 5.1.1)",
           "cseq": "2"
         }
        
        

        Monocle: https://monoclecam.com
        Getting Started | Troubleshooting Guide | FAQ | Contact Support

        W 4 Replies Last reply Reply Quote 0
        • W
          will @Monocle last edited by

          @Monocle I appreciate the response. What is occuring is for this model in the log there is a 401 (unauth) error coming back. I assumed it is due to this URL and ‘track1’ getting added. All other Reolinks for me work.

          1 Reply Last reply Reply Quote 0
          • W
            will @Monocle last edited by

            @Monocle Here is the log 9f798f6e-dae4-444f-9f2e-4ecc22b4af69-image.png

            1 Reply Last reply Reply Quote 0
            • W
              will @Monocle last edited by

              @Monocle No, its not a credential issue.

              1 Reply Last reply Reply Quote 0
              • W
                will @Monocle last edited by

                @Monocle If I use @proxy or @proxy-tcp as opposed to tunnel there is no 401 (auth) issue. However, Alexa just hangs on ‘buffering’ forever.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Privacy Policy  |  Terms & Conditions

                © 2018 shadeBlue, LLC.