Can't find RTSP URL for TrendNet TV-IP672WI



  • Hi all

    I have the TrendNet IP-672WI camera and am failing to find the correct RSTP link despite looking at the manual and several internet searches. I am trying to open it in VLC before I try on Alexa. I have looked at the settings on the actual camera and all seems correct including RTSP authentication enabled and the correct 554 port.

    I just submitted a support ticket to TrendNet but as the product has been discontinued for a while now, I don’t hold out hope for a reliable answer.

    Does anyone else have any experience with this or a similar camera?

    I have tried:
    rtsp://192.168.0.47:554
    rtsp://192.168.0.47:554/3gpp
    rtsp://192.168.0.47:554/Streaming/Channels/1/httpPreview
    rtsp://192.168.0.47:554/Streaming/Channels/101
    rtsp://192.168.0.47:554/play1.sdp
    rtsp://192.168.0.47:554/OVProfile00

    Thank you for any other suggestions



  • @Lewis6643

    If the camera supports the ONVIF protocol, you can attempt to use the ONVIF Device Manager tool to see if you can discover the valid RTSP URLs for this camera. See http://help.angelcam.com/en/articles/372646-how-to-find-a-rtsp-address-for-an-onvif-compatible-camera-nvr-dvr

    Thanks, Robert



  • Thanks for the reply. Unfortunately the application didn’t seem to find anything automatically so I assume my camera doesn’t support the ONVIF protocol. Are there any other ways to obtain the URL? Thanks



  • @Lewis6643 ‘’

    ONVIF is the only “discoverable” method that I know of to determine the RTSP URL. Apart from that its typically found in the documentation for each camera or at least on the manufacture’s site.

    The database results from this site are typically pretty good:
    https://www.ispyconnect.com/man.aspx?n=trendnet#

    It lists model 672WI using rtsp:// ... /play1.sdp which you already listed.

    Like you already mentioned, using VLC is the right tool to test with first just to verify the stream.

    Thanks, Robert



  • @Monocle

    PS, while port 554 is the default port, some cameras use an alternate port or allow RTSP over the HTTP connection. So you might try port 80 or whatever port the web server of the camera is running on as well.

    Thanks, Robert



  • Thanks, I was able to discover the URL which worked with VLC but didn’t work on Alexa, with the screen seeming to flash as if it was trying to connect but couldn’t. Would that be an incompatbility on my cameras side?



  • @Lewis6643

    Most likely some Alexa incompatibility with the camera stream.

    However, may users have found success using our Monocle Gateway software which can get past many incompatibility issues. If I recall correctly, I believe some users using TrendNet did get their cameras using using the Monocle Gateway and @proxy tag.

    More info:
    https://monoclecam.com/monocle-gateway

    Thanks, Robert



  • @Monocle Okay thanks, I’ll give that a go. There have been a few updates to my devices recently, which could involve the newer security features you describe in devices like the Fire Stick 4K which prevent it from loading.

    I can’t see it on the website but could you please confirm if the device that needs to stay on has to be within the local network? Or can I use my Windows VPS which is hosted with a professional host and on 24/7 even though this may slow down the stream?



  • @Lewis6643

    Yes the Monocle Gateway needs to be running 24x7 or at least whenever you would expect to use Alexa to view a camera stream.

    For simplicity it should be running inside your local network. The gateway will need direct access to each of your camera streams. Additionally each Alexa device will require direct access to port 443 of the gateway. You could run this on a hosted server; however, it would need inbound access to each camera stream on your local/private network as well as port 443 exposed for the Alexa devices to access it. Some additional custom configuration properties may also be needed to override the detected IP address and use your public IP to this hosted server as well.

    I would suggest getting it working first locally, and then we can experiment moving it outside the local network if needed.

    Thanks, Robert


Log in to reply