Tvheadend

Just my 2 cents: I don't like this extension at all. It seems like a dup of tuning parameters and PIDs already sent - something like an internal configuration string. Some other extensions (Digital Devices) supports pmt=PID parameter for the integrated CI modules support to specify which service should be descrambled which is simplier, but also the server can identity the requested service using the audio/video PIDs already passed in the RTSP request.

the DD pmt=PID parameter is also a propriety extension and not in the standard. And DDs implementation is to use the CI over the network on the client side AFAIK, so actually not even over SAT>IP. Anyway, this extension would work for DD as well.
You can not use A/V pids to determin the service in general as multiple services can be defined with the same A/V pids for different providers with even different encryption systems.

Digital Devices has a SAT>IP server with the integrated CI slot, so I believe that descrambling is on the server side.

For the PIDs list - if the SAT>IP server knowns which CAIDs/PrividerIDs can descramble (and it should know this information) then only services which can be decoded should be decrypted. Yes, there might be shared audio/video PIDs with multiple services, but usually the services from different broadcaster use another CAIDs and the user should be able to manage the decoded services (enable/disable) on the server.

In other words - the standard SAT>IP requests ALLOW to descramble services on the server side without extra client requirements.

from english wiki:
The SAT>IP protocol doesn't provides any specific support for encrypted services. The specification only targets the tuner, and how to access to DVB streams over the network. So if the client likes to access to encrypted feeds it can do it, but needs to have the correct support for them. This is easy when the client is a device with CAS/CAM hardware support (like a television or set-top-box), but it's unclear how to do it in a PC, mobile or tablet.

From the manual of octupus net (Google translated :-)):
The CI in your Octopus Net can be used with any program (client), which can call on M3U lists RTSP links. In the RTSP links is determined whether or not a station is to be decrypted using an existing CI. Programs that can handle M3U lists, for example, are on your PC or MAC the VLC® Player. On your mobile device (smartphone or tablet) as the GoodPlayer®. Of course, the use of the browser screen TVs in the web interface of Octopus Net is possible. After SAT> IP standard is currently the DVBViewer GE suitable for the use of CIs.

So no, SAT>IP does not officially support scrambling in any way and does only work with the help of propriety extensions (actually the &tnr stuff was DVB-Viewers original way to call DDs Octopus Net). The &tnr is redundant for sure, but compared to scan PAT, CAT and each PMT of the whole TS just to find out the SID is IMHO overkill and also not done by DD

OK, I think that we are on the similar road. I just don't see any possibility to integrate this to the standard SAT>IP client in tvh, but there's a possibility to manage automatically m3u playlist in an IPTV network which will have URLs with all these credentials to obtain descrambled streams from those devices/software servers.

TVH can also detect the pids= argument automatically and filter out the services for which the PIDs are not available.

was just writing this while you replied, so think of it b4 your post, but it is quite the same :-)

but if you don't like it at all than an IPTV-m3u source with an URL to the rtspchannels.xml file would for sure be another option and maybe the clean way but more work for the coding guy. So adding the mux with the URL it gets parsed and populates the services with the URLs from the XML. Sounds cool as it would make the user happy with a fully automated setup and would make it also possible for the guys with an octopus net device to use the CIs.

just in case this might be considered, i have seen #EXTINF tags in two flavours by now
#EXTINF:-1,KabelKiosk - iTVN (DVBViewer)
#EXTINF:0,1. TF1 (Sat>IP spec)
i don't know where DVB-Viewer got the format from but it might be valid as there own creation would not make much sense (but who knows :-)). I have not yet seen an octopus net list and their implementation