ch03s03.html

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

  interface is usually a low-cost solution.
  <LI><SPAN class=emphasis><EM>E&amp;M interfaces</EM></SPAN> - E&amp;M is 
  commonly explained as Ear and Mouth or recEive and transMit. Allows extension 
  dialing before the conversation begins. Requires a special interface card for 
  the PBX, but if the PBX is already equipped with this card, this can also be a 
  low-cost solution.
  <LI><SPAN class=emphasis><EM>E1/CAS trunk with MFC-R2 signaling </EM></SPAN>- 
  CAS (Channel Associated Signaling) exists in many variants that operate over 
  analog and digital interfaces. The advantage of a digital interface is its 
  ability to transfer the identification of the calling party, which is 
  important for detailed accounting. This is the first digital solution that was 
  used, which was later mostly replaced by ISDN interfaces. Requires special 
  interface cards on both sides of the interconnection, and it is a rather 
  expensive solution. 
  <LI><SPAN class=emphasis><EM>ISDN with DSS1 signaling</EM></SPAN> - In 
  addition to calling party identification, supplementary services are available 
  such as Call Waiting, Do not disturb, etc. Can be used with a BRI interface 
  (Basic Rate Interface, up to 2 simultaneous calls) or PRI interface (Primary 
  Rate Interface, up to 30 simultaneous calls). The interface card is usually 
  already in place on modern PBXs. The PRI interface is economically preferable 
  when more than 8 channels (4xBRI) are required.
  <LI><SPAN class=emphasis><EM>ISDN with QSIG signaling</EM></SPAN> - QSIG 
  signaling supports more supplementary services, such as Call completion, Path 
  replacements, etc. However, QSIG uses proprietary features of the PBX from 
  particular manufacturers and is therefore suitable only for corporate 
  networks, where IP telephony is used to interconnect PBXs in company branches. 
  </LI></UL></DIV></DIV>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=fullreplacement>3.3.3.&nbsp;Scenario 2c: Full replacement 
of legacy PBX systems</H3></DIV></DIV>
<DIV></DIV>
<P>It is only in greenfield situations, when building a telephony service from 
scratch, or when an existing PBX is fully depreciated, that IP Telephony can be 
considered as a complete replacement alternative to a traditional PBX. </P>
<DIV class=figure><A id=scen_allip>
<P class=title><B>Figure&nbsp;3.7.&nbsp;IP-Telephony fully replacing PBX</B></P>
<DIV class=mediaobject><IMG alt="IP-Telephony fully replacing PBX" 
src="ch03s03.files/scen_allip.png"></DIV></DIV>
<P>The design of an IPBX system involves a couple of choices.</P>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e2279>3.3.3.1.&nbsp;Intelligent vs. simple terminals 
</H4></DIV></DIV>
<DIV></DIV>
<P>IPBXes can support terminals in two ways: either through analogue ports that 
support analogue terminals, or through IP only. The latter implies that the 
terminals are intelligent devices, including an implementation of signaling 
functions. Since intelligence in IP phones is built-in anyway, these terminals 
are often equipped with interactive screens and other sophisticated functions. 
As a result, the equipment is expensive and requires to be provided with power, 
either externally or by Power-over-Ethernet. A feature that most of these 
advanced terminals support is pass-through of Ethernet packets, so that a single 
wall outlet can be used for both IP Telephony and computer data. </P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e2284>3.3.3.2.&nbsp;Signalling</H4></DIV></DIV>
<DIV></DIV>
<P>Though the choice among H.323, SIP and proprietary protocols seems a purely 
technical one, it has implications on the interoperability with future 
expansions, inter-department trunking and the deployment of new advanced 
features, like messaging, etc. It is wise to require that a supplier complies to 
at least one of the open standards.</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e2289>3.3.3.3.&nbsp;Inter-department 
trunking</H4></DIV></DIV>
<DIV></DIV>
<P>The choice of a full IP-based institutional voice architecture does not 
automatically lead to a specific solution for connecting geographically 
separated locations. The cookbook examines the options for this case in the <A 
title="3.2.&nbsp;Scenario 1: Long-distance least cost routing" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch03s02.html">Least-Cost 
Routing</A> section.</P>
<P>The inter-departmental architecture also involves a choice of whether to 
break out local calls at local PSTN trunks, or to centralize all PSTN trunking 
on one of the locations of the institution. This choice depends on the tariff 
structure that the public operator(s) offer for centralized break out, as well 
as the volume of calls that have a local public destination as compared to 
long-distance public and private destined calls.</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e2299>3.3.3.4.&nbsp;Legacy 
functionality</H4></DIV></DIV>
<DIV></DIV>
<P>Traditional PBXes have the advantage that long-recognized needs have been 
incorporated through decades of development in their functionality. These 
important features need to be implemented by the IP Telephony architecture as 
well, if it is to become a competitive solution. The most elementary of these 
are:</P>
<DIV class=itemizedlist>
<UL type=disc compact>
  <LI>Emergency call handling to public emergency numbers (911, 112 etc)
  <LI>Public dialplan routing (regular numbers, blocking/routing of 
  premiumnumbers etc)
  <LI>Integration with public wireless telephony
  <LI>Voice/data integration and call distribution for call center/help desk 
  department
  <LI>Support for beeper systems
  <LI>Support for private wireless telephony
  <LI>Support for elevator phones</LI></UL></DIV></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e2326>3.3.3.5.&nbsp;Wireless VoIP</H4></DIV></DIV>
