📄 ch04s04.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0077)http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s04.html -->
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><HTML
xmlns="http://www.w3.org/1999/xhtml"><HEAD><TITLE>4.4.燛xamples</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><LINK
href="ch04s04.files/terena.css" type=text/css rel=stylesheet>
<META content="MSHTML 6.00.2800.1106" name=GENERATOR><LINK
title="IP Telephony Cookbook" href="index.html" rel=home><LINK
title="Chapter 4. Setting up basic services" href="ch04.html"
rel=up><LINK title=4.3. Authentication href="ch04s03.html"
rel=previous><LINK title="4.5. Setting up H.323 services"
href="ch04s05.html" rel=next><LINK title=Chapter 1. Introduction
href="ch01.html" rel=chapter><LINK
title="Chapter 2. Technology Background" href="ch02.html"
rel=chapter><LINK title="Chapter 3. IP Telephony Scenarios"
href="ch03.html" rel=chapter><LINK
title="Chapter 4. Setting up basic services" href="ch04.html"
rel=chapter><LINK title="Chapter 5. Setting up Advanced Services"
href="ch05.html" rel=chapter><LINK
title="Chapter 6. Setting up Value-Added Services" href="ch06.html"
rel=chapter><LINK title="Chapter 7. Global telephony integration"
href="ch07.html" rel=chapter><LINK
title="Chapter 8. Regulatory / Legal considerations" href="ch08.html"
rel=chapter><LINK title="Appendix A. European IP Telephony Projects"
href="apa.html" rel=appendix><LINK
title="Appendix B. IP Telephony Hardware/Software" href="apb.html"
rel=appendix><LINK title=Glossary href="go01.html" rel=glossary><LINK
title="4.4.1. Example 1: Simple, use IP telephony like legacy telephony"
href="ch04s04.html#d0e3301" rel=subsection><LINK
title="4.4.2. Example 2: Complex, full featured"
href="ch04s04.html#d0e3350" rel=subsection></HEAD>
<BODY>
<DIV class=navheader>
<TABLE width="100%" summary="Navigation header">
<TBODY>
<TR>
<TH align=middle colSpan=3>4.4. Examples</TH></TR>
<TR>
<TD align=left width="20%"><A accessKey=p
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s03.html">Prev</A> </TD>
<TH align=middle width="60%">Chapter 4. Setting up basic
services</TH>
<TD align=right width="20%"> <A accessKey=n
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s05.html">Next</A></TD></TR></TBODY></TABLE></DIV>
<DIV class=sect1 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H2 class=title style="CLEAR: both"><A
id=d0e3296>4.4. Examples</H2></DIV></DIV>
<DIV></DIV>
<P>This section lists some examples on how a zone setup could look like
depending on the requirements.</P>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=d0e3301>4.4.1. Example 1: Simple, use IP telephony
like legacy telephony</H3></DIV></DIV>
<DIV></DIV>
<DIV class=segmentedlist>
<P><B>Assumption: </B>An institution currently using a PBX with internal numbers
of four digits length. There telephone numbers from 6000 to 6999 are available
for IP telephony. There are no requirements regarding authentication. Because
only calls into the PSTN shall be billed the PBX is the only place where billing
shall take place. There are no special requirements regarding availability and
there is no demand for IP telephony research.</P>
<P><B>Components: </B>Any kind of IP telephony server (H.323 gatekeeper or <SPAN
class=acronym>SIP</SPAN> proxy)- even productions using proprietary protocols
are usable. The gateway must be able to translate signaling between the protocol
that the server uses and the PBX. The protocol to the PBX usually uses one of
the protocols described in <A title="5.1.1. Gateway interfaces"
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch05.html#gw-interfaces">Section 5.1.1</A>.</P>
<P><B>Structure: </B>See <A
title="Figure 4.11. Simple IP telephony example."
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s04.html#ch4-example1">Figure 4.11</A>.
</P>
<P><B>Call Routing: </B>The PBX is configured to route every call to a number
starting with 6 to the gateway. The IP telephony server either has the gateway
as a default route for unknown/unregistered targets or is configured to route
every call to a number that does not start with 6 to the gateway too. The
gateway can either be configured to always route a call from one side to the
other or needs to be get a configuration similar to the IP telephony server.</P>
<P><B>Authentication: </B>Authentication on the IP side is either done using the
H.323 or <SPAN class=acronym>SIP</SPAN> authentication mechanisms or can be done
on the link layer. In the latter case a telephone number is bound to a specific
port or MAC address.</P>
<P><B>Billing: </B>The billing mechanisms that were already in use for PBX calls
can be used for IP telephony as well as all outgoing calls pass the
PBX.</P></DIV>
<DIV class=figure><A id=ch4-example1>
<P class=title><B>Figure 4.11. Simple IP telephony example.</B></P>
<DIV class=mediaobject align=center><IMG alt="Simple IP telephony example."
src="ch04s04.files/Example1.png" align=middle></DIV></DIV>
<P>The described solution allows an easy integration of IP telephony into a PBX
world. The gain of this solution compared to just more legacy phones is that IP
telephony allows more flexibility regarding the endpoints - allowing hard- and
software phones that may even be connected by wireless LAN (depending on the
authentication mechanisms used).</P>
<P>The problems of this solution are that it heavily relies on the PBX that
remains the core element of the infrastructure. If once there is demand for more
IP telephony accounts more number blocks must be available - to free such a
block requires giving legacy phone users to numbers. The solution also is not
prepared to make use of the Internet for long distance calls or select an IP
telephony service provider.</P></DIV>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=d0e3350>4.4.2. Example 2: Complex, full
featured</H3></DIV></DIV>
<DIV></DIV>
<DIV class=segmentedlist>
<P><B>Assumption: </B>A university with multiple locations, a shared
unstructured dialing space and need for borth <SPAN class=acronym>SIP</SPAN> and
H.323. It should be possible to test new IP telephony server firmwares before
installing them in the production network. To stretch this idea further an
additional requirement is that the IP telephony system has to be divided into
three <SPAN class=emphasis><EM>logical networks</EM></SPAN>: a production
network (the telephone system for 90% of all employees), a <I
class=firstterm>testing network</I> to run new firmware versions before
deploying them in the production network, and a <I class=firstterm>research
network</I> for IP telephony related research work. Obviously the networks
differ in reliability - having high reliability requirements in the production
network and nearly none in the research network. A daring user might decide to
participate in the testing network - without changing his phone number or using
a second phone.</P>
<P><B>Components: </B>To be able to do IP telephony research on standardized
protocols the research network runs either a H.323 gatekeeper or a <SPAN
class=acronym>SIP</SPAN> proxy. The production network runs a redundant server
that supports H.323 as well as <SPAN class=acronym>SIP</SPAN>. The testing
network uses the same server model - without redundancy. The gateway is either a
H.323/PSTN or <SPAN class=acronym>SIP</SPAN>/PSTN gateway. A RADIUS server
stores all valid users (names and numbers) along with their password. The
billing records can be written by the PBX and the IP telephony server - e.g.
using a SQL server.</P>
<P><B>Structure: </B><A
title="Figure 4.12. Example of a multi-server IP telephony zone"
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s04.html#ch4-example2">Figure 4.12</A>
describes how the servers are organized. There is a H.323 gatekeeper or <SPAN
class=acronym>SIP</SPAN> proxy for each logical network. Which logical network
an endpoint belongs to is simply defined by which server it is registered with
and is independent from the physical network structure. To participate in
testing of new features, the endpoint of the user need only be configured to
register on the server using the new firmware version.</P>
<P><B>Call Routing: </B>Routing decisions are either made using a shared
database (see <A
title="4.1.1.1.3. Per number routing, more than one server"
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.html#indivrout2">Section 4.1.1.1.3</A>)
or by routing calls to external targets via the server in the production network
to the PBX gateway. A server whose user dials an internal number tries other
locally registered endpoints first, before asking the peer server using the LRQ
mechanism of H.323.</P>
<P><B>Authentication: </B>To achieve authentication the mechanisms described in
<A title=4.3. Authentication
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s03.html">Section 4.3</A>
are used. The authentication backend is provided by a RADIUS server that stores
logins and passwords.</P>
<P><B>Billing: </B>Because external calls are routed through the PBX the
existing billing solution may be used. If the production network gatekeeper is
able to write billing records as well, it will become the production billing
server when sometime in the future the university selects an IP telephony
provider instead a PSTN Telco.</P></DIV>
<DIV class=figure><A id=ch4-example2>
<P class=title><B>Figure 4.12. Example of a multi-server IP telephony
zone</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="Example of a multi-server IP telephony zone"
src="ch04s04.files/Example2.png" width=496
align=middle></TD></TR></TBODY></TABLE></DIV></DIV>
<P>This scenario is quite complex, but it is the most flexible. It allows
individual users to move from the legacy telephony world to IP telephony,
eventually reducing the PBX to a minimal state. It is made robust by using
redundant servers where necessary. Because routing decisions are made on the IP
side, this solution qualifies for communication with external targets via the
Internet or through use of an IP telephony provider. The decision for open
standards (<SPAN class=acronym>SIP</SPAN>, H.323) allows soace for research
initiatives and prevents dependencies on specific vendors.</P>
<P>All these possibilities come at a price. Several servers must be bought and
the complex structure makes it harder to trace errors.</P></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/ch04s03.html">Prev</A> </TD>
<TD align=middle width="20%"><A accessKey=u
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.html">Up</A></TD>
<TD align=right width="40%"> <A accessKey=n
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s05.html">Next</A></TD></TR>
<TR>
<TD vAlign=top align=left width="40%">4.3. Authentication </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%"> 4.5. Setting up H.323
services</TD></TR></TBODY></TABLE></DIV></A></DIV></DIV></DIV></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -