go2rtc icon indicating copy to clipboard operation
go2rtc copied to clipboard

Published 20 hours ago • verified publisher icon AlexxIT

Alexa incompatibility with Go2RTC RTSP stream

Open lawrence-jeff opened this issue 1 year ago • 12 comments

I'm trying to get monocle (an RTSP proxy for Alexa with an associated skill) instance working with the go2RTC restream provided by Frigate (v 1.9.2)

I have found that the proxy works with the source streams but Alexa fails immediately when trying to pull the restream from go2rtc. Looking at wireshark and comparing the difference it seems that after Amazon gets the Describe result image It then tries to do a SETUP command to the go2RTC stream with the control part added, so in this example it does a SETUP to rtsp://homeassistant.local:8554/annke/trackID=0

And then go2RTC replies with Unsupported transport image

The process repeats a few times and Alexa/Amazon gives up

Bypassing go2rtc and using the same setup with the camera directly, it accepts that SETUP request and then establishes a connection. I see the same behavior across Reolink, Annke and Amcrest devices

Any thoughts on this? It would be great if go2rtc worked better with these Alexa requests then you can easily expose all your streams to the Monocle skill

lawrence-jeff avatar Jun 27 '24 04:06 lawrence-jeff

Good sleuthing on the setup traffic!

I fought with this one a lot and gave up. If you goto the Monocle forums there is some discussion about what Alexa considers a "valid" stream - seems to be a bit of a black box.

Both cams that I want to be able to use (Amcrest doorbell and turret) will work fine just pulling the RTSP stream directly including Audio. So I just live with it - since it isn't on 24/7. I have Frigate triggering car/person/dog on my front walk and person on the doorbell to turn on the Alexa camera automatically (via Home Assitant) and then turn it back off a few minutes later.

Never could get Birdseye re-stream to work on Alexa.

image

ElksInNC avatar Jul 04 '24 19:07 ElksInNC

You don't needs Wireshark. Just collect go2rtc logs with trace level for rtsp module.

AlexxIT avatar Jul 13 '24 06:07 AlexxIT

Ok - Well however we got there, is there anyway to make Go2RTC to accept a connection passing a trackID? Or to not have it advertise (probably the wrong word) it in the SDP for the Go2RTC stream? The only spec type reference I could find seemed to indicate that it should be honored if provided in the describe response

lawrence-jeff avatar Jul 14 '24 02:07 lawrence-jeff

Your question wrong. SETUP request always has control part (trackID in your example). This is part of RTSP proto and go2rtc of course support it.

You should collect logs to find real problem.

AlexxIT avatar Jul 14 '24 04:07 AlexxIT

Hi guys, I'm trying to do the same thing and failed successfully; Basically if i set the tag on monocle @proxy-tcp it works but is laggy and buffering.

The problem when tunneling seems to be the go2rtc response: 461 unsupported transport. Is there any way we can tune ffmpeg to produce a valid stream?

Logs of the "handshake" attached:

2024-11-27T23:05:45.392Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP CLIENT ATTACHED TO STREAM: Mosaico (STREAM:3255a48e-75f3-4ad6-a6c4-820fa9525d63) 2024-11-27T23:05:45.392Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP ENDPOINT SOCKET CONNECTING TO: {10.123.0.3:8554} 2024-11-27T23:05:45.392Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP ENDPOINT SOCKET CONNECTED {10.123.0.3:8554} 2024-11-27T23:05:45.393Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT REQUEST] --> [DESCRIBE] rtsp://732fe3a1-e21c-4e6c-bbb0-ac749bf41f92.mproxy.io:443/STREAM:3255a48e-75f3-4ad6-a6c4-820fa9525d63?session=6983491b-84b1-41d0-be1a-cd31304757eb 2024-11-27T23:05:45.393Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT REQUEST] --> [HEADERS] { "accept": "application/sdp", "user-agent": "Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)", "cseq": "1" } 2024-11-27T23:05:45.394Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT REQUEST] --> [DESCRIBE] rtsp://10.123.0.3:8554/birdseye 2024-11-27T23:05:45.394Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT REQUEST] --> [HEADERS] { "accept": "application/sdp", "user-agent": "Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)", "cseq": "1" } 2024-11-27T23:05:46.055Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT RESPONSE] <-- [HEADERS] { "content-type": "application/sdp", "cseq": "1", "content-length": "262" } 2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT RESPONSE] <-- [BODY] v=0 o=- 1 1 IN IP4 0.0.0.0 s=go2rtc/1.9.2 c=IN IP4 0.0.0.0 t=0 0 m=video 0 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QMKawsqAUAW6aIAAADAAgAAAMApHhAIVA=,aO44sA==; profile-level-id=640C29 a=control:trackID=0

2024-11-27T23:05:46.055Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP ENDPOINT AUTHENTICATION SUCCESSFUL: NONE 2024-11-27T23:05:46.055Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT RESPONSE] <-- [HEADERS] { "content-type": "application/sdp", "cseq": "1", "content-length": "275", "content-base": "rtsp://10.123.0.3:8554/birdseye" } 2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT RESPONSE] <-- [BODY] v=0 o=- 1 1 IN IP4 0.0.0.0 s=go2rtc/1.9.2 c=IN IP4 0.0.0.0 t=0 0 a=control:* m=video 0 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QMKawsqAUAW6aIAAADAAgAAAMApHhAIVA=,aO44sA==; profile-level-id=640C29 a=control:trackID=0

2024-11-27T23:05:46.062Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT REQUEST] --> [SETUP] rtsp://10.123.0.3:8554/birdseye/trackID=0 2024-11-27T23:05:46.062Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT REQUEST] --> [HEADERS] { "transport": "RTP/AVP/TCP;interleaved=0-1", "user-agent": "Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)", "cseq": "2" } 2024-11-27T23:05:46.063Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT REQUEST] --> [SETUP] rtsp://10.123.0.3:8554/birdseye/trackID=0 2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT REQUEST] --> [HEADERS] { "transport": "RTP/AVP/TCP;interleaved=0-1", "user-agent": "Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)", "cseq": "2" } 2024-11-27T23:05:46.063Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT RESPONSE] <-- [461 (Unsupported transport)] <cseq=2> (session=undefined) 2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [ENDPOINT RESPONSE] <-- [HEADERS] { "cseq": "2" } 2024-11-27T23:05:46.063Z [WARN] [192.168.3.98:58844 <Fne1FrTNE>] RTSP ENDPOINT RESPONSE ERROR: [SETUP] = 461 (Unsupported transport) 2024-11-27T23:05:46.063Z [DEBUG] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT RESPONSE] <-- [461 (Unsupported transport)] <cseq=2> (session=undefined) 2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 <Fne1FrTNE>] [CLIENT RESPONSE] <-- [HEADERS] { "cseq": "2" } 2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP CLIENT SOCKET CLOSED 2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP CLIENT DETACHED FROM STREAM: Mosaico (STREAM:3255a48e-75f3-4ad6-a6c4-820fa9525d63) 2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP ENDPOINT SOCKET CLOSED [192.168.3.98:58844 <Fne1FrTNE>] 2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 <Fne1FrTNE>] RTSP ENDPOINT SOCKET CLOSED {10.123.0.3:8554}

192.168.3.98 : alexa device 10.123.0.3: go2rtc instance

Also this is the same output if I try to connect to the birdseye stream, but after the 461 ffplay seems to be able to switch to another protocol and it works. I suspect that the Alexa Echo Show is not able to do so.

Anyone can point me into the right direction? thanks!

kekkokk avatar Nov 27 '24 23:11 kekkokk

go2rtc does not support RTSP over UDP. If the client device/program does not support RTSP TCP - nothing can be done.

AlexxIT avatar Nov 29 '24 11:11 AlexxIT

go2rtc does not support RTSP over UDP. If the client device/program does not support RTSP TCP - nothing can be done.

2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 ] [ENDPOINT REQUEST] --> [HEADERS] { "transport": "RTP/AVP/TCP;interleaved=0-1",

I have this same issue and if I'm reading the logs correctly the device is requesting TCP, not UDP. Using "proxy-tcp" in monocle-gateway does work which is just proxying it using TCP, so the device is asking for TCP at soem point. Just trying to do it directly fails with this "Unsupported transport" error.

djcode avatar Nov 30 '24 03:11 djcode

Ok. I needs to check logs carefully. Maybe problems in header format.

AlexxIT avatar Nov 30 '24 06:11 AlexxIT

I did a quick packet capture between the MonocleCam @tunnel (doesn't work) vs @proxy-tcp (works) modes.

@proxy-tcp - this works, but monocle-gateway is proxying the request with it's own client

Internet Protocol Version 4, Src: {{monocle-gateway}}, Dst: {{go2rtc}}
Transmission Control Protocol, Src Port: 60552, Dst Port: 8554, Seq: 152, Ack: 516, Len: 181
Real Time Streaming Protocol
    Request: SETUP rtsp://{{go2rtc}}:8554/camera/trackID=0 RTSP/1.0\r\n
    CSeq: 3\r\n
    User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2018.04.25)\r\n
    Transport: RTP/AVP/TCP;unicast;interleaved=0-1
    \r\n

@tunnel - doesn't work, monocle-gateway is tunneling the request direct from the Alexa device (Echo Show 8 1st gen in this case)

Internet Protocol Version 4, Src: {{monocle-gateway}}, Dst: {{go2rtc}}
Transmission Control Protocol, Src Port: 33214, Dst Port: 8554, Seq: 203, Ack: 516, Len: 114
[2 Reassembled TCP Segments (169 bytes): #43(55), #45(114)]
Real Time Streaming Protocol
    Request: SETUP rtsp://{{go2rtc}}:8554/camera/trackID=0 RTSP/1.0\r\n
    Transport: RTP/AVP/TCP;interleaved=0-1
    User-Agent: Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)\r\n
    CSeq: 2\r\n
    \r\n

The only obvious difference I can see, assuming there's no logic differentiating behavior based on User-Agent, is the tunneled request is missing unicast from the transport. Would this be enough to cause "461 Unsupported transport" to be returned? Can this be assumed if it is missing? I don't know enough about the protocol to be more help.

djcode avatar Dec 06 '24 05:12 djcode

I looked at the code and answered my own question and it appears that yes, go2rtc expects "unicast" to be in the transport header. If it's not there, it returns "461 Unsupported transport". https://github.com/AlexxIT/go2rtc/blob/master/pkg/rtsp/server.go#L151-L152

Maybe a regex can be used instead to determine transport compatibility?

	transport, _ := regexp.Compile("^RTP/AVP/TCP;(?:unicast;)?interleaved=")
	if transport.MatchString(tr) {
	  ...

Seems to work with both versions of the header.

RTSP spec states that if unicast/multicast is missing, that the default is multicast. 😢 https://www.rfc-editor.org/rfc/rfc2326.html#section-12.39

unicast | multicast: mutually exclusive indication of whether unicast or multicast delivery will be attempted. Default value is multicast. Clients that are capable of handling both unicast and multicast transmission MUST indicate such capability by including two full transport-specs with separate parameters for each.

djcode avatar Dec 06 '24 05:12 djcode

Fixed. Check latest master version

AlexxIT avatar Dec 06 '24 09:12 AlexxIT

I still can't seem to get this sorted on master, with Kasa, is there some special config I need to set?

EDIT: The config works fine for all cameras, but won't work for rtsp from Home Assistant, never accepts it, and times out trying to add, secondly when I did have the cameras working on the release, they worked fine in HA, but not Alexa.

briankwest avatar Dec 07 '24 01:12 briankwest

Reopen this issue if problem still exists https://github.com/AlexxIT/go2rtc/releases/tag/v1.9.8

AlexxIT avatar Jan 03 '25 14:01 AlexxIT