Posted on 2009-10-12 19:00:00
Tags: Asterisk, Voice over IP
Recently I have been involved in the design and installation of a global VoIP telephone system and learned a few valuable lessons.
The call-flow design and requirements were as follows:
So far nothing spectacular, but the issues came when mapping calls on the network.
Normally people differentiate between internal and external calls by dialing the 0 (or 9 if you are stuck with an American based PABX, or 91 if you want to make a long distance call in the USA) before dialing the local number. After the 0, you more or less have captured a channel on the PRI and are able to call anything via that, local or national or international as long as you play via the rules of that PSTN. For example in Sydney, Australia: You can dial an eight digit local number, a ten digit local number or a ten digit national number. And if you prefix your call with a 0011, you end up on an international call.
On a distributed telephone system connected to various PSTNs, this will be a nightmare for the people to remember (0, 0011, 86 plus a string of numbers for China) which has to be translated by the PABX to +86 plus a string of numbers which has to be send to the PABX in China so it knows how to translate it back to the a China local number etc etc etc. Both a nightmare for the users and for the PABX maintainers, plus a nightmare for the travelling salesman.
So, instead of having a single prefix for an external line for a local or national call and an international call, let's split it: Prefix local or national calls with a 0 and make the international access an *. Yes, that's a * because it looks most like the international prefix +. So the PABX maintainers now know when to handle local calls and national calls.
The only tricky part is left over with the international calls, but it is less tricky than what it was. Instead of having to write a different parser for for each country to figure out when an international call is placed, they just check for the * prefix: No check of 0,0011 in Australia, an 9,011 in the USA, 0,00 in Europe, just check for the *. Next is to map of the next one, two or three numbers on the remote destination telephone system, which we just send their national call telephone number and wait for it to be connected.
So, if you have enough local offices, you will be able to call a lot of international telephone numbers for the cost of a national telephone call!
So no more 9,0011 1 415 123 4567 to call, just *1 415 123 4567! It will save money (It will be a cheap local call for the telephone system. Or a free call if the destination is a free number), it will reduce the number of buttons to press (9,0011 -> *) and it will prevent from making silly counting mistakes (missing 1 in the string of numbers to be pressed).
The whole system was implemented on the open source PABX Asterisk and a central monitoring / configuration server which kept track of which international prefixes needed to be forwarded to which telephone system. The implementation showed that its fail-safe design worked as expected when the office in Germany lost its internet connectivity for a three days and nobody complained that their calls to Germany didn't work anymore.
The overal telephone bill got reduced to 20% of the original cost, having the whole system paying for itself it as little as eleven months! (Although we still have three months to go :-)
So: Stop thinking about local calls and national calls and international calls, only think about local / national calls and international calls. Don't think about local international call prefixes, handle that on the PABX. International calls should be routed to remote PABXs which handle it locally. And only if a remote call can't be completed due to no free PRI channels or the remote PABX not being reachable, then handle it locally.
Posted on 2006-05-17 15:45:37, modified on 2006-05-17 15:54:45
Tags: Networking, Voice over IP, Cisco
The Cisco 7970 phones have a nifty feature: IP Phone Services. With it, you can access services on the internet (for example the stock value of CSCO). I have been asked to make some nifty features, but the phone has some funky HTTP client code.
This is how our services are configured in the Cisco Call Manager
Service URL: http://xml.barnet.com.au/echo.xml
And this it the HTTP request the phone sends
GET /echo.xml?demo=text HTTP/1.1. Host: 202.83.176.80:80. Connection: close. User-Agent: Allegro-Software-WebClient/4.20. Accept: x-CiscoIPPhone/*;version=3.0, text/*,image/png,*/*. Accept-Language: en. Accept-Charset: iso-8859-1. Cookie: ASPSESSIONIDQQSCDATD=IIHNKHFBLCNEAGLMFDIEEIGN.
So despite that the service has the full hostname, the Host line in the HTTP request contains an IP address. It's HTTP/1.1, so the Host line is required. RFC2616 says this about it:
14.23 Host
The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original
URI given by the user or referring resource (generally an HTTP URL,
as described in section 3.2.2). The Host field value MUST represent
the naming authority of the origin server or gateway given by the
original URL. This allows the origin server or gateway to
differentiate between internally-ambiguous URLs, such as the root "/"
URL of a server for multiple host names on a single IP address.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL). For
example, a request on the origin server for
<http://www.w3.org/pub/WWW/> would properly include:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI does not include an Internet host
name for the service being requested, then the Host header field MUST
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header
field.
Reading this, it looks like the IP address isn't even allowed there. But it should have been xml.barnet.com.au.
Posted on 2006-02-08 17:58:54, modified on 2006-02-08 21:05:06
Tags: Voice over IP, IPMUX
The IPMux are TDMoIP (Time Division Multiplexer over IP) devices, to transport E1/T1s over an IP network.
The IPMux 8 requires a female DB9 serial cable for it's console, which comes default on 19200 bps. You can see it booting. If your cable doesn't set the DCD, you will see still see it booting, but the IPMux won't accept the data from it. So if you wonder why the IPMuxes don't respond to your keystrokes, make sure you use the cable coming with it!
The IPMux 11 on the other hand requires a male DB9 serial cable, and it set to 115200 bps (note the two differences). If you try to define the timeslots on a bundle on it, and the current bundle is active, it will not accept any changes but will only say "ERROR", while not giving a hint of what the error is. After disabling the bundle, you can edit the timeslots.
Posted on 2005-09-13 14:08:27, modified on 2006-01-09 16:29:23
Tags: Happiness, Networking, Voice over IP, DHCP
64 bytes from 10.192.14.243: icmp_seq=25 ttl=127 time=0.532 ms 64 bytes from 10.192.14.243: icmp_seq=26 ttl=127 time=0.546 ms 64 bytes from 10.192.14.243: icmp_seq=27 ttl=127 time=0.564 ms 64 bytes from 10.192.14.243: icmp_seq=28 ttl=127 time=0.564 ms 64 bytes from 10.192.14.243: icmp_seq=29 ttl=127 time=0.570 ms 64 bytes from 0.0.0.0: icmp_seq=34 ttl=249 time=0.420 ms 64 bytes from 0.0.0.0: icmp_seq=35 ttl=249 time=1.807 ms 64 bytes from 0.0.0.0: icmp_seq=36 ttl=249 time=1.283 ms 64 bytes from 0.0.0.0: icmp_seq=37 ttl=249 time=1.036 ms 64 bytes from 0.0.0.0: icmp_seq=38 ttl=249 time=2.385 ms 64 bytes from 10.192.14.243: icmp_seq=39 ttl=249 time=0.764 ms 64 bytes from 10.192.14.243: icmp_seq=40 ttl=249 time=2.500 ms 64 bytes from 10.192.14.243: icmp_seq=41 ttl=249 time=0.507 ms 64 bytes from 10.192.14.243: icmp_seq=42 ttl=249 time=2.383 ms 64 bytes from 10.192.14.243: icmp_seq=43 ttl=249 time=0.612 ms 64 bytes from 10.192.14.243: icmp_seq=44 ttl=249 time=2.373 ms
Posted on 2005-08-19 10:59:03, modified on 2006-01-09 16:29:23
Tags: Voice over IP, DHCP, Alcatel
My Alcatel Premium e-reflexes voice-over-IP phone (best VoIP phone I've encountered, besides the fact that it is a non-SIP non-open protocol device) suddenly stopped worked after an upgrade from the ISC dhcpd 3.0.1r14 (yes yes) to version 3.0.3. The error was (very descriptive): Error 2.02
The cause was this change in the ISC DHCP server:
The siaddr field was being improperly set to the server-identifier when responding to DHCP messages. RFC2131 clarified the siaddr field as meaning the 'next server in the bootstrap process', eg a tftp server. The siaddr field is now left zeroed unless next-server is configured.
And according to the output of dhcpdump(1), that was indeed the case:
TIME: 10:30:13.000930 | TIME: 10:32:31.001894
IP: 192.168.1.1.67 (00:50:8b:b9:2 IP: 192.168.1.1.67 (00:50:8b:b9:2
OP: 2 (BOOTPREPLY) OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet) HTYPE: 1 (Ethernet)
HLEN: 6 HLEN: 6
HOPS: 0 HOPS: 0
XID: 7db4fce1 XID: 7db4fce1
SECS: 0 SECS: 0
FLAGS: 0 FLAGS: 0
CIADDR: 0.0.0.0 CIADDR: 0.0.0.0
YIADDR: 192.168.2.249 YIADDR: 192.168.2.249
SIADDR: 192.168.1.1 | SIADDR: 0.0.0.0
GIADDR: 0.0.0.0 GIADDR: 0.0.0.0
CHADDR: 00:80:9f:54:50:a3:00:00:00:00 CHADDR: 00:80:9f:54:50:a3:00:00:00:00
SNAME: . SNAME: .
FNAME: . FNAME: .
OPTION: 53 ( 1) DHCP message type OPTION: 53 ( 1) DHCP message type
OPTION: 54 ( 4) Server identifier OPTION: 54 ( 4) Server identifier
OPTION: 51 ( 4) IP address leasetim OPTION: 51 ( 4) IP address leasetim
OPTION: 1 ( 4) Subnet mask OPTION: 1 ( 4) Subnet mask
OPTION: 3 ( 4) Routers OPTION: 3 ( 4) Routers
OPTION: 43 ( 15) Vendor specific inf OPTION: 43 ( 15) Vendor specific inf
OPTION: 58 ( 4) T1 OPTION: 58 ( 4) T1
OPTION: 59 ( 4) T2 OPTION: 59 ( 4) T2
OPTION: 66 ( 13) TFTP server name OPTION: 66 ( 13) TFTP server name
OPTION: 67 ( 9) Bootfile name OPTION: 67 ( 9) Bootfile name
My dhcpd entry for these phones now looks like:
class "ipphone" {
match if option vendor-class-identifier = "alcatel.tsc-ip.0";
option dhcp-parameter-request-list 1,3,28,43,54,58,59,60,66,67;
option vendor-encapsulated-options "alcatel.a4400.0";
option tftp-server-name "10.192.13.10";
next-server 10.192.13.10;
option bootfile-name "ST_JAMES";
}and every phone here is happy again!
Posted on 2005-07-29 14:40:23, modified on 2006-01-09 16:29:23
Tags: Voice over IP, Cisco
A new day, a new toy... except this is one which doesn't want to buzz.
The ATA can be called, and it rings. That part works. The other way around, it conveniently forgets to send the dialed number in its SIP INVITEs:
INVITE sip:;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.2.248:5060 From: sip:[email protected];tag=1606025951 To: <sip:;user=phone> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected]:5060;transport=udp> User-Agent: Cisco ATA 186 v3.1.0 atasip (040211A) Expires: 300 Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 248 Content-Type: application/sdp
I've asked for an upgrade to the 3.2(1) image, but I haven't heard anything yet. Annoying!
Posted on 2005-03-28 23:14:38, modified on 2006-01-09 16:29:23
Tags: Voice over IP, Asterisk
This document describes a best practice approach to a structured and controllable design of the Asterisk extensions configuration file.
The design is as follows: There are input sources, there are dial groups and there are macros.
Input sources are places where calls are being made from. For example incoming SIP connections (authenticated or unauthenticated), calls from the PSTN and calls from the internal phone numbers.
Dial groups are destinations to be called. For example other SIP phones, calls to the PSTN, calls to internal phone numbers and calls to Asterisk applications like voicemail and conferences.
And as third, macros to reduce the amount of repetitive code.
The context of input sources are defined in sip.conf, iax2.conf and zapata.conf.
Sip.conf has three different contexts: The default context, to which everybody who isn't authenticated is assigned:
[general]
context=incoming-from-internet
People who are authenticated so they are trusted.
[my-friend]
context=incoming-from-friends
Iax2.conf has the same idea, but instead of putting it in the general section it's put in the guest section:
[guest]
context=incoming-from-internet
[my-friend]
context=incoming-from-friends
Zapata.conf has the definitions of ISDN channels to logical groups in it. For every group of ISDN channels you could have a different group and a different context:
group = 1
context = CUST1-PABX
signalling = pri_net
channel => 1-15,17-31
group = 2
context = CUST2-PABX
signalling = pri_net
channel => 32-46,48-62
group = 3
context = ME-TELCO
signalling = pri_net
channel => 63-77,79-93
Dial groups are the collections of different extension to dial. To start with, all PSTN numbers which are routed by your telco to your Asterisk server. Also all internal numbers for voicemail and conferences. And as last, a default entry for everything which is not local.
Our PSTN numbers for customers are +61 2 9210 0500 to +61 2 9210 0599 for customer 1 and +61 2 9210 0600 to +61 2 9210 0799 for customer 2. First we map the trunk to the customer onto the Zap interface, then we map the number ranges for the customers onto the customer trunks. In the dial plan we use the last mapping, so that any changes in hardware links only have to be modified in the general section. In the extensions definitions we use three versions of the number: The local number without the are code, the full national number with the area code and the international number with the country code.
[general]
TRUNK_CUST1= Zap/g1
TRUNK_CUST2= Zap/g2
TRUNK_612921005xx=${TRUNK_CUST1}
TRUNK_612921006xx=${TRUNK_CUST2}
TRUNK_612921007xx=${TRUNK_CUST2}
[outgoing-customer1]
exten => _612921005XX,1,Macro(call-int,${TRUNK_612921005xx},0${EXTEN:2})
exten => _02921005XX,1,Macro(call-int,${TRUNK_612921005xx},${EXTEN})
exten => _921005XX,1,Macro(call-int,${TRUNK_612921005xx},02${EXTEN})
[outgoing-customer2]
exten => _612921006XX,1,Macro(call-int,${TRUNK_612921006xx},0${EXTEN:2})
exten => _02921006XX,1,Macro(call-int,${TRUNK_612921006xx},${EXTEN})
exten => _921006XX,1,Macro(call-int,${TRUNK_612921006xx},02${EXTEN})
exten => _612921007XX,1,Macro(call-int,${TRUNK_612921007xx},0${EXTEN:2})
exten => _02921007XX,1,Macro(call-int,${TRUNK_612921007xx},${EXTEN})
exten => _921007XX,1,Macro(call-int,${TRUNK_612921007xx},02${EXTEN})
The PSTN number ranges for VoIP users are +61 2 9210 081x for authenticated SIP users and +61 2 9210 080x towards a remote SIP server.
[general]
OTHERSIPSERVER= sip.foo.bar
[outgoing-voip]
exten => _6129210080X,1,Macro(call-sip-remote,${EXTEN:9}@${OTHERSIPSERVER}))
exten => _029210080X,1,Macro(call-sip-remote,${EXTEN:8}@${OTHERSIPSERVER}))
exten => _9210080X,1,Macro(call-sip-remote,${EXTEN:6}@${OTHERSIPSERVER}))
exten => 61292100810,1,Macro(call-sip-local,foo,0${EXTEN:2})
exten => 0292100810,1,Macro(call-sip-local,foo,${EXTEN})
exten => 92100810,1,Macro(call-sip-local,foo,02${EXTEN})
exten => 61292100811,1,Macro(call-sip-local,bar,0${EXTEN:2})
exten => 0292100811,1,Macro(call-sip-local,bar,${EXTEN})
exten => 92100811,1,Macro(call-sip-local,bar,02${EXTEN})
We don't want to specify all outgoing PSTN numbers, so we just use a catch-all for them:
[general]
TRUNK_TELCO= Zap/g3
[outgoing-theworld]
exten => _.,1,Macro(call-ext,${TRUNK_TELCO},${EXTEN})
And a number of tools for internal and external users on +61 2 9210 082x:
[outgoing-tools]
exten => 61292100820,1,MeetMe(1234|M)
exten => 0292100820,1,MeetMe(1234|M)
exten => 92100820,1,MeetMe(1234|M)
exten => 61292100821,1,VoicemailMain
exten => 61292100821,n,Hangup
exten => 0292100821,1,VoicemailMain
exten => 0292100821,n,Hangup
exten => 92100821,1,VoicemailMain
exten => 92100821,n,Hangup
exten => *600,1,Playback(demo-echotest)
exten => *600,n,Echo
exten => *600,n,Playback(demo-echodone)
exten => *600,n,Hangup
Now we're in the section which actually does do the dialing. The following four macros are all we need: call-int, call-ext and call-sip-local and call-sip-remote.
The call-int macro calls on an internal trunk. Further call handling is done by these phone systems:
[macro-call-int]
exten => s,1,NoOp(Trunk:${ARG1})
exten => s,n,NoOp(Number:${ARG2})
exten => s,n,ChanIsAvail(${ARG1})
exten => s,n,Cut(C=AVAILCHAN,,1)
exten => s,n,Dial(${C}/${ARG2})
exten => s,n,Hangup()
The call-ext macro calls on a trunk to the outside world. We need to check for dial responses like BUSY, CHANUNAVAIL and others.
[macro-call-ext]
exten => s,1,NoOp(Trunk:${ARG1})
exten => s,n,NoOp(Number:${ARG2})
exten => s,n,ChanIsAvail(${ARG1})
exten => s,n,Cut(C=AVAILCHAN,,1)
exten => s,n,Dial(${C}/${ARG1})
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s,n,Hangup()
exten => s-BUSY,1,Busy()
exten => s-BUSY,n,Hangup()
exten => s-CHANUNAVAIL,1,PlayTones(congestion)
exten => s-CHANUNAVAIL,n,Wait(5)
exten => s-CHANUNAVAIL,n,StopPlayTones()
exten => s-CHANUNAVAIL,n,Hangup
exten => s-CONGESTION,1,PlayTones(congestion)
exten => s-CONGESTION,n,Wait(5)
exten => s-CONGESTION,n,StopPlayTones()
exten => s-CONGESTION,n,Hangup
exten => s-NOANSWER,1,Hangup
exten => s-ANSWER,1,Hangup
exten => s-CANCEL,1,Hangup
Call-sip-remote is just like call-int, but then for an SIP session:
[macro-call-sip-remote]
exten => s,1,Playback(pls-wait-connect-call)
exten => s,n,Dial(SIP/${ARG1},45,r)
exten => s,n,Hangup
And call-sip-local is like call-ext, but with better handling of failed dial attempts since we need to use voicemail there:
[macro-call-sip-local]
exten => s,1,NoOp(To user: ${ARG1})
exten => s,n,NoOp(Voicemail: ${ARG2})
exten => s,n,Dial(SIP/${ARG1},45,r)
exten => s,n,NoOp(${DIALSTATUS})
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s,n,Hangup
exten => s-BUSY,1,Playback(user)
exten => s-BUSY,n,Playback(is-curntly-busy)
exten => s-BUSY,n,Goto(s-VM,1)
exten => s-NOANSWER,1,Playback(user)
exten => s-NOANSWER,n,Playback(is-curntly-unavail)
exten => s-NOANSWER,n,Goto(s-VM,1)
exten => s-ANSWER,1,Playback(thank-you-for-calling)
exten => s-ANSWER,n,Hangup
exten => s-CHANUNAVAIL,1,Playback(is-curntly-unavail)
exten => s-CHANUNAVAIL,n,Goto(s-VM,1)
exten => s-CONGESTION,1,PlayTones(congestion)
exten => s-CONGESTION,n,Wait(5)
exten => s-CONGESTION,n,StopPlayTones()
exten => s-CONGESTION,n,Goto(s-VM,1)
exten => s-CANCEL,1,Hangup
exten => s-VM,1,VoiceMail(${ARG2})
exten => s-VM,n,Hangup
Pfioew! That's all the low level work.
Now it's time to glue the input source and the dial groups together. Every input source has its own definitions on which dial groups it is allowed to call.
The first group is the unauthenticated people on the internet which get routed to my Asterisk server. They are allowed to call my public PSTN numbers, but not to retrieve voicemail and do conferencing.
[incoming-from-internet]
include => outgoing-voip
include => outgoing-customer1
include => outgoing-customer2
The second group is the authenticated people on the internet which actually register at my Asterisk server. They are allowed as above, but also to retrieve voicemail and do conferencing.
[incoming-from-friends]
include => outgoing-tools
include => outgoing-voip
include => outgoing-customer1
include => outgoing-customer2
All incoming called from the PSTN are allowed to call my public PSTN numbers and to retrieve voicemail and do conferencing.
[ME-TELCO]
include => outgoing-tools
include => outgoing-voip
include => outgoing-customer1
include => outgoing-customer2
And the customers are allowed to call everything: public PSTN numbers, retrieve voicemail and do conferencing and make PSTN calls.
[CUST1-PABX]
include => outgoing-tools
include => outgoing-voip
include => outgoing-customer1
include => outgoing-customer2
include => outgoing-theworld
[CUST2-PABX]
include => outgoing-tools
include => outgoing-voip
include => outgoing-customer1
include => outgoing-customer2
include => outgoing-theworld
By properly defining what the input sources are, what the destination groups are and what the allowed destinations for an input source are, it is possible to have a structured, scalable and safe dial plan.
Posted on 2005-03-12 22:53:41, modified on 2006-01-09 16:29:23
Tags: Voice over IP, Cisco, DNS
The Cisco 7970 phones have a nifty feature: IP Phone Services. With it, you can access services on the internet (for example the stock value of CSCO). I have been asked to make some nifty features, but up to now it's no luck for me! Read on...
An IP Phone Service is defined as an URL, which returns an XML file with the commands in it. All very simple stuff.
For example, http://1.2.3.4/test.xml would return an XML file. This works.
But, we're living in the 21st century and we use hostnames these days. So, I changed it to http://xml.example.org/test.xml. No fish. Not even an TCP session towards the webserver. Why?
15:43:25.727288 10.192.15.229.1177 > 10.192.0.2.53: 48+ Type1907 (Class 29802)?. (33) [tos 0x60] 0x0000 4560 003d 1186 0000 3e11 4564 0ac0 0fe5 E`.=....>.Ed.... 0x0010 0ac0 0002 0499 0035 0029 0000 0030 0100 .......5.)...0.. 0x0020 0001 0000 0000 0000 0007 7374 6a61 6d65 ..........stjame 0x0030 7303 6e65 7402 6175 0000 0100 01 s.net.au.....
This is why. Don't ask me why the phone asks for A record of stjames.net.au, but it is asking it wrong: At offset 0x0028, the value 00 is there by mistake, it shouldn't have been there in the first place.
My name server happily refuses the query, and the Cisco 7970 returns "Host not found". Let's hope that Cisco can do something about it :-/
Note: Please note that this problem has been fixed in version 6.0.3.
Posted on 2005-02-21 13:02:07, modified on 2006-01-09 16:29:23
Tags: Voice over IP, Cisco, tftp, DHCP
For a new project within BarNet, we're going to use the Cisco solution for Voice-over-IP. The central server will be the Cisco Call Manager (and friends), the phones will be Cisco 7970 phones.
DHCP-wise these devices aren't too demanding, it asks for the TFTP server and something like option 150 (which is unspecified as far as I can tell). The TFTP server option is a string with the hostname or IP address of the TFTP server. The option 150 is, after going through the documentation of the Cisco gear, *also* for specifying the TFTP server, but then only with the IP address.
So the DHCP configuration should be (for people using the ISC DHCP server):
option cisco-tftp code 150 = array of ip-address;
class "cisco7970" {
match if substring (option vendor-class-identifier,0,37) = "Cisco Systems, Inc. IP Phone CP-7970G";
option arp-cache-timeout 60;
option cisco-tftp 192.168.1.1,192.168.1.2;
option tftp-server-name "cisco-cm.mavetju.org";
}
Update
There is a draft for the option 150 available at: http://www.ietf.org/internet-drafts/draft-raj-dhc-tftp-addr-option-00.txt
Posted on 2004-11-28 22:37:36, modified on 2006-01-09 16:29:22
Tags: Voice over IP, Asterisk, PRI
Problem: Before switching to asterisk, it was possible for people to seize the trunk and dial out any number, and thus bypassing the numbering plan. The error you currently get is:
-- Extension '' in context 'SJH05-A4400' from '282122348' does not exist. Rejecting call on channel 3/21, span 3
Solution: In zapata.conf, add overlapdial=yes to the group definition. This will cause an additional delay of three seconds before the number is forwarded:
-- Starting simple switch on 'Zap/206-1'
-- Accepting overlap call from '293312303' to '<unspecified>' on channel 7/20, span 7
-- Executing Dial("Zap/206-1", "Zap/g8/95212347||") in new stack
Posted on 2004-11-10 23:28:07, modified on 2006-01-09 16:29:22
Tags: Voice over IP, Asterisk, PRI
To connect an TE410P / TE405P card to the australian PSTN, use the following settings:
In /etc/zaptel.conf:
span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-21
dchan=16
unused=22-31
The 1 in span means that you use the clock from their network.
Please note that this is for an OnRamp20, which has 20 B-channels. With an OnRamp10 you need only channels 1-10 and modify unused too.
In /etc/asterisk/zapata.conf, use:
[trunkgroups]
trunkgroup => 1,16
spanmap => 1,1,1
[channels]
group = 1
context=PRI-Telstra
switchtype=national
pridialplan=unknown
prilocaldialplan=unknown
signalling = pri_cpe
channel => 1-15,17-21
Posted on 2003-11-20 18:58:47, modified on 2006-01-09 16:29:21
Tags: Voice over IP, DHCP, Alcatel
How to configure the ISC DHCP server to serve the Alcatel Voice over IP phones.
At BarNet, we are testing Voice over IP phones from Alcatel. C., The company which helps us with it isn't really up to date with their IP network skills. With the result that I had to spent the last days with trying to find out how to configure the ISC DHCP server properly for these phones. Fortunatly that I got some Alcatel OmniPCX 4400 manuals via a friend which described exactly what I needed to configure.
Please take note that...
So here is the config for the ISC DHCP:
class "ipphone" {
match if option vendor-class-identifier = "alcatel.tsc-ip.0";
option dhcp-parameter-request-list 1,3,28,43,54,58,59,60,66,67;
option vendor-encapsulated-options "alcatel.a4400.0";
option tftp-server-name "10.192.13.10";
option bootfile-name "ST_JAMES";
}That's a little bit shorter than the two pages of "click here, tick this button" for the Windows DHCP servers, isn't it?