ch02s02.html

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

    <SPAN class=acronym>Multiple Calls</SPAN> this enhancement shall reduce the 
    need to open new TCP connections. After the last call has ended the endpoint 
    may decide to maintain the TCP connection to provide a better call setup 
    time for the next call.</LI></UL></DIV>
  <P>Primary use of both enhancements is at the communication between servers 
  (Gatekeeper, MCU) or gateways. While in theory both mechanisms were possible 
  before, beginning with H.323v3 the messages contained fields to indicate 
  support for the mechanisms.</P>
  <LI>
  <P><SPAN class=emphasis><EM>H.245 Conference Control</EM></SPAN> -- The 
  conference control channel is used to establish and control two party calls 
  (as well as multiparty conferences). Its functionality includes determining 
  possible modes for media exchange (e.g. select media encoding formats both 
  parties understand) and configuring actual media streams (including exchanging 
  transport addresses to send media streams to and receive them from). H.245 can 
  be used to carry user input (such as DTMF), it also enables confidential media 
  exchange, defines syntax and semantics for multipoint conference operation 
  (see below). Finally, it provides a number of maintenance messages. Also this 
  logical channel may optionally run through one or more gatekeeper or directly 
  between caller and called party (please refer to the <A 
  title="2.2.1.4.&nbsp;Signaling models" 
  href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#sec-signaling-models">Signaling 
  models section</A> for details).</P>
  <P>It should be noted that H.245 is a legacy protocol inherited from the 
  collective work on multimedia conferencing over ATM, PSTN, and other networks. 
  Hence it carries a lot of fields and procedures that do not apply to H.323 but 
  make the protocol specification quite heavyweight.</P>
  <P><SPAN class=emphasis><EM>Optimizations:</EM></SPAN> The conference control 
  channel is also subject to optimizations. Per default it is transported over 
  an exclusive TCP connection but it may also be tunneled within the signaling 
  connection (<SPAN class=acronym>H.245 tunneling</SPAN>). Other optimizations 
  deal with the call setup time. The last chance to start a H.245 channel is on 
  receipt of the CONNECT message which implies that the first seconds after the 
  user accepted the call no media is transmitted. H.245 may also start parallel 
  to the setup of the H.225 call signaling, which is not really a new feature 
  but another way of dealing with H.245. Vendors often call this <SPAN 
  class=emphasis><EM>Early connect</EM></SPAN> or <SPAN class=emphasis><EM>Early 
  media</EM></SPAN>. Since H.323 V2 it is possible to start a call using a less 
  powerful but sufficient capability exchange by simply offering possible media 
  channels that just have to be accepted. This procedure is called <SPAN 
  class=emphasis><EM>FastConnect</EM></SPAN> or <SPAN 
  class=emphasis><EM>FastStart</EM></SPAN>, requires less round-trips and is 
  transported over the H.225 channel. After the FastConnect procedure is 
  finished or when it fails the normal H.245 procedures start. 
</P></LI></UL></DIV>
<P>A number of extensions to H.323 include mechanisms for more efficient call 
setup (H.323 Annex E) and reduction of protocol overhead e.g. for simple 
telephones (SETs, simple endpoint types, H.323 Annex F).</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=discreg>2.2.1.3.&nbsp;Gatekeeper Discovery and 
Registration</H4></DIV></DIV>
<DIV></DIV>
<P>A H.323 endpoint usually registers with a gatekeeper that provides basic 
services like address resolution for calling the other endpoints. There are two 
possibilities for an endpoint to find its gatekeeper:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI><SPAN class=emphasis><EM>Multicast discovery</EM></SPAN> - The endpoint 
  sends a gatekeeper request (GRQ) to a well known multicast address 
  (224.0.1.41) and port (1718). Receiving gatekeepers may confirm their 
  responsibility for the endpoint (GCF) or ignore the request.
  <LI><SPAN class=emphasis><EM>Configuration</EM></SPAN> - The endpoint knows 
  the IP address of the gatekeeper by manual configuration. While there is no 
  need that a gatekeeper request (GRQ) be sent to the preconfigured gatekeeper 
  some products need this protocol step. If a gatekeeper receives a GRQ via 
  unicast it must either confirm (GCF) the request or reject it 
(GRJ).</LI></UL></DIV>
<P>When trying to discover the gatekeeper via multicast an endpoint may request 
any gatekeeper or specify the request by adding a <SPAN class=acronym>Gatekeeper 
identifier</SPAN> to the request. Only the gatekeeper that has the requested 
identifier may reply positively. (see figure <A 
title="Figure&nbsp;2.3.&nbsp;Discovery and registration process" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#fig-h323reg1">Figure&nbsp;2.3</A>)</P>
<DIV class=figure><A id=fig-h323reg1>
<P class=title><B>Figure&nbsp;2.3.&nbsp;Discovery and registration 
process</B></P>
<DIV class=mediaobject align=center><IMG 
alt="Picture showing the message flow of gatekeeper discovery&#10;&#9;&#9;and registration." 
src="ch02s02.files/h323reg1.png" align=middle></DIV></DIV>
<P>After the endpoint discovers the location of the gatekeeper it tries to 
register itself (RRQ). Such a registration includes (among other 
information):</P>
<DIV class=itemizedlist>
<UL type=disc compact>
  <LI><SPAN class=emphasis><EM>The addresses of the endpoint</EM></SPAN> - For a 
  terminal this may be the user ids or telephone numbers. An endpoint may have 
  more than one address. In theory it is possible that addresses belong to 
  different users to enable multiple users to share a single phone - in practice 
  this depends on the phones and gatekeeper implementation.
  <LI><SPAN class=emphasis><EM>Prefixes</EM></SPAN> - If the registering 
  endpoint is a gateway it may register number prefixes instead of addresses.
  <LI><SPAN class=emphasis><EM>Time to live</EM></SPAN> - An endpoint may 
  request how long the registration shall last. This value can be overwritten by 
  gatekeeper policies.</LI></UL></DIV>
<P>The gatekeeper checks the requested registration information and confirms the 
(possibly modified) values (RCF). It may also reject a registration request 
because of e.g. invalid addresses. In case of a confirmation the gatekeeper 
assigns a unique identifier to the endpoint, which shall be used in subsequent 
requests to indicate that the endpoint is still registered.</P>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=address_reg>2.2.1.3.1.&nbsp;Addresses and 
registrations</H5></DIV></DIV>
<DIV></DIV>
<P>H.323 defines and utilizes several address types. The one most commonly used 
and derived from the PSTN world is the <I class=firstterm>Dialed digit</I> 
address that is defined as a number dialed by the endpoint. It does not include 
further information (e.g. about the dial plan) and needs to be interpreted by 
the server. The server might convert the dialed number into a <I 
class=firstterm>Party Number</I> that includes information about the type of 
number and the dialplan.</P>
<P>To provide alphanumeric or name dialing H.323 supports <I 
class=firstterm>H.323-IDs</I> that represent either usernames or e-mail like 
addresses, or the more general approach of <I class=firstterm>URL-ID</I> which 
represent any kind of URL.</P>
<P>Unlike <SPAN class=acronym>SIP</SPAN> addresses, H.323 address can be only 
registered by one endpoint (per zone) so a call to that address only resolves to 
a single endpoint. To call multiple destinations "simultaneously" in H.323 
requires a gatekeeper that actively maps a single address to multiple different 
addresses and tries to contact them in sequence is required..</P></DIV>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H5 class=title><A id=d0e579>2.2.1.3.2.&nbsp;Updating 
registrations</H5></DIV></DIV>
<DIV></DIV>
<P>A registration expires after a defined time and must therefore be refreshed 
i.e. kept alive by subsequent registrations which include the previsouly 
assigned endpoint identifier. To reduce the registration overhead of regular 
registrations H.323 supports <SPAN class=acronym>KeepAlive</SPAN> registrations 
that contain just the previously assigned endpoint identifier. Of course these 
registrations may only be sent if the registration information are 
unchanged.</P>
<P>Endpoints requesting the registration of large numbers of addresses would 
exceed the size of a UDP packet, so H.323 version4 supports <SPAN 
class=emphasis><EM>Additive Registration</EM></SPAN>, a mechanism that allows an 
endpoint to send multiple registration requests (RRQ) in which the addresses 
don't replace existing registrations but are submitted in addition to 
them.</P></DIV></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=sec-signaling-models>2.2.1.4.&nbsp;Signaling 
models</H4></DIV></DIV>
<DIV></DIV>
<P>The call signaling messages and the H.245 control messages may be exchanged 
either end-to-end between caller and called party or through a gatekeeper. 
Depending on the role the gatekeeper plays in the call signaling and in the 
H.245 signaling the H.323 specification foresees three different types of 
signaling models:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI>Direct signaling, with this signaling model only H.225.0 RAS messages are 
  routed through the Gatekeeper while the other logical channel messages are 
  directly exchanged between the two endpoints;
  <LI>Gatekeeper routed call signaling, with this signaling model H.225.0 RAS 
  and H.225.0 Call signaling messages are routed through the Gatekeeper while 
  the H.245 Conference control messages are directly exchanged between the two 
  endpoints;
  <LI>Gatekeeper routed H.245 control, H.225.0 RAS and H.225.0 Call signaling an 
  H.245 Conference control messages are routed through the Gatekeeper and only 
  the media streams are directly exchanged between the two 
endpoints.</LI></UL></DIV>
<P>In the following sub-sections we are going to detail each signaling model. 
The figures reported in this section apply both to the use of a single 
Gatekeeper and to the use of a "Gatekeeper network". Since the signaling model 
is decided by the endpoint's Gatekeeper configuration and apply to all the 
messages such Gatekeeper handles, the extensions to the multiple Gatekeeper case 
is straightforward (simply apply the definition of the signaling model described 
in the itemized list above to each Gatekeeper involved) except for the location 
of zone external targets (described later in <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>); we decided not to report those message 
exchange in any of this section figures as it is intended to remain bounded in 
the ellipse where the H.323 Gatekeeper is depicted and it is described in the <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>. Please note that there is no indication about 
the call termination in each signaling model sub-section, please refer to <A 
title="2.2.1.5.&nbsp;Communication Phases" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#sec-h323comm-phases">Communication 
phases section</A> for details.</P>
<DIV class=sect4 lang=en>
<DIV class=titlepage>
<DIV>
<DIV></DIV>
<P>The <SPAN class=emphasis><EM>Direct signaling model</EM></SPAN> is depicted 
in <A title="Figure&nbsp;2.4.&nbsp;Direct signaling model" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#direct-model">Figure&nbsp;2.4</A>. 
In this model the H.225.0 Call signaling and H.245 Conference control messages 
are exchanged directly between the call terminals. As shown in the figure, the 
communication starts with an ARQ (Admission ReQuest) message sent by the caller 
(which may be either a Terminal or a Gateway) to the 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), if an ARJ is issued the call is 
terminated. After this first step the Call signaling part of the call begins 
with the transmission of the SET UP message from the caller to the called party. 
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 Direct signaling model it 
is the address of the destination endpoint. Upon receiving the SET UP message 
the called party starts its H.225.0 RAS procedure with the Gatekeeper, if