<DIV></DIV>
<P>With at least three manufacturers currently presenting wireless IP terminals 
that can use IEEE 802.11b (Wi-Fi) wireless data communication, a new aspect for 
VoIP is emerging. Where DECT has a strong position in the wireless PBX market, 
it can be expected that institutions with Wi-Fi networks in place, will want to 
reuse this infrastructure for their wireless telephony network, obtaining 
similar consolidation advantages, as in the fixed IP telephony case. Wireless IP 
phones are equally intelligent as their fixed IP equivalents, but are different 
on the Ethernet level. The usual issues in wireless data communications are 
battery autonomy, portability, coverage, etc. Current developments show that 
manufacturers of public network mobile phones like GSM are planning to include 
Wireless VoIP into their terminals. This would enable seamless roaming from 
public mobile telephony networks to the campus wireless environment, potentially 
reducing costs when calling locally on campus.</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e2331>3.3.3.6.&nbsp;Issues</H4></DIV></DIV>
<DIV></DIV>
<P>Since the field of IPBXes is rapidly emerging, many features that are known 
in the traditional PBXes are quickly adopted. Additionaly, new issues arise as 
data networks develop. An example is the introduction of network access control 
by IEEE 802.1X. This standard forces equipment to first authenticate at a RADIUS 
server before accessing the network. All equipment on 802.1X enabled network 
ports should be 802.1X enabled as well. With the adoption of 802.1X, the vendors 
are announcing terminals that support this standard as well.</P>
<P>A similar situation holds for VLANs. In case a network administrator chooses 
to put IP telephones in a different VLAN from PC (groups) and the IP telephones 
are in pass-through configuration, they should support VLAN trunking. This 
feature is also appearing in the market.</P></DIV></DIV></DIV>
<DIV class=navfooter>
<TABLE width="100%" summary="Navigation footer">
  <TBODY>
  <TR>
    <TD align=left width="40%"><A accessKey=p 
      href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch03s02.html">Prev</A>&nbsp;</TD>
    <TD align=middle width="20%"><A accessKey=u 
      href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch03.html">Up</A></TD>
    <TD align=right width="40%">&nbsp;<A accessKey=n 
      href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch03s04.html">Next</A></TD></TR>
  <TR>
    <TD vAlign=top align=left width="40%">3.2.&nbsp;Scenario 1: Long-distance 
      least cost routing&nbsp;</TD>
    <TD align=middle width="20%"><A accessKey=h 
      href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/index.html">Home</A></TD>
    <TD vAlign=top align=right width="40%">&nbsp;3.4.&nbsp;Scenario 3: 
      Integration of VoIP and 
Videoconferencing</TD></TR></TBODY></TABLE></DIV></A></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></BODY></HTML>