Identity and Discovery

Identity and Discovery

How a speaker identifies itself over SSC, how it announces itself on the network, and what that means for its address.

Source marks [measured], [Sennheiser]: see the legend on Home. Tested hardware: KH 120 II firmware 1_7_3, KH 750 DSP firmware 2_1_2, two units of each. Types and flags below are what the speakers report about themselves via osc/limits, checked by reading every leaf. Other models (KH 80 DSP, KH 150, ...) are not tested on hardware (see Limits-and-Untested).

Identity fields

All fields live under device/identity/ and are read one leaf at a time (see SSC-Protocol; types in SSC-Paths).

Path	Value format	Source
product	Text, e.g. KH 120 II, KH 750	[measured]
vendor	Text, Georg Neumann GmbH on both tested models	[measured]
serial	Text (type String)	[measured]
version	Firmware version with underscores, major_minor_patch, e.g. 1_7_3, 2_1_2	[measured]
hw_version	Integer (type Number)	[measured]

Notes:

• device/identity/hw_revision and device/identity/manufacturer do not exist on the tested models (answer 404 on both models; rejected on all four units in the 2026-10-17 probe). [measured]
• osc/limits marks serial, product, vendor and version as constant; for hw_version it reports const false and writeable false, so it is read-only but not constant. [measured]
• The serial number identifies a speaker across address changes; it is the right key for a client to remember a speaker by. Treat it as personal data: it ties the device to its owner.

"KH 750" vs. "KH 750 DSP"

Item	Value	Source
Product name reported over SSC by the KH 750 DSP	KH 750 (no "DSP")	[measured]

Non-Neumann SSC devices

SSC is not Neumann-only. Sennheiser's guide describes the same protocol for its EW-DX line, over UDP and IPv4 [Sennheiser]. A client should check vendor before it assumes the Neumann paths.

mDNS

Item	Value	Source
Service type	_ssc._tcp.local.	[measured]
Port	45	[measured]
TXT keys	txtvers, model, sscvers (1.1), id	[measured]
TXT id	The device serial	[measured]
Addresses in the record	Global IPv6 and link-local IPv6	[measured]
Unsolicited announcements	None observed (7 min passive capture)	[measured]
Record TTLs	AAAA 120 s; PTR/SRV/TXT 4500 s	[measured]

python-zeroconf defaults to IPv4 only; a browse with default settings found none of these IPv6-only devices. [measured]

SSC has no authentication [measured], and mDNS has none by design; forging an announcement was not tested on hardware. A client that follows a speaker to a new address should therefore read the serial over SSC at that address before it trusts the announcement.

Link-local vs. global address

SSC on the tested speakers is IPv6-only. [measured]

Property	Link-local (fe80::/10)	Global
Needs a scope ID / interface	Yes	No
Derived from	The device MAC	The prefix delegated by the ISP
Stays valid	As long as the speaker is on the same network segment	Until the ISP prefix changes

Observed after an ISP prefix change: stored global addresses no longer reached the speakers, while they still answered on their link-local addresses. A client should store the link-local address. [measured]

Link-local addresses and mDNS do not cross routers: the client has to share the layer-2 segment with the speakers. A link-local address is derived from the MAC address, so it identifies the device as well; mask it in logs.

See also: SSC-Protocol · SSC-Paths · Limits-and-Untested