Project

General

Profile

Bug #4471

SAT>IP: Inactive streams created when the SETUP request triggers an error.

Added by DSA APF over 7 years ago. Updated about 7 years ago.

Status:
Fixed
Priority:
Normal
Category:
SAT>IP
Target version:
-
Start date:
2017-07-05
Due date:
% Done:

100%

Estimated time:
Found in version:
maser snapshot
Affected Versions:

Description

Hi,

We have found one tricky bug with “some” clients.

The problem appears when this condition is true:

- The TVHeadEnd is running as a SAT>IP server. And some frequencies are unavailable, for example, when using IPTV muxes as inputs.
- When one client request some unavailable frequency with a SETUP command, then it receives one error as the response (“RTSP/1.0 405 Method not allowed”).

Until here no problem!

- However, for each frequency unavailable the TVHeadEnd is creating internally a new “stream”. So, if the client requests, for example for 20 unused frequencies, then 20 “inactive streams” are created. Here one example of the response to a DESCRIBE command after these failed tuning requests:

RTSP/1.0 200 OK
Content-Type: application/sdp
Content-Length: 2617
CSeq: 40
Content-Base: rtsp://192.168.224.19/stream=25
v=0
o=- 8387533343261 8387533343384 IN IP4 192.168.224.19
s=SatIPServer:1 8 t=0 0
a=control:stream=3
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=4
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=5
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=6
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=7
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=8
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=9
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=10
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=11
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=12
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=13
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=14
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=15
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=16
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=17
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=18
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=19
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=20
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=21
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=22
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=23
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=24
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=25
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive


- The problem is then when the client can’t process such large response!
- This case is only true when the client uses the SETUP command for tuning unavailable frequencies.

So, we recommend to not instantiate any new stream when one error appears. In fact, if the server sends one error (4xx) it doesn’t have sense to create/modify/destroy any internal stream. Right?

We hope you consider this case and improve the behavior of the SAT>IP server module.
Regards.
D.

History

#1

Updated by Jaroslav Kysela over 7 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|72128777940978239ba535c98d2c27648687c93f.

#2

Updated by DSA APF over 7 years ago

Hi Jaroslav,

We're still testing it. However, the last patch seems to be correct.

Thank you!
D.

#3

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from Fixed to Accepted

I have to revert this patch, because of bug #4499. Perhaps, this issue is already fixed with the other satip server updates.

#4

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from Accepted to Fixed

Applied in changeset commit:tvheadend|0683521cb0c9c4384a245436a32a26e2439f487a.

#5

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from Fixed to Accepted
#6

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from Accepted to Fixed

Applied in changeset commit:tvheadend|b75bb114b7000b1aa42b795994d52194e43e9027.

Also available in: Atom PDF