Previous: Protocol MIC-0 - The interface to the CCS
Up: Channel Server
Next: Proxy MIC-1
Previous Page: Protocol MIC-0 - The interface to the CCS
Next Page: Proxy MIC-1
MIC-1 is the protocol by which the Channel Server discovers the capabilities of the remote codec, and by which the remote codec (via it's controller) is set into a known and useful state. Like all client-server protocols, it is asymmetric. We shall refer to the directions as MIC-1-CH for messages originating in the Channel Server and MIC-1-RC for messages originating in the Remote Codec Controller.
Note that MIC-1 is only used in this form for codecs that are under direct control of the CMMC (usually codecs transmitting unicast to the CMMC).
MIC-1-CH messages can be be of the following types:
MIC-1-RC messages can be of the following types:
For each network type:
An MIC-1-CH Capability Request should generate a MIC-1-RC Capability Report in response. Every other MIC-1-CH request should generate an MIC-1-RC State Report in response. Any unrequested change of state in the remote codec (other than a brief loss of incoming data traffic) should also generate a state report, but state reports that are not responses to requests should not be generated more often than once every second. If, for any reason, a remote codec cannot comply with a Set State request, it should achieve the nearest state it can comply with ("nearest state" is left to the implementor to define), and report that state in it's State Report. The channel server will then attempt to comply with the remote codec if it can do so.
Clearly the remote codec does not really need to report all this state every time a change has occurred, but as this is intended as a low data rate control channel, then extra overhead is considered minimal, and the redundancy increases the available recovery mechanisms when failures result in inconsistent state.
The syntax of MIC-1 is defined in Appendix 4.