Alexa incompatibility with Go2RTC RTSP stream

[lawrence-jeff]

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

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

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

[ElksInNC]

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.

[AlexxIT]

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

[lawrence-jeff]

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

[AlexxIT]

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.

[kekkokk]

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 ] RTSP CLIENT ATTACHED TO STREAM: Mosaico (STREAM:3255a48e-75f3-4ad6-a6c4-820fa9525d63)
2024-11-27T23:05:45.392Z [INFO] [192.168.3.98:58844 ] RTSP ENDPOINT SOCKET CONNECTING TO: {10.123.0.3:8554}
2024-11-27T23:05:45.392Z [INFO] [192.168.3.98:58844 ] RTSP ENDPOINT SOCKET CONNECTED {10.123.0.3:8554}
2024-11-27T23:05:45.393Z [DEBUG] [192.168.3.98:58844 ] [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 ] [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 ] [ENDPOINT REQUEST] --> [DESCRIBE] rtsp://10.123.0.3:8554/birdseye
2024-11-27T23:05:45.394Z [TRACE] [192.168.3.98:58844 ] [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 ] [ENDPOINT RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined)
2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 ] [ENDPOINT RESPONSE] <-- [HEADERS] {
"content-type": "application/sdp",
"cseq": "1",
"content-length": "262"
}
2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 ] [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 ] RTSP ENDPOINT AUTHENTICATION SUCCESSFUL: NONE
2024-11-27T23:05:46.055Z [DEBUG] [192.168.3.98:58844 ] [CLIENT RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined)
2024-11-27T23:05:46.055Z [TRACE] [192.168.3.98:58844 ] [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 ] [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 ] [CLIENT REQUEST] --> [SETUP] rtsp://10.123.0.3:8554/birdseye/trackID=0
2024-11-27T23:05:46.062Z [TRACE] [192.168.3.98:58844 ] [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 ] [ENDPOINT REQUEST] --> [SETUP] rtsp://10.123.0.3:8554/birdseye/trackID=0
2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 ] [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 ] [ENDPOINT RESPONSE] <-- [461 (Unsupported transport)] <cseq=2> (session=undefined)
2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 ] [ENDPOINT RESPONSE] <-- [HEADERS] {
"cseq": "2"
}
2024-11-27T23:05:46.063Z [WARN] [192.168.3.98:58844 ] RTSP ENDPOINT RESPONSE ERROR: [SETUP] = 461 (Unsupported transport)
2024-11-27T23:05:46.063Z [DEBUG] [192.168.3.98:58844 ] [CLIENT RESPONSE] <-- [461 (Unsupported transport)] <cseq=2> (session=undefined)
2024-11-27T23:05:46.063Z [TRACE] [192.168.3.98:58844 ] [CLIENT RESPONSE] <-- [HEADERS] {
"cseq": "2"
}
2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 ] RTSP CLIENT SOCKET CLOSED
2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 ] RTSP CLIENT DETACHED FROM STREAM: Mosaico (STREAM:3255a48e-75f3-4ad6-a6c4-820fa9525d63)
2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 ] RTSP ENDPOINT SOCKET CLOSED [192.168.3.98:58844 ]
2024-11-27T23:05:46.116Z [INFO] [192.168.3.98:58844 ] 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!

[AlexxIT]

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

[djcode]

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.

[AlexxIT]

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

[djcode]

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]

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.

[AlexxIT]

Fixed. Check latest master version