藍色情懷

3-way conferencing using H.323

Protocols included in the H.323 specification

H.323 is a protocol suite that supports a range of protocols that provides component descriptions, signaling procedures, call control, system control, audio/video codecs, data protocols etc.

The figure above shows the range of protocols supported by the H.323 standard. The H.323 protocol suite includes a core "Conference Manager" layer to manage all conference setup activities. The "Conference Manager" is comprised of:

This scenario clearly explains how the 3-way conversation takes place using H.323 terminals and a Gatekeeper.

Explanation:

• Terminal 1 will request a call to Terminal 2 through the Gatekeeper.
• GateKeeper checks up with the Registration /Admission/Status (RAS) and gives the IP address of Terminal 2 to Terminal 1
• Now after this Terminal 2 will use this IP address to directly converse to the Terminal 2.

Call Connection:

Explanation:

• Terminal 1 creates a logical path between Terminal 1 and Terminal 2.
• Terminal 2 requests permission from gatekeeper to respond for the conversation.
• Gatekeeper responds for the call to Terminal 2.
• Terminal 2 issues an alert signal to Terminal 1 to connect. Terminal 1 establishes a connection with Terminal 2 through the IP address.

H.245 Connection:

Explanation:

• For this example, assume Terminal 1 acting as Master and become the Multipoint Controller (MC) of the conference.

Multipoint Communication:

Explanation:

• Terminal 1 invite Terminal 3 through the Gatekeeper.
• Gatekeeper resolves the IP address of Terminal 3 and sends it to Terminal 1.
• A call is setup between the two terminals 1 and 3.
• Terminal 3 request the Gatekeeper to join the conversation with Terminal 1.
• Gatekeeper then acknowledges Terminal 3’s request.
• Terminal 3 alert and connect to Terminal 1.
• H.245 connection is established between the Terminal 1 and Terminal 3.

Logical Flow of Audio Packets

 Any MultiConferencing Application uses the same set of classes as the Point-to-Point Conferencing application.

At any point in time, there are N nodes connected to the MCU. Consequently, there are N copies of H323Connection class, which will be labelled connA, connB... connN. There is only ever one H323EndPoint. There are N*(N-1) instances of audio buffers. Each connection has a dictionary, containing (N-1) instances of audiobuffers. ConnI (Connection class of the Endpoint) has audio Buffers, labeled abA, abB, abC... (Not abI) ...abM, abN

• Incoming Audio (audio data arrives at the MCU)
  • The audio codecs write to the Incoming Audio channel)
  • IncomingAudio sends data to connI
  • ConnI writes the data to the Endpoint.
  • The Endpoint copies the data to connA, connB.. (Not connI)...connM, connN)
  • The connections listed in step d copy the data to the specified audio buffer.

Thus, audio data from connI is copied into abI for connA, copied into abI for connB, copied into abI for connC etc. Thus, audio data from connI is copied (N-1) times.

• Outgoing Audio (the audio encoder requests audio data to send))
  • The audio codec requests data from the Outgoing Audio channel
  • The Outgoing Audio channel requests data from the connI
  • ConnI requests data from the Endpoint.
  • The Endpoint’s ReadAudio method then finds the connection associated with audio codec that has requested data. - In this case connI.
  • The Connection’s ReadAudio method is then called for connI.
  • Connection’s ReadAudio combines the data in each of its audiobuffers, which is abA, abB, abC... (Not abI) ...abM, abN.