📄 ch04s02.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/ch04s02.html -->
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><HTML
xmlns="http://www.w3.org/1999/xhtml"><HEAD><TITLE>4.2.燚ialplans</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><LINK
href="ch04s02.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="Chapter 4. Setting up basic services"
href="ch04.html" rel=previous><LINK title=4.3. Authentication
href="ch04s03.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></HEAD>
<BODY>
<DIV class=navheader>
<TABLE width="100%" summary="Navigation header">
<TBODY>
<TR>
<TH align=middle colSpan=3>4.2. Dialplans</TH></TR>
<TR>
<TD align=left width="20%"><A accessKey=p
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.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/ch04s03.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=dialplan>4.2. Dialplans</H2></DIV></DIV>
<DIV></DIV>
<P>The previous sections already addressed issues regarding the dialplan that is
used. There is no ideal solution to address all different needs but just a
number of techniques to solve specific. This section addresses the most common
problems faced when dealing with dialplans.</P>
<DIV class=orderedlist>
<OL type=1>
<LI>
<P><SPAN class=emphasis><EM>IP telephony numberblocks</EM></SPAN></P>
<P>The general situation is that there is an already existing PBX dialplan and
IP telephony shall be integrated into this dialplan. If the existing dialplan
has a free number block then the first approach would be to give IP telephony
the whole block. This makes the configuration very simple because it allows
prefix based routing (see <A
title="4.1.1.1.1. Routing based on a number prefix"
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.html#prefrout">Section 4.1.1.1.1</A>).
The problem is that either only new telephone users get an IP telephone or
that every user who wants to use IP telephony gets a new phone number. So this
approach is not suitable for a seamless migration towards IP telephony</P>
<LI>
<P><SPAN class=emphasis><EM>IP telephony service prefix</EM></SPAN></P>
<P>Another solution is to define a prefix that has to be dialed to reach an IP
telephone. As mentioned before prefix routing is the easiest option to
configure. An IP telephony prefix would also allow a user changing from a
legacy phone to an IP telephony phone to keep his number modified in a way
that is easy to remember (e.g. if the internal number was 2972 and the prefix
for VoIP is 99 than the new number is 992972 - which applies for all
numbers).</P>
<P>On the other hand there must be a way to decide of a call that originates
on the IP side has an IP telephony target or a phone on the PBX. This can
again be realized with a service prefix for legacy phones or by making the PBX
the default route for targets that are not registered at the same server. This
must be carefully considered to avoid that a call from an IP phone to another
IP phone target that is not currently registered is routed back and forth
between IP telephony server and PBX.</P>
<P>The problem with this solution is that you have to know if the person you
want to call has an IP phone or not and this constitutes a number change which
still requires all business cards to be reprinted.</P>
<P>To avoid this number change to be "visible" the PBX might set up a mapping
table that maps outdated old addresses to the new addresses. So the PBX maps
the dialed 2972 to 992972 and routes the call to the IP world.</P>
<LI>
<P><SPAN class=emphasis><EM>Per number routing</EM></SPAN></P>
<P>The cleanest way to handle call routing is to perform routing decisions on
the individual number (see <A
title="4.1.1.1.2. Per number routing, one server"
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.html#indivrout">Section 4.1.1.1.2</A>).
The fact that a number belongs to an IP phone or PBX phone is fully
transparent to the user and no error-prone default routes are required. It is
also the solution that has the highest configuration and administration effort
because there are most probably at least two databases that must be kept
consistent. </P>
<LI>The call routing problem gets worse as soon as multiple call signaling
protocols are deployed in the IP world and no single server supporting all of
them at once (see <A
title="Figure 4.5. Per number routing with a) two or b) one gateways"
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04.html#fig-indivrout2">Figure 4.5</A>).
Every IP telephony server must be aware that a number that belongs to another
server must be routed to the gateway, or otherwise the gateway must be the
default route for unknown targets. In any case, calls for unknown targets land
on a gateway. Now the gateway needs to decide where to route a call. Because
it is desirable that gateways are dumb (to prevent having yet another place to
configure routing details) the gateway will hand the call to the PBX which
makes the final routing decision - which eventually means to hand the call to
another gateway (or back to the originating if there is only one
multi-protocol gateway).</LI></OL></DIV>
<P>All problems and solutions mentioned above are highly dependent on specific
products and the features they support, so unfortunately there can be no general
advice on how to implement dialplan migration.</P></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/ch04.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/ch04s03.html">Next</A></TD></TR>
<TR>
<TD vAlign=top align=left width="40%">Chapter 4. Setting up
basic services </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.3. Authentication</TD></TR></TBODY></TABLE></DIV></DIV></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -