Audio only streams don't work ERROR: wrong interleaved IDs

[t3therdev]

v0.16.0

Which operating system are you using?

OS

• Linux
• Windows
• macOS

Describe the issue

When using audio only rtsp streams, the server won't relay them.

Describe how to replicate the issue

Send audio only rtsp stream.

See attached logs.
audio_only_log.txt

[aler9]

Hello, this is caused by the fact that Larix uses ids 2 and 3 to stream audio:

2021/05/24 19:29:47 D [0/0] [RTSP] [conn XX.XXX.XXX.XX:36156] [c->s] SETUP rtsp://XX.XXX.XXX.XX:8554/channel1/streamid=1 RTSP/1.0
CSeq: 3
Session: 3885109565
Transport: RTP/AVP/TCP;unicast;interleaved=2-3;mode=record
User-Agent: Larix/1.1.5

While the server requires ids 0 and 1 for the first stream.

Technically, Larix is right, since a stream can use any interleaved id, and they shouldn't be constrained.

[InSpectrumed]

Hello. I also have this error.
OS: Linux
rtsp-simple-server v0.15.5

My stream:

gst-launch-1.0 videotestsrc ! clockoverlay halignment=right valignment=top text="SERVER h264 " shaded-background=true font-desc="Sans, 36" ! videoconvert ! videoscale ! video/x-raw,format=I420 ! x264enc tune=zerolatency bitrate=500 speed-preset=ultrafast ! h264parse ! queue ! s.sink_0 audiotestsrc ! audio/x-raw,width=16,depth=16,rate=44100,channels=1 ! queue ! audioconvert ! audioresample ! voaacenc ! aacparse ! queue ! s.sink_1 rtspclientsink name=s location=rtsp://localhost:8554/mystream/test/264

on server:
2021/06/06 22:37:13 [I] [1/0/0] [client [:: 1]: 57234] connected (RTSP / TCP)
2021/06/06 22:37:15 [I] [1/1/0] [client [:: 1]: 57234] is publishing to path 'mystream / test / 264', 2 tracks with udp
2021/06/06 22:37:58 [I] [2/1/0] [client [:: 1]: 36559] connected (RTSP / TCP)
2021/06/06 22:37:58 [I] [2/1/0] [client [:: 1]: 36559] ERR: wrong interleaved IDs, expected [2 3], got [0 1]
2021/06/06 22:37:58 [I] [1/1/0] [client [:: 1]: 36559] disconnected

How can I solve this problem?

[RogerHardiman]

I have just hit this problem as well, the RTSP Client is the Motorola/IndigoVision CCTV Viewing Software.

I checked the RFCs for what is included in the SETUP command from client to rtsp server. It says

   interleaved:
          The interleaved parameter implies mixing the media stream with
          the control stream in whatever protocol is being used by the
          control stream, using the mechanism defined in Section 10.12.
          The argument provides the channel number to be used in the $
          statement. This parameter may be specified as a range, e.g.,
          interleaved=4-5 in cases where the transport choice for the
          media stream requires it.

It also includes the example with Interleaved as 4 and 5.

I had a look at what I wrote in the C# code in SharpRTSP here on Github.
I parse the Transport string Transport: RTP/AVP/TCP;unicast;interleaved=168-169 and cache the values from Interleaved to use when writing the RTP payloads back into the RTSP stream

So should be a simple fix.

[RogerHardiman]

For logs, here is Wireshark from IndigoVision to simple-rtsp-client

DESCRIBE rtsp://127.0.0.1:8554/transcode RTSP/1.0
Accept: application/sdp
User-Agent: IndigoVision RTSP client
CSeq: 1

RTSP/1.0 200 OK
CSeq: 1
Content-Base: rtsp://127.0.0.1:8554/transcode/
Content-Length: 348
Content-Type: application/sdp
Server: gortsplib

v=0
o=- 0 0 IN IP4 127.0.0.1
s=Stream
c=IN IP4 0.0.0.0
t=0 0
m=video 0 RTP/AVP 96
b=AS:15000
a=rtpmap:96 H264/90000
a=control:trackID=0
m=audio 0 RTP/AVP 96
b=AS:768
a=rtpmap:96 MPEG4-GENERIC/48000/2
a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1190
a=control:trackID=1

SETUP rtsp://127.0.0.1:8554/transcode/trackID=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=168-169
User-Agent: IndigoVision RTSP client
CSeq: 2

[aler9]

linked to bluenviron/gortsplib#47

[t3therdev]

Hi, is there any update on this issue? Thanks!

[aler9]

fixed in main, will be available in the next release.

[aler9]

added in v0.16.4

[github-actions]

This issue is being locked automatically because it has been closed for more than 6 months.
Please open a new issue in case you encounter a similar problem.