You are correct about the current UPnP server - it's a device.
I'm curious about the rest of your post. From what I've seen, the UPnP devices are roughly half "control points" (like NetGear) and half "devices" (like Linksys). Having used the Linksys (with it's own software), it browses just fine. I haven't studied this part of the protocol yet, so what am I missing - what is wrong with devices that are UPnP "devices" (ain't terminology wunnerful).
MC UPnP being a device is why I'm concerned something might be wrong with the plugin on my system since there is no port 1900 SSDP traffic from it.
Curious - which Linksys do you have? The audio/video 802.11A/B one or the audio-only 802.11B one?
I don't care much for some of the UPnP terminology either. As I've been using it, control point is any 'client' - ie. it does not expose devices or services, but can do SSDP discovery of other devices or services, get their descriptions, control them, and subscribe to their events.
'Device' is the most generic and ambiguous term, I think I am being true to definition in considering it anything which contains one or more services, and is advertised or responds to searches via SSDP NOTIFY. 'Service' is the meat of all real functionality and defines all the control methods, state variables, eventable info, etc.
The AV related UPnP 'Devices' are
MediaServer
requires ContentDirectory service
requires ConnectionManager service
optional AVTransport service
MediaRenderer
requires RenderingControl service
requires ConnectionManager service
optional AVTransport service (I cursed the working group for the confusion of having CM and optional AVT both places)
A good citizen UPnP media client would implement MediaRenderer, exposing its volume, bass, etc. CM and possibly AVT on the RenderingControl service. It would also need to be a control point which discovers and uses MediaServer (if it was a _really_ good UPnP citizen it would also even use the CP to talk to its own MediaRenderer to control volume, etc. when a user presses a button, but this is very likely to be shortcutted). The CP would use MediaServers to find and browse content on the network using ContentDirectory.
Content play start is a mess with push/pull option and ambiguity from CM+AVT being able to be on server or renderer, but CP should be able to work out how to get the AVT in one place or the other to play the content. On wired or wireless LANs with file shares or HTTP for file fetch, the most sensible combination would be client pull - ie. ContentURI is set on AVTransport on the MediaRenderer, not AVTransport on the MediaServer. I would therefore expect most UPnP media clients to have an AVTransport on their renderer, but this could realistically be a place for significant differences among different media clients.
It would surprise me if a UPnP media client tried to not have a CP - that would really mean it would be UPnP controllable only from a remote CP (useful for perhaps central control of zoned audio, but that's it). It could be possible for it to use a completely proprietary protocol for content browsing, setting up the playback, etc. and maybe expose a token MediaRenderer for volume control, but in that case I'd say claiming UPnP compliant would definitely be false advertising. Media clients may still have plenty of other legit differences - eg. whether AVTransport was implemented on renderer or if one needs to be on server to push, whether CP can also control renderer or not - and not so legit ones - eg. misimplementations, shortcuts or proprietary extensions to ugly pieces of UPnP or the AV standards.
Aaron
Author
Topic: UPnP for Media Receivers (Read 20250 times)