ch02s02.html

IP_Telephony_Cookbook主要讲解的是IP电话方面的知识,对这个方面需求的读者会很有帮助

  <LI>Both endpoints registered to the same gatekeeper, in this call set up the 
  communication is decided by the signaling model configured on the Gatekeeper;
  <LI>Only calling endpoint has gatekeeper, in this call set up only the caller 
  sends messages to the Gatekeeper depending on the signaling models configured 
  while the called party sends the messages directly to the caller endpoint;
  <LI>Only called endpoint has gatekeeper, in this call set up only the called 
  party sends messages to the Gatekeeper depending on the signaling models 
  configured while the caller sends the messages directly to the called 
endpoint;
  <LI>Both endpoints registered to different gatekeepers, each of the two 
  endpoints communicate with their Gatekeeper depending on the signaling model 
  configured, additional H.225.0 RAS messages may be exchanged between 
  gatekeeper in order to retrieve location information (see <A 
  title="2.2.1.6.&nbsp;Locating zone external targets" 
  href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#sec-h323lrq">Locating 
  zone external targets section</A> for more details);
  <LI>Call set up with Fast connect procedure, in this call set up the media 
  channels are established using either the "Fast Connect" procedure. The Fast 
  Connect procedure speeds up the establishment of a basic point-to-point call 
  (only one round-trip message exchange is needed), enabling immediate media 
  stream delivery upon call connection. The Fast connect procedure is started if 
  the calling endpoint initiates it by sending a SETUP message containing the 
  fastStart element (to advice it is going to use the Fast Connect procedure). 
  Such element contains, among the other things, a sequence of all of the 
  parameters necessary to immediately open and begin transferring media on the 
  channels. Fast Connect procedure may be refused by the called endpoint 
  (motivations may be either because it wants to use features requiring use of 
  H.245 or because it does not implement it). Fast Connect procedure may be 
  refused with any H.225.0 Call signaling message up to and including the 
  CONNECT one. Refusing the Fast Connect procedure (or not initiating it) 
  requires that H.245 procedures be used for capabilities exchange and opening 
  of media channels. Moreover, the Fast Connect procedure allows to have more 
  information for the scope of H.323/SIP gatewaying (further details to be found 
  in <A title="Chapter&nbsp;4.&nbsp;Setting up basic services" 
  href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.html">Chapter 
  4</A>);
  <LI>Call setup via gateways, when a gateway is involved the call setup between 
  it and the network endpoint is the same as the endpoint-to-endpoint call set 
  up;
  <LI>Call setup with an MCU, when an MCU is involved all endpoints exchange 
  call signaling with the MCU (and with the interested Gatekeepers if any). No 
  changes are foreseen between an endpoint and the MCU call set up since it 
  proceeds the same as the endpoint-to-endpoint;
  <LI>Broadcast call setup, this kind of call set up follows the procedures 
  defined in Recommendation H.332.</LI></UL></DIV></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e783>2.2.1.5.2.&nbsp;Initial communication and 
capability exchange</H5></DIV></DIV>
<DIV></DIV>
<P>After exchanging call setup messages, the endpoints shall, if they plan to 
use H.245, establish the H.245 Control Channel. The H.245 Control Channel is 
used for the capability exchange and to open the media channels. The H.245 
Control channel procedures shall either not be started or closed if CONNECT does 
not arrive (an H.245 Control channel can be opened on reception of ALERTING or 
CALL PROCEEDING messages, too) or an endpoint sends RELEASE COMPLETE. H.323 
endpoints shall support the capabilities exchange procedure of H.245. The H.245 
TERMINALCAPABILITYSET message is used for endpoint system capabilities exchange. 
This message shall be the first H.245 message sent. Master-slave determination 
procedure of H.245 has to be supported by H.323 compliant endpoints as a must. 
In cases of multipoint conferencing (MC) capability is present in more than one 
endpoint, the master-slave determination is used for determining which MC will 
play an active role. The H.245 Control channel procedure also provides 
master-slave determination for opening bi-directional channels for data. After 
Terminal Capability Exchange has been initiated, master-slave determination 
procedure (consisting of either MASTERSLAVEDETERMINATION or 
MASTERSLAVEDETERMINATIONACK) has to be started as the first H.245 Conference 
control procedure. Upon failure of initial capability exchange or master-slave 
determination procedures a maximum of two retries shall be performed before the 
endpoint passes to the Call Termination phase. Normally, after successful 
completion of the requirements of this phase, the endpoints shall proceed 
directly to Establishment of audiovisual communication phase.</P>
<DIV class=sect5 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H6 class=title><A id=d0e788>2.2.1.5.2.1.&nbsp;Encapsulation of H.245 messages 
within H.225.0 Call signaling messages</H6></DIV></DIV>
<DIV></DIV>
<P>Encapsulation of H.245 messages inside H.225.0 Call signaling messages 
instead of establishing a separate H.245 channel is possible in order to save 
resources, synchronize call signaling and control, and reduce call setup time. 
This process is named as "encapsulation" or "tunneling" of H.245 messages. This 
procedure allows the terminal to copy the encoded H.245 message using one 
structure inside the data of the Call Signaling Channel. If tunneling is used, 
any H.225.0 Call signaling message may contain one or more H.245 messages. If 
there is no need of sending an H.225.0 Call signaling message when an H.245 
message has to be transmitted, a FACILITY message shall be sent detailing (with 
appropriate fields inside) the reason of such a message.</P></DIV></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e793>2.2.1.5.3.&nbsp;Establishment of audiovisual 
communication</H5></DIV></DIV>
<DIV></DIV>
<P>The Establishment of audiovisual communication shall follow the procedures of 
Recommendation H.245. Open logical channels for the various information streams 
are opened using the H.245 procedures. The audio and video streams are 
transported using an unreliable protocol while data communications are 
transported using a reliable protocol. The transport address that the receiving 
endpoint has assigned to a specific logical channel (audio, video or data) is 
transported by the OPENLOGICALCHANNELACK message (an example is given in <A 
title="Figure&nbsp;2.7.&nbsp;OPENLOGICALCHANNELACK message content" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#openlogicalchannelack">Figure&nbsp;2.7</A>). 
That transport address is used to transmit the information stream associated 
with that logical channel.</P>
<DIV class=figure><A id=openlogicalchannelack>
<P class=title><B>Figure&nbsp;2.7.&nbsp;OPENLOGICALCHANNELACK message 
content</B></P>
<DIV class=mediaobject align=center><IMG 
alt="OPENLOGICALCHANNELACK message content" 
src="ch02s02.files/openlogicalchannelack.png" align=middle></DIV></DIV></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e806>2.2.1.5.4.&nbsp;Call services</H5></DIV></DIV>
<DIV></DIV>
<P>When the call is active, the terminal may request additional call services, 
among those we report here on the Bandwidth changes services and on the 
Supplementary services. As regards as Bandwidth changes services, during a 
conference, the endpoints or Gatekeeper (if involved) may, at any time, request 
an increase or decrease in the call bandwidth. If the aggregate bit rate of all 
transmitted and received channels does not exceed the current call bandwidth 
then an endpoint may change the bit rate of a logical channel without requesting 
a bandwidth change. After requesting for bandwidth change, the endpoint shall 
wait for confirmation prior to actually changing the bit rate (confirmation 
usually comes from the Gatekeeper). Asking call bandwidth changes is performed 
using a BANDWIDTH CHANGE REQUEST (BRQ) message, if the request is not accepted, 
a BANDWIDTH CHANGE REJECT (BRJ) message is returned to endpoint. If the request 
is accepted, a BANDWIDTH CHANGE CONFIRM (BCF) is sent back to the endpoint. As 
regards as Supplementary services, support for them is optional. The 
H.450-Series of Recommendations describe a method of providing Supplementary 
Services in the H.323 environment. <A 
title="Figure&nbsp;2.8.&nbsp;Supplementary services of the H.450-Series" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#supplementary-services-table">Figure&nbsp;2.8</A> 
reports some of the supplementary services defined so far and their 
Recommendation number.</P>
<DIV class=figure><A id=supplementary-services-table>
<P class=title><B>Figure&nbsp;2.8.&nbsp;Supplementary services of the 
H.450-Series</B></P>
<DIV class=mediaobject align=center><IMG 
alt="Supplementary services of the H.450-Series" 
src="ch02s02.files/supplementary-services-table.png" 
align=middle></DIV></DIV></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e819>2.2.1.5.5.&nbsp;Call termination</H5></DIV></DIV>
<DIV></DIV>
<P>A call may be terminated either by both endpoint or by the Gatekeeper. Call 
termination is defined using the following procedure:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>video should be terminated after a complete picture and then all logical 
  channels for video closed;
  <LI>data transmission should be terminated and then all logical channels for 
  data closed;
  <LI>audio transmission should be terminated and then all logical channels for 
  audio closed;
  <LI>the H.245 ENDSESSIONCOMMAND message (H.245 Control Channel) should be sent 
  by the endpoint/Gatekeeper, this message indicates that the call has to be 
  disconnected, then the H.245 message transmission should be terminated;
  <LI>the ENDSESSIONCOMMAND message should be sent back to the sending endpoint 
  and then the H.245 Control Channel should be closed;
  <LI>a RELEASE COMPLETE message should be sent closing the Call Signaling 
  channel if this is still open;</LI></UL></DIV>
<P>An endpoint receiving ENDSESSIONCOMMAND message does not need to receive it 
back again after replying to it in order to clear a call. Terminating a call 
within a conference does not mean the all conference needs to be terminated. In 
order to terminate a conference an H.245 message (DROPCONFERENCE) is used, then 
the MC should terminate the calls with the endpoint as described above.</P>
<P>A call may be terminated differently depending on the Gatekeeper presence and 
on the party issuing the call termination:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI><SPAN class=emphasis><EM>Call clearing without a Gatekeeper</EM></SPAN> - 
  No further action is required.
  <LI><SPAN class=emphasis><EM>Call clearing with a Gatekeeper</EM></SPAN> - The 
  Gatekeeper needs to be informed about the Call termination. After RELEASE 
  COMPLETE is sent, an H.225.0 DISENGAGE REQUEST (DRQ) message should be sent by 
  each endpoint to its Gatekeeper. A Disengage Confirm (DCF) message is sent 
  back to the endpoints to acknowledge the reception.
  <LI><SPAN class=emphasis><EM>Call clearing issued by the 
  Gatekeeper</EM></SPAN> - A call may be terminated by the Gatekeeper by sending 
  a DRQ to an endpoint. The procedure described above for Call termination 
  should be immediately followed by the endpoint up to the RELEASE COMPLETE 
  message included,then a reply to the Gatekeeper should be sent using a DCF 
  message. The other endpoint should follow the same Call termination procedures 
  upon receiving the ENDSESSIONCOMMAND message. Moreover, if a multipoint 
  conference is taking place, in order to close the entire conference, the 
  Gatekeeper should send a DRQ to each endpoint in the 
conference.</LI></UL></DIV></DIV></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=sec-h323lrq>2.2.1.6.&nbsp;Locating zone external 
targets</H4></DIV></DIV>
<DIV></DIV>
<P>When calling an address that is registered at the same gatekeeper as the 
caller, the case - the gatekeeper just needs to look up its internal tables to 
resolve the target address. Complexity enters the picture if the destination 
address is registered with another gatekeeper. While <A 
title="Chapter&nbsp;7.&nbsp;Global telephony integration" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch07.html">Chapter&nbsp;7</A> 
will cover this topic in more detail, the most basic mechanism H.323 provides