For all the promise of interoperability, TR-069
implementations still have a way to go. While the specification itself
is fairly well written, there is room for interpretation and error
during the implementation. For example, there is a typo in the specification
where a common word, used to define a field, is misspelled. Does
the vendor take the specification at its literal meaning, or does
the vendor correct the spelling error? Both approaches have been
taken, resulting in incompatibilities.
Another issue is the SOAP implementation. SOAP, Simple Object
Access Protocol, is the communications protocol mandated by TR-069.
The specification further mandates that all communications between
the CPE (client) and ACS (server) are done via a persistent, bi-directional
connection. However SOAP was designed for transitory, one-way communications
where the roles of client and server are clearly defined. By requiring
a persistent, bi-directional connection, TR-069 is switching these
roles during communications, something SOAP wasn't designed to
do and introducing complexity to a "simple" protocol.
As a result of this shift, developers of TR-069 software are required
to develop their own SOAP implementation. This has caused problems
on how different SOAP implementations interpret the SOAP messages.
Normally the handling functions are defined during product development
and the rest is automatic. However, in the current specification
it is necessary for the SOAP to be generated manually; a process
highly prone to errors.
The Dimark client also includes a full SOAP Parser to ensure compliance
with the standard and complete interoperability. Don't be fooled
by others who try to decrease the RAM and Flash footprint with a
partial, or hard-coded SOAP implementation; those "savings" come
at the high cost of poor interoperability, a lack of flexibility
and the resulting lost deployments.
:
|