ch02s02.html

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

successful a CONNECT message is sent back to the caller to indicate acceptance 
of the call. Before sending the CONNECT message, two other messages may be sent 
from the called party to the caller (those two messages are not depicted in the 
figure since we have reported only mandatory messages):</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>ALERTING message, this message may be sent by the called user to indicate 
  that called user alerting has been initiated (in everyday terms, the "phone is 
  ringing");
  <LI>CALL PROCEEDING message, this message may be sent by the called user to 
  indicate that requested call establishment has been initiated and no more call 
  establishment information will be accepted.</LI></UL></DIV>
<DIV class=figure><A id=direct-model>
<P class=title><B>Figure&nbsp;2.4.&nbsp;Direct signaling model</B></P>
<DIV class=mediaobject align=center><IMG alt="Direct signaling model" 
src="ch02s02.files/direct-model.png" align=middle></DIV></DIV>
<P>The CONNECT message closes the H.225.0 Call signaling part of the call and 
make the Terminals starting the H.245 Conference control one. In such call model 
the H.245 Conference control messages are exchanged directly between the two 
endpoints (the correct "h245Address" was retrieved from the CONNECT message 
itself). The procedures started with the H.245 Conference control channel are 
used to:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>allow the exchange of audiovisual and data capabilities, with the TERMINAL 
  CAPABILITY messages;
  <LI>request the transmission of a particular audiovisual and data mode, with 
  the LOGICAL CHANNEL SIGNALING messages;
  <LI>to manage the logical channels used to transport the audiovisual and data 
  information;
  <LI>to establish which terminal is the master terminal and which is the slave 
  terminal for the purposes of managing logical channels, with the MASTER SLAVE 
  DETERMINATION messages;
  <LI>to carry various control and indication signals;
  <LI>to control the bit rate of individual logical channels and the whole 
  multiplex, with the MULTIPLEX TABLE SIGNALING messages;
  <LI>to measure the round trip delay, from one terminal to the other and back, 
  with the ROUND TRIP DELAY messages.</LI></UL></DIV>
<P>Once the H.245 Conference control messages are exchanged the two endpoints 
have all the necessary information to open the media streams.</P></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e665>2.2.1.4.2.&nbsp;Gatekeeper routed call signaling 
model</H5></DIV></DIV>
<DIV></DIV>
<P>The <SPAN class=emphasis><EM>Gatekeeper routed call signaling 
model</EM></SPAN> is depicted in <A 
title="Figure&nbsp;2.5.&nbsp;Gatekeeper Routed call signaling model" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#gk-routed-callsign-model">Figure&nbsp;2.5</A>. 
In this model the H.245 Conference control messages are exchanged directly 
between the call termination. As each call, the communication starts with an ARQ 
(Admission ReQuest) message sent by the caller to its Gatekeeper. The ARQ 
message is used by the endpoint to be allowed to access the packet-based network 
by the Gatekeeper, which either grants the request with an ACF (Admission 
ConFirm) or denies it with an ARJ (Admission ReJect). After this first step the 
Call signaling part of the call begins with the transmission of the SET UP 
message from the caller to its Gatekeeper. The transport address of the SET UP 
message (and of all the H.225.0 Call signaling messages) is retrieved by the 
caller from the "destCallSignalAddress" field carried inside the ACF received, 
in the case of Gatekeeper routed call signaling model it is the address of the 
Gatekeeper itself. The SET UP message is then forwarded by the Gatekeeper (or by 
the "Gatekeeper network") to the called endpoint. Upon receiving the SET UP 
message the called party starts its H.225.0 RAS procedure with its Gatekeeper, 
if successful a CONNECT message is sent to indicate acceptance of the call; 
because of the call model, also this message is sent to the called endpoint's 
Gatekeeper which is in charge of forwarding it to the caller endpoint (either 
directly or using the "Gatekeeper network"). Before sending the CONNECT message, 
two other messages may be sent from the called party to its Gatekeeper (those 
two messages are not depicted in the figure since we have reported only 
mandatory messages):</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>ALERTING message, this message may be sent by the called user to indicate 
  that called user alerting has been initiated (in everyday terms, the "phone is 
  ringing");
  <LI>CALL PROCEEDING message, this message may be sent by the called user to 
  indicate that requested call establishment has been initiated and no more call 
  establishment information will be accepted.</LI></UL></DIV>
<DIV class=figure><A id=gk-routed-callsign-model>
<P class=title><B>Figure&nbsp;2.5.&nbsp;Gatekeeper Routed call signaling 
model</B></P>
<DIV class=mediaobject align=center>
<TABLE cellSpacing=0 cellPadding=0 width=496 
summary="manufactured viewport for HTML img" border=0>
  <TBODY>
  <TR>
    <TD align=middle><IMG alt="Gatekeeper Routed call signaling model" 
      src="ch02s02.files/gk-routed-callsign-model.png" width=496 
  align=middle></TD></TR></TBODY></TABLE></DIV></DIV>
<P>The two optional messages listed above are then forwarded by the Gatekeeper 
(or by the "Gatekeeper network") to the caller. After receiving the CONNECT 
message, the caller starts the procedures H.245 Conference control channel 
procedures directly with the called party (the correct "h245Address" was 
retrieved from the CONNECT message itself). The H.245 Conference control channel 
procedure scopes are the same detailed above, please refer to <A 
title=2.2.1.4.1.&nbsp; 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#sec-direct-sign-model">Direct 
signaling model section</A> for details.</P></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e693>2.2.1.4.3.&nbsp;Gatekeeper routed H.245 control 
model</H5></DIV></DIV>
<DIV></DIV>
<P>The <SPAN class=emphasis><EM>Gatekeeper routed H.245 control 
model</EM></SPAN> is depicted in <A 
title="Figure&nbsp;2.6.&nbsp;Gatekeeper Routed H.245 control model" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#gk-routed-h245contr-model">Figure&nbsp;2.6</A>. 
In this model only the media streams are exchanged directly between the call 
termination. As each call, the communication starts with an ARQ (Admission 
ReQuest) message sent by the caller to its Gatekeeper. The ARQ message is used 
by the endpoint to be allowed to access the packet-based network by the 
Gatekeeper, which either grants the request with an ACF (Admission ConFirm) or 
denies it with an ARJ (Admission ReJect). After this first step the Call 
signaling part of the call begins with the transmission of the SET UP message 
from the caller to its Gatekeeper. The transport address of the SET UP message 
(and of all the H.225.0 Call signaling messages) is retrieved by the caller from 
the "destCallSignalAddress" field carried inside the ACF received, in the case 
of Gatekeeper routed H.245 control model it is the address of the Gatekeeper 
itself. The SET UP message is then forwarded by the Gatekeeper (or by the 
"Gatekeeper network") to the called endpoint. Upon receiving the SET UP message 
the called party starts its H.225.0 RAS procedure with its Gatekeeper, if 
successful a CONNECT message is sent to indicate acceptance of the call; because 
of the call model, also this message is sent to the called endpoint's Gatekeeper 
which is in charge of forwarding it to the caller endpoint (either directly or 
using the "Gatekeeper network"). Before sending the CONNECT message, two other 
messages may be sent from the called party to its Gatekeeper (those two messages 
are not depicted in the figure since we have reported only mandatory 
messages):</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>ALERTING message, this message may be sent by the called user to indicate 
  that called user alerting has been initiated (in everyday terms, the "phone is 
  ringing");
  <LI>CALL PROCEEDING message, this message may be sent by the called user to 
  indicate that requested call establishment has been initiated and no more call 
  establishment information will be accepted.</LI></UL></DIV>
<DIV class=figure><A id=gk-routed-h245contr-model>
<P class=title><B>Figure&nbsp;2.6.&nbsp;Gatekeeper Routed H.245 control 
model</B></P>
<DIV class=mediaobject align=center><IMG 
alt="Gatekeeper Routed H.245 control model" 
src="ch02s02.files/gk-routed-h245contr-model.png" align=middle></DIV></DIV>
<P>The two optional messages listed above are then forwarded by the Gatekeeper 
(or by the "Gatekeeper network") to the caller. After receiving the CONNECT 
message, the caller starts the H.245 Conference control channel procedures with 
its Gatekeeper (the correct "h245Address" was retrieved from the CONNECT message 
itself). All the H.245 channel messages are then exchanged by the endpoints with 
their Gatekeeper (or Gatekeepers), it is the Gatekeeper (or "Gatekeeper 
network") which takes care of forwarding them up to the remote endpoint as 
foreseen by the Gatekeeper routed H.245 control model. The H.245 Conference 
control channel procedure scopes are the same detailed above, please refer to <A 
title=2.2.1.4.1.&nbsp; 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#sec-direct-sign-model">Direct 
signaling model section</A> for details.</P></DIV></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=sec-h323comm-phases>2.2.1.5.&nbsp;Communication 
Phases</H4></DIV></DIV>
<DIV></DIV>
<P>In a H.323 communication may be identified 5 different phases:</P>
<DIV class=itemizedlist>
<UL type=disc compact>
  <LI>Call set up;
  <LI>Initial communication and capability exchange;
  <LI>Establishment of audiovisual communication;
  <LI>Call services;
  <LI>Call termination.</LI></UL></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=h323callsetup>2.2.1.5.1.&nbsp;Call set up</H5></DIV></DIV>
<DIV></DIV>
<P>Recommendation H.225.0 defines the Call set up messages and procedures here 
detailed. The recommendation foresees that requests for bandwidth reservation 
should take place at the earliest possible phase. Differently from other 
protocols, there is no explicit synchronization between two endpoints during the 
call setup procedure (two endpoints can send a Setup message each other at 
exactly the same time). Actions to be taken when problems of synchronization 
during SET UP message exchange arise are resolved by the application itself; 
applications not supporting multiple simultaneous calls should issue busy signal 
when they have an outstanding SET UP message, while applications supporting 
multiple simultaneous call should issue a busy signal only to the same endpoint 
to which they sent an outstanding SET UP message. Moreover, an endpoint shall be 
capable of sending the ALERTING messages. Alerting has the meaning that the 
called party has been alerted of an incoming call ("phone ringing" in the 
language of the old telephony). Only the ultimate called endpoint shall 
originate the ALERTING message and only when the application has already alerted 
the user. If a Gateway is involved, the Gateway shall send ALERTING when it 
receives a ring indication from the Switched Circuit Network (SCN). The sending 
of an ALERTING message is not required if an endpoint can respond to a SET UP 
message with a CONNECT, CALL PROCEEDING, or RELEASE COMPLETE within 4 seconds. 
After successfully sending a SET UP message an endpoint can expect to receive 
either an ALERTING, CONNECT, CALL PROCEEDING, or RELEASE COMPLETE message within 
4 seconds after successful transmission. Finally, to maintain the consistency of 
the meaning of the CONNECT message between packet based networks and circuit 
switched networks, the CONNECT message should be sent only if it is certain that 
the capability exchange will successfully take place and a minimum level of 
communications can be performed.</P>
<P>The Call set up phase may have different realizations, basically we can 
identify different call set up:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>Basic call setup when neither endpoint are registered, in this call set up 
  the two endpoints communicate directly;