SAT>IP device in HTTP mode

[userip]

Hi,

 

I have a suggestion for the SAT>IP hardware device (RTSP Network Device). At time, this device driver uses the well known RTSP+RTP mode for receiving the transport stream from the tuner. But I suggest to support also the alternative HTTP transport mode. I suggest this for a routed access to the server in another network (using also some security over firewall rules). I hope this will be easy to implement, so the commands to send are identical and the same socket is used for control and data. The side effect is a more slow channel change, because you need to start a new http connection; but it can be useful for use remote SAT>IP servers.

 

You agree this?

 

Thank you!

[Tjod]

Are you referring to "3.6.2 HTTP Streaming" in the SAT>IP Protocol Specification Version 1.2.1 ore something else?

[userip]

Yes! "3.5.16" and "3.6.2"

 

Also I like to request if the Recording Service has implemented the HTTP transport working as a SAT>IP server.

[userip]

I like to request if the Recording Service has implemented the HTTP transport working as a SAT>IP server.

 

Related to this question, after my first tryal the answer is NO.

 

See this (192.168.1.100 is the address where the RS is running):

 

Request: wget http://192.168.1.100:554/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&mtype=qpsk&sr=27500&fec=34&pids=0,16,50,104,166,1707

Answer: wget: server returned error: HTTP/1.1 404 Not Found

So, if you ask for this, at time, isn't implemented.

Edited December 11, 2014 by userip

[Griga]

The Recording Service rather adheres to the Unicast Only Profile that does not require HTTP streaming (see Appendix E).

 

However, the Recording Service is not far away from it, because DVBViewer clients may optionally receive the stream as tcp instead of udp. So i think basically responding to http get requests is missing. Time will show if this will be implemented...

[userip]

The Recording Service rather adheres to the Unicast Only Profile that does not require HTTP streaming (see Appendix E).

 

However, the Recording Service is not far away from it, because DVBViewer clients may optionally receive the stream as tcp instead of udp. So i think basically responding to http get requests is missing. Time will show if this will be implemented...

 

Yes, I know that the RS is implementing only the "restricted version" of SAT>IP server, that is documented in the last pages of the current specification (1.2.1). I don't have any problem with it. And yes, my idea is link multiple instances using HTTP for access from routed networks. So, the diagram can be:

 

hardware SAT>IP server --localLAN--> RS as SAT>IP server --HTTP--> RS as SAT>IP client

 

And DVBViewer can do that, but not the RS (as client). So I suggest to add the HTTP transport (ease to implement) in both: the server side of the SAT>IP, and in the client side.

 

I hope you agree to improve the support for the good SAT>IP protocol !

Edited December 11, 2014 by userip

[Griga]

but not the RS (as client).

 

That would be a surprise. The RTSP client code in DVBViewer and the Recording Service is identical.

[userip]

 

That would be a surprise. The RTSP client code in DVBViewer and the Recording Service is identical.

Sorry! I expresed wrong!

 

Any DVBViewer can use the "DVB Server" mode (as protocol) to connect to the RS, so it can (as client) connect to the server (RS) using TCP. But the RS don't have the option to be a client of another "DVB Server". So to link one RS (as client) to another RS (as sever) you need to use the SAT>IP protocol (and really this is the best solution!), but at time you are limited to only use the RTP transport (UDP) and not the HTTP (TCP).

 

So, I explain best now?

 

Best!

[Griga]

but at time you are limited to only use the RTP transport (UDP) and not the HTTP (TCP).

 

That's wrong.

[Tjod]

But TCP is only available if you connect to a RS as Sat>IP Server.

[Griga]

That's exactly what he wants (sorry for incomplete quoting):

 

So to link one RS (as client) to another RS (as sever) you need to use the SAT>IP protocol (and really this is the best solution!), but at time you are limited to only use the RTP transport (UDP) and not the HTTP (TCP).

[userip]

 

That's wrong.

 

Hi Griga,

 

The current RS version V1.30.1.0 (beta) don't have this option! So, you say that next version will have this implemented? In this case... great! and thank you!

 

But TCP is only available if you connect to a RS as Sat>IP Server.

 

Yes and No. The "client http transport" is only one part of the equation. My requirement is connect one RS to another RS, using the SAT>IP protocol and the HTTP transport. If the HTTP transport is already implemented in client mode, then I suggest to implement also in the server part. From my first tests, the HTTP transport in RS as server don't work... or I'm doing something wrong!

 

One more time: Thank you for your good software!

Edited December 15, 2014 by userip

[Griga]

The current RS version V1.30.1.0 (beta) don't have this option!

 

Again wrong. All recent versions have this option. The selected server must be a Recording Service instance to make it visible.

[userip]

 

Again wrong. All recent versions have this option. The selected server must be a Recording Service instance to make it visible.

Sorry?

 

The window you show is from Viewer, I'm speaking about the Recording Service. In my post I type "RS version 1.30.1.0 (beta)", beacuse is the last to download and the version that I'm using (has you published another beta version?). And in this version the Window for configure the "RTSP Network Device" don't have this "UDP" "TCP" option. Yes, the Viewer has this option, but as I explained my objetive is RS-to-RS connection, so the Viewer is not relevant.

 

I repeat the diagram:

 

Recording Service ----HTTP/SAT>IP----> Recording Service

 

Please, can I do that?

Thank you!

 

PD: I check now (2014/12/15) in members area, last version of Recording Service to download is 1.30.1 from 19.10.14.

Edited December 15, 2014 by userip

[userip]

I repeat the diagram:

 

Recording Service ----HTTP/SAT>IP----> Recording Service

 

 

 

Hi,

 

Sorry, it's my fault! I have installed RS in another computer, and when the SAT>IP server is the RS in the other computer, then in the window the UDP/TCP option appears! Is annoying, but the option works!

 

Thank you!

 

Please, can I do some suggestions? First, put this option in gray when not available, is more easy to understand it. Second, enable also the HTTP transport for other SAT>IP servers that supports it, because the standard supports it (or leave the user to force TCP if s/he likes it).

 

I'll comment my results after more tests.

Edited December 15, 2014 by userip

[Griga]

and when the SAT>IP server is the RS in the other computer, then in the window the UDP/TCP option appears!

 

it wouldn't make much sense for the RS to connect to itself on the same computer, would it? it's explicitely excluded in the UI in order to prevent beginners from doing stupid things...

 

Second, enable also the HTTP transport for other SAT>IP servers

 

The current HTTP solution is a proprietary thing that only works with RS/DVBViewer as server/client. As already mentioned:

 

So i think basically responding to http get requests is missing. Time will show if this will be implemented...

[userip]

 

The current HTTP solution is a proprietary thing that only works with RS/DVBViewer as server/client. As already mentioned:

 

 

Ok, current implementation is the thing that I need to connect local RS to remote RS using HTTP. Thank you at all!