Advantages of the flexible and modular characteristics of the Video Access architecture include:
Application components that use the 3G-324M and Video Messaging Server interfaces can be developed and tested independently.
The 3G-324M and Video Messaging Server interfaces can use different boards and run on different chassis as long as the application uses a recognized protocol for communicating between sub-systems.
Developers can implement a variety of system designs within the scope of the flexible framework (for example, using an IP stream media play and record, connected through RTP to the 3G-324M Interface).
The following illustration shows a high-level architecture for supporting the Video Access toolkit (including an optional Video Transcoder) using NMS CG boards:
The 3G-324M Interface allows applications to manage sessions within a 3G-324M network, including call establishment, mid-call control, and call tear down. The middleware that supports the 3G-324M Interface includes H.223 multiplexer/demultiplexer and H.245 signaling stack components.
The Video Messaging Server Interface supports the play and record functions associated with audio and video streams. Applications access multimedia play and record functions through Natural Access ADI service multimedia extensions.
Audio decoding functionality in the recording path allows applications to provide functionality such as automatically terminating record operations based on silence detection. In addition, decoding can provide the first step in transcoding audio data from one encoding format to another (for example, from G.723 to AMR).
The Video Messaging Server Interface also contains a Multimedia File Interface (MMFI) library that enables an application to merge audio and video media streams into a 3GP format file and to split a 3GP format file into two separate media streams.
For information about the multimedia play and record functions and the MMFI Library, refer to the Video Messaging Server Interface Developer's Reference Manual.
Developers can use the Video Transcoder along with Video Access to perform video transcoding when required by the application. The media streams between the Video Transcoder and the Video Access components or third party devices are transported via RTP.
The video transcoder resource controller (TRC) provides Video Access components with a control interface to the Video Transcoder. A TCP/IP connection between the TRC and the Video Transcoder provides a control channel. The TRC automatically re-establishes any lost connections and reports occurrences such as the loss of connection and connection re-established connections to the controlling Video Access component.
For more information, see the Video Transcoder Developer's Reference Manual.
Media flows between the 3G-324M Interface and the Video Messaging Server Interface are transported as RTP streams. On both interfaces, control of RTP streams is provided through the Natural Access MSPP service.
To create an RTP endpoint, at least one Ethernet interface of the CG board must be enabled and the destination IP address must be accessible. If both components are located on the same CG board, they communicate through the internal IP stack and do not require external IP connectivity. If the components are located on separate CG boards, the CG board Ethernet ports must either be connected to the same IP subnet, or connected to each other using an Ethernet crossover cable.