ch02s02.html

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

shall be explained here.</P>
<P>A gatekeeper may explicitly request the resolution of an address from other 
gatekeepers. On receipt of an request to call an address that the gatekeeper has 
no registration, it can send out a location request (LRQ) to other gatekeepers 
(see figure <A 
title="Figure&nbsp;2.9.&nbsp;External address resolution using LRQs" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#fig-h323lrq1">Figure&nbsp;2.9</A>). 
The receiving gatekeeper - assuming it knows the address - will reply with the 
<I class=firstterm>Transport Service Access Point</I> (a combination of IP 
address and portnumber) of either the requested address or its own call 
signaling TSAP.</P>
<DIV class=figure><A id=fig-h323lrq1>
<P class=title><B>Figure&nbsp;2.9.&nbsp;External address resolution using 
LRQs</B></P>
<DIV class=mediaobject align=center><IMG 
alt="An picture showing the message flow of an endpoint&#10;&#9;&#9;initiating an ARQ, resulting in a LRQ/LCF between to&#10;&#9;&#9;gatekeepers, an ACF reply and the start of the call between to endpoints." 
src="ch02s02.files/h323lrq1.png" align=middle></DIV></DIV>
<P>A location request can be sent via Unicast or Multicast. If sent via 
Multicast, only the gatekeeper that can resolve the address shall reply. If a 
gatekeeper receives a unicast LRQ, it shall either confirm or reject the 
request.</P>
<P>This mechanism can be used to have a list of peer gatekeeper to ask in 
parallel or sequentially. It is also possible to assign a domain suffix or 
number prefix to each peer so that an address with a matching number prefix of a 
neighbouring institution will result in a request to the gatekeeper of that 
institution. By defining default peers one could also build a hierarchy of 
gatekeepers (Again, see <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> 
for further details.)</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e893>2.2.1.7.&nbsp;Sample Call Scenario</H4></DIV></DIV>
<DIV></DIV>
<P><A title="Figure&nbsp;2.10.&nbsp;Sample H.323 Call Setup Scenario" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch02s02.html#fig-h323example1">Figure&nbsp;2.10</A> 
depicts an example of an inter-zone call setup using H.323 with one gatekeeper 
(A) using direct signaling while the other uses routed signaling. The caller in 
zone A contacts its gatekeeper to ask for permission to call the called party in 
zone B (1). Gatekeeper of zone A confirms this request and provides the caller 
with the address of zone B's gatekeeper (2).1 The caller establishes a call 
signaling channel (and subsequently / in parallel the conference control 
channel) to the gatekeeper of zone B (3), who determines the location of the 
called party and forwards the request to the called party (4).</P>
<DIV class=figure><A id=fig-h323example1>
<P class=title><B>Figure&nbsp;2.10.&nbsp;Sample H.323 Call Setup 
Scenario</B></P>
<DIV class=mediaobject align=center><IMG 
alt="Picture showing the signaling flow of H.323 messages in a&#10;&#9;      simple inter-zone call." 
src="ch02s02.files/h323example1.png" align=middle></DIV></DIV>
<P>The called party explicitly confirms with its gatekeeper that it is allowed 
to accept the call (5, 6) and, if so, alerts the recipient of the call, returns 
an alerting indication and (once the receiving user picks up the call) 
eventually an indication of successful connection setup back to the caller (7, 
8). In (parallel to) this exchange, capability negotiation and media stream 
configuration take place. When the setup has completed, both parties start 
sending media streams directly to each other.</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e912>2.2.1.8.&nbsp;Additional (Call) 
Services</H4></DIV></DIV>
<DIV></DIV>
<P>It is well known from our daily interaction with PBXes, that telephony 
service comprises far more than just call setup and teardown: n-way conferencing 
and various supplementary services (such as call transfer, call waiting, etc.) 
are available. Similar features - at least the more commonly known and used ones 
- need to be provided by IP telephony systems as well to be accepted by 
customers. Additional call services in H.323 can be grouped into three 
categories:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI><SPAN class=emphasis><EM>Conferencing</EM></SPAN> -- H.323 inherently 
  supports multipoint tightly-coupled conferencing - i.e. conferences with 
  access control, optional support for conference chairs, and close 
  synchronization of conference state among all participants - from the outset: 
  through the concept of a Multipoint Controller and an optional Multipoint 
  Processor. While control is centralized in the MC, in theory data exchange may 
  be either via IP multicast, multi-unicast (i.e. peer-wise fan-out between 
  endpoints without MP), or through an MP. (Practically there seems to be no 
  H.323 equipment supporting media multicast.) The distribution mode may be 
  selected per-media and per endpoint peer and is controlled by the MC.
  <LI><SPAN class=emphasis><EM>"Broadcast conferencing"</EM></SPAN> -- H.323 
  also provides an interface to support large loosely-coupled conferences as are 
  frequently used in the Mbone to multicast seminars, events, etc. In this case, 
  the MC defines session description (using the Session Description Protocol, 
  <SPAN class=acronym>SDP</SPAN>, see below) for the H.323 media sessions (which 
  have to operate using multicast) and announces this description by some means 
  (e.g. the Session Announcement Protocol, <SPAN class=acronym>SAP</SPAN>). 
  Details are defined in ITU-T H.332.
  <LI><SPAN class=emphasis><EM>Supplementary Services</EM></SPAN> -- H.323 
  provides a variety of supplementary services with additional ones continuously 
  being defined. While some services can be accomplished using the basic H.323 
  specifications, the H.450.x Recommendations define a framework (derived from 
  QSIG, the ECMA/ISO/ETSI standard for supplementary service signaling in PBXes) 
  and a number of services (call transfer, call diversion, call hold, call park 
  &amp; pickup, call waiting, message waiting indication, call 
completion).</LI></UL></DIV>
<P>Further extensions for supplementary services and other functional 
enhancements are on the way. In particular, an HTTP-based extension framework is 
being defined at the time of writing to enable rapid introduction of new 
services without the need for standardization.</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e941>2.2.1.9.&nbsp;H.235 Security</H4></DIV></DIV>
<DIV></DIV>
<P>The H.235 recommendation defines elements of security for H.323. This 
includes:</P>
<DIV class=itemizedlist>
<UL type=disc>
  <LI><SPAN class=emphasis><EM>Authentication</EM></SPAN><BR 
  xmlns="http://www.w3.org/TR/xhtml1/transitional">Authentication can be 
  achieved by using a shared secret (password) or digital signatures. The RAS 
  messages include a token that was generated using either the shared secret or 
  the signature. A receiving entity authenticate the sender by comparing the 
  received token with a self generated token.
  <LI><SPAN class=emphasis><EM>Message Integrity</EM></SPAN><BR 
  xmlns="http://www.w3.org/TR/xhtml1/transitional">Integrity is achieved by 
  generating a password based checksum over the message.
  <LI><SPAN class=emphasis><EM>Privacy</EM></SPAN><BR 
  xmlns="http://www.w3.org/TR/xhtml1/transitional">Mechanisms are provided to 
  setup encryption on the media streams. They must be used in conjunction with 
  the H.245 protocol and employ DES, Triple DES or RC2 - the use of SRTP is not 
  supported yet (in H.235v2).</LI></UL></DIV>
<P>Those mechanisms are grouped into the so called <SPAN 
class=emphasis><EM>Security Profiles</EM></SPAN>, where the <I 
class=firstterm>Baseline Security Profile</I> provides authentication and 
message integrity making it suitable for subscription based environments and the 
<I class=firstterm>Voice Encryption Profile</I> that provides confidential 
end-to-end media channels.</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e976>2.2.1.10.&nbsp;Protocol Profiles</H4></DIV></DIV>
<DIV></DIV>
<P>H.323 has its origin - as mentioned before - in the area of multimedia 
conferencing. This implies that a vast number of options are available which are 
not necessary for simply providing telephony services. The TIPHON project of the 
European Telecommunication Standards Institute (ETSI) has defined a Telephony 
Profile for H.323 that specifies which combination of options should be 
implemented.</P>
<P>Similarly, H.323 contains a security framework (H.235) that describes a 
collection of algorithms and protocol mechanisms but lacks - because of 
international political constraints - a precise specification of a mandatory 
baseline. This is accounted for by the ETSI TIPHON security profile: this 
specification fills in the gaps and provides the foundation for inter operable 
implementations.</P>
<P>In summary, it can be said that the H.323 family of standards provides a 
mature basis for commercial products in the field of IP telephony. While the 
details of the protocol are often dominated by their legacy from various earlier 
ITU protocols, there is an active effort to profile and simplify the protocol to 
reduce the complexity.</P></DIV></DIV>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=sec-sip>2.2.2.&nbsp;SIP</H3></DIV></DIV>
<DIV></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=sec-purpose-of-sip>2.2.2.1.&nbsp;Purpose of <SPAN 
class=acronym>SIP</SPAN></H4></DIV></DIV>
<DIV></DIV>
<P><SPAN class=acronym>SIP</SPAN> stands for Session Initiation Protocol. It is 
an application-layer control protocol which has been developed and designed 
within the <A href="http://www.ietf.org/" target=_top>IETF</A>. The protocol has 
been designed with easy implementation, good scalability, and flexibility in 
mind. </P>
<P>The specification is available in form of several <SPAN 
class=abbrev>RFCs</SPAN>, the most important one is <A 
href="http://www.ietf.org/rfc/rfc3261.txt" target=_top>RFC3261</A> which 
contains the core protocol specification. The protocol is used for creating, 
modifying, and terminating sessions with one or more participants. By sessions 
we understand a set of senders and receivers that communicate and the state kept 
in those senders and receivers during the communication. Examples of a session 
can include Internet telephone calls, distribution of multimedia, multimedia 
conferences, distributed computer games, etc. </P>
<P><SPAN class=acronym>SIP</SPAN> is not the only protocol that the 
communicating devices will need. It is not meant to be a general purpose 
protocol. Purpose of <SPAN class=acronym>SIP</SPAN> is just to make the 
communication possible, the communication itself must be achieved by another 
means (and possibly another protocol). Two protocols that are most often used 
along with <SPAN class=acronym>SIP</SPAN> are <SPAN class=acronym>RTP</SPAN> and 
<SPAN class=acronym>SDP</SPAN>. <SPAN class=acronym>RTP</SPAN> protocol is used 
to carry the real-time multimedia data (including audio, video, and text), the 
protocol makes it possible to encode and split the data into packets and 
transport such packets over the Internet. Another important protocol is <SPAN 
class=acronym>SDP</SPAN>--Session Description Protocol, which is used to 
describe and encode capabilities of session participants. Such a description is 
then used to negotiate the characteristics of the session so that all the 
devices can participate (that includes, for example, negotiation of codecs used 
to encode media so all the participants will be able to decode it, negotiation 
of transport protocol used and so on). </P>
<P><SPAN class=acronym>SIP</SPAN> has been designed in conformance with the 
Internet model. It is an end-to-end oriented signaling protocol which means, 
that all the logic is stored in end devices (except routing of <SPAN 
class=acronym>SIP</SPAN> messages). State is also stored in end-devices only, 
there is no single point of failure and networks designed this way scale well. 
The price that we have to pay for the distributiveness and scalability is higher 
message