Installers of VoIP (Voice over IP) often stress the importance of having QoS for the network. On a so-called 'experts' forum, I have even seen QoS put forward as the solution to one-way audio problems, even though it is of little or no relevance to such problems. QoS is undoubtedly a powerful and useful tool for VoIP engineers and can make a great difference in the right circumstances, but on the other hand is likely to make no difference at all to the handling of IP packets sent out to the Internet on a standard small-business broadband connection.
Want to know how QoS works in practice and understand where it makes a difference and how? Then read my article on the Smartvox Knowledgebase:
http://kb.smartvox.co.uk/index.php/ip-network-design/voip-qos-network-congestion/
Sunday, 27 November 2011
Wednesday, 5 October 2011
Why does NAT cause such a problem for SIP?
This question comes up time and again. Finding this week that I needed to brief a network consultant about the problems of SIP and NAT, it seemed like a good idea to write my summary here as a new blog article.
Why is NAT such a big deal for SIP communications:
Why is NAT such a big deal for SIP communications:
- Although one SIP device is nominally the client device and another is nominally the server, all SIP end-points may need to act as a server or client at certain points in the dialogue – for example, the client device may initiate a call, but the server may end it.
- SIP requests may be relayed through a series of SIP Proxy servers (similar to email being relayed by SMTP servers)
- If Proxy servers want to be kept in the signalling path, they add a special “Record-Route” header containing their own address. They must respect any existing Record-Route headers.
- SIP requests always contain a “Request URI address” which describes the ultimate destination, but SIP devices and SIP Proxies may relay the request to an intermediate address which they know will relay it to the final destination.
- SIP requests contain IP addresses embedded in various headers and also in the SDP payload – see below for details
- The media path may not be the same as the SIP signalling path. The end points for the media are given in the SDP payload. The idea is that the media path needs to be as direct as possible, but the SIP signalling is less susceptible to latency so it is acceptable for it to go via a more convoluted path (e.g. via a billing server)
- SIP requests contain a Via header to tell the destination which IP address (and port) to send their replies. The source device that constructs the SIP request may not be aware of NAT traversal further downstream so is likely to specify its own local IP in the Via. To alleviate this known problem, many SIP devices have features (e.g. STUN) to allow them to examine their own networking environment and determine if they are behind NAT. It is also quite common to be able to manually program the device with an “external” IP address.
- The port specified in the Via address does not have to be the same as the port that the request was sent from.
- SIP requests contain a Contact header which specifies the address where the sending device can be reached by the remote end-point when the remote end-point wants to initiate a new request (as opposed to responding to the existing request, which is handled by the Via)
If you want some further reading on this topic, please take a look at the following articles on the Smartvox knowledgebase:
Wednesday, 17 August 2011
VoIP QoS Settings
If you're confused by the QoS settings on VoIP equipment or just want to know what value you should assign to the DiffServ/TOS field on a Linksys IP phone, then you need to read the 2-part article on the Smartvox Knowledgebase:
VoIP QoS Settings - Part 1: Overview and Layer 2 settings
VoIP QoS Settings - part 2: Layer 3 settings, DSCP/TOS
VoIP QoS Settings - Part 1: Overview and Layer 2 settings
VoIP QoS Settings - part 2: Layer 3 settings, DSCP/TOS
Friday, 10 December 2010
Protecting Asterisk from Toll Fraud
Toll fraud on poorly protected Asterisk servers seems to have mushroomed in the last 12 months. I constantly see evidence of scanning and brute force password guessing attempts on port 5060 of many different servers and PBX's.
If you operate a Trixbox or any Asterisk based PBX then you urgently need to review how secure it is and make sure you have not left any gaps in your defences. Failure to do so could leave you with an astronomical phone bill and very little, if any, redress.
Learn about the vulnerabilities and how to protect your Asterisk based PBX by reading my three part article:
How secure is your Asterisk PBX? Part 1
How secure is your Asterisk PBX? Part 2
How secure is your Asterisk PBX? Part 3
If you find the articles useful, please pass the link on.
If you operate a Trixbox or any Asterisk based PBX then you urgently need to review how secure it is and make sure you have not left any gaps in your defences. Failure to do so could leave you with an astronomical phone bill and very little, if any, redress.
Learn about the vulnerabilities and how to protect your Asterisk based PBX by reading my three part article:
How secure is your Asterisk PBX? Part 1
How secure is your Asterisk PBX? Part 2
How secure is your Asterisk PBX? Part 3
If you find the articles useful, please pass the link on.
Friday, 28 May 2010
Caller ID in SIP and Asterisk - Part 2
Caller ID, ANI, PAI, RPI, Privacy - what Asterisk does
I didn't plan on writing a "Part 2" to this article, but since nobody has posted any answers to my questions in Part 1, I had no option other than to test it for myself. In some ways, the answers are quite simple, but there are some subtle details that are not at all intuitive.
P-Asserted-Identity
First, what does Asterisk do when it receives a P-Asserted-Identity header. The answer is an unqualified nothing! As far as I could ascertain, it ignores it totally no matter what settings you use for "trustrpid" or "sendrpid". It does not copy it from an inbound call leg to an outbound call leg for a bridged SIP-to-SIP call.
Remote-Party-ID
Next, what about the Remote-Party-ID header? Well, if you have set "sendrpid=yes" in the settings for the destination peer in sip.conf then Asterisk will always add an RPI header. Here is a typical example:
Remote-Party-ID: "Johns Linksys" <sip:1001@192.168.1.15>;privacy=off;screen=no
The name "Johns Linksys" and the number, 1001, were taken from the From header of the inbound call leg. The IP address 192.168.1.15 is the IP of the Asterisk server, but can be over-ridden using the "fromdomain" parameter in the definition of the destination peer in sip.conf.
If you set "trustrpid=yes" in the definition of the source peer in sip.conf, then Asterisk will use the number from the RPI header in the request it received on the inbound call leg.
Privacy
Asterisk respects the privacy setting in the RPI header it receives (if there is an RPI header in the request) irrespective of any setting for "trustrpid". However, I have not found a way to tell Asterisk to change the privacy setting for a call it is bridging. Asterisk ignores the PAI Privacy header if the inbound call leg includes one.
<1001@192.168.1.15>
We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-2 |
I didn't plan on writing a "Part 2" to this article, but since nobody has posted any answers to my questions in Part 1, I had no option other than to test it for myself. In some ways, the answers are quite simple, but there are some subtle details that are not at all intuitive.
P-Asserted-Identity
First, what does Asterisk do when it receives a P-Asserted-Identity header. The answer is an unqualified nothing! As far as I could ascertain, it ignores it totally no matter what settings you use for "trustrpid" or "sendrpid". It does not copy it from an inbound call leg to an outbound call leg for a bridged SIP-to-SIP call.
Remote-Party-ID
Next, what about the Remote-Party-ID header? Well, if you have set "sendrpid=yes" in the settings for the destination peer in sip.conf then Asterisk will always add an RPI header. Here is a typical example:
Remote-Party-ID: "Johns Linksys" <sip:1001@192.168.1.15>;privacy=off;screen=no
The name "Johns Linksys" and the number, 1001, were taken from the From header of the inbound call leg. The IP address 192.168.1.15 is the IP of the Asterisk server, but can be over-ridden using the "fromdomain" parameter in the definition of the destination peer in sip.conf.
If you set "trustrpid=yes" in the definition of the source peer in sip.conf, then Asterisk will use the number from the RPI header in the request it received on the inbound call leg.
Privacy
Asterisk respects the privacy setting in the RPI header it receives (if there is an RPI header in the request) irrespective of any setting for "trustrpid". However, I have not found a way to tell Asterisk to change the privacy setting for a call it is bridging. Asterisk ignores the PAI Privacy header if the inbound call leg includes one.
<1001@192.168.1.15>
Tuesday, 20 April 2010
Caller ID in SIP and Asterisk - Part 1
Caller ID, ANI, PAI, RPI, Privacy - can Asterisk cope?
Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller's number on an LCD display, look it up in a directory so the caller's name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller's identity because it may be important for billing or to notify the emergency services of the caller's location.
In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data - a display ID that can optionally be blocked and an asserted ID or ANI that cannot. Protocols such as ISDN also include single bit privacy flags that show if the ID should be hidden.
The SIP protocol also has elements that allow for all the caller ID requirements. The From header provides basic caller ID data but it is too easily modified, blocked or spoofed to be of use to the network. Alongside this, the SIP protocol was extended to support the use of the Remote-Party-Id (RPI) header which should be added to an Invite by the first server within the trusted network cloud. It is described in an IETF memo:
http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt
The RPI header is added by one of the network servers so it should provide a much more reliable and trustworthy identification than the From header which can be set by users at the client device. The IETF memo also makes provision for the inclusion of certain tag values on the RPI header: "privacy" indicates to what extent the ID should be hidden and "screen" indicates what level of trust the network associates with the Remote-Party-ID information.
Another approach is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity (PAI) header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.
Decisions about adding or removing these ID headers depend partly on whether the call is entering or leaving your own infrastructure cloud and whether the remote peer or UA is trusted or not. If necessary, servers must use authentication challenges to ensure that a remote device can be trusted and only then should they add a P-Asserted-Identity header. When a request is sent to an untrusted device, it is necessary first to delete any such headers.
What control is provided within Asterisk?
Regrettably, all I have here are questions. Lots of questions and very few answers. Lets start with some basic facts about the configuration settings available in sip.conf:
Asterisk has two parameters for controlling handling of Remote-Party-Id as follows:
sendrpid=yes¦no : If an RPI header should be sent to the peer
trustrpid=yes¦no : If the RPI from this peer can be trusted
However, I am not sure what these parameters mean in practice. For example, will Asterisk automatically add an RPI header when sendrpid is set to "yes" or will it remove the header when set to "no". When I get time I will do some testing to see how it actually behaves.
To see the results of my testing, take a look at Part 2.
How does Asterisk handle caller ID when bridging calls from SIP to ISDN? For example, does it automatically populate the ANI and other caller ID fields using data sent in the RPI and From headers? If so, does this behaviour depend on the setting of trustrpid?
Areas where Asterisk seems to be very weak include:
1. The handling of P-Asserted-Identity. The only control I am aware of is the ability to add a PAI header (and a Privacy header) using the SIPAddHeader() function. Why doesn't Asterisk have a SIPDeleteHeader() function?
2. Access to the Privacy settings of ISDN calls. You can see the setting using the pri debug command at the CLI, but there seems to be no way of accessing the data within the dial plan.
We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-1 |
Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller's number on an LCD display, look it up in a directory so the caller's name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller's identity because it may be important for billing or to notify the emergency services of the caller's location.
In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data - a display ID that can optionally be blocked and an asserted ID or ANI that cannot. Protocols such as ISDN also include single bit privacy flags that show if the ID should be hidden.
The SIP protocol also has elements that allow for all the caller ID requirements. The From header provides basic caller ID data but it is too easily modified, blocked or spoofed to be of use to the network. Alongside this, the SIP protocol was extended to support the use of the Remote-Party-Id (RPI) header which should be added to an Invite by the first server within the trusted network cloud. It is described in an IETF memo:
http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt
The RPI header is added by one of the network servers so it should provide a much more reliable and trustworthy identification than the From header which can be set by users at the client device. The IETF memo also makes provision for the inclusion of certain tag values on the RPI header: "privacy" indicates to what extent the ID should be hidden and "screen" indicates what level of trust the network associates with the Remote-Party-ID information.
Another approach is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity (PAI) header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.
Decisions about adding or removing these ID headers depend partly on whether the call is entering or leaving your own infrastructure cloud and whether the remote peer or UA is trusted or not. If necessary, servers must use authentication challenges to ensure that a remote device can be trusted and only then should they add a P-Asserted-Identity header. When a request is sent to an untrusted device, it is necessary first to delete any such headers.
What control is provided within Asterisk?
Regrettably, all I have here are questions. Lots of questions and very few answers. Lets start with some basic facts about the configuration settings available in sip.conf:
Asterisk has two parameters for controlling handling of Remote-Party-Id as follows:
sendrpid=yes¦no : If an RPI header should be sent to the peer
trustrpid=yes¦no : If the RPI from this peer can be trusted
However, I am not sure what these parameters mean in practice. For example, will Asterisk automatically add an RPI header when sendrpid is set to "yes" or will it remove the header when set to "no". When I get time I will do some testing to see how it actually behaves.
To see the results of my testing, take a look at Part 2.
How does Asterisk handle caller ID when bridging calls from SIP to ISDN? For example, does it automatically populate the ANI and other caller ID fields using data sent in the RPI and From headers? If so, does this behaviour depend on the setting of trustrpid?
Areas where Asterisk seems to be very weak include:
1. The handling of P-Asserted-Identity. The only control I am aware of is the ability to add a PAI header (and a Privacy header) using the SIPAddHeader() function. Why doesn't Asterisk have a SIPDeleteHeader() function?
2. Access to the Privacy settings of ISDN calls. You can see the setting using the pri debug command at the CLI, but there seems to be no way of accessing the data within the dial plan.
Saturday, 19 December 2009
Taking the plunge with SIP Trunks - part 3
Outbound calls; Matching a DDI/DID; Diagnosing problems; Internet bandwidth.
Configuration for Outbound calling
Part 2 looked only at the configuration for receiving inbound calls, but the SIP Trunk configuration form in Trixbox/FreePBX has to also include the settings for making outbound calls. It may not even work at all if you only use the inbound call settings shown in part 2.
You will need a peer definition in sip.conf that includes "type=peer" and has the user ID and password required by your VoIP service provider. I also recommend that you duplicate the settings for "context=" and "insecure=" that were described in part 2 because Asterisk can be annoyingly unpredictable about separation of inbound and outbound call handling.
Outbound calls are authenticated with "username" and "secret" during call set up. Some service providers may also check that your PBX is registered, but this is usually unnecessary for outbound calls. Where the user ID assigned to you by the VoIP service provider is also your DID number, then assign that value both to the "username=" and the "fromuser=" as shown above. Otherwise, set "fromuser" as your DID number. The "host=" parameter tells Asterisk where to send the INVITE request when making a call. The "qualify=yes" parameter tells Asterisk to ping the service provider at frequent intervals - this allows Asterisk to monitor the connection and to maintain some measure of its latency (the time it takes for packets to get from one end of the connection to the other).
For those of you who prefer to use raw Asterisk instead of Trixbox or FreePBX, you will need to add a similar section in sip.conf to the one shown above for FreePBX:
[smartvox-out]
type=peer
username=432112345
secret=mysecret
fromuser=43212345
fromdomain=mysipsp.com
qualify=yes
context=from-trunk
insecure=invite
host=mysipsp.com
In fact, the above peer definition (plus the registration) should be all you need for handling both inbound and outbound calls. Inbound calls are matched against known peers by checking the address given for "host=". When there are two peers defined in sip.conf with the same host address, it is usually the last one that takes precedence. However, in the latest release 1.6 of Asterisk, this unwritten rule seems to have been reversed - the first matching peer is used. If you only have one peer definition capable of handling both inbound and outbound calls (as shown above) then there is less scope for confusion.
Matching the DDI/DID number for inbound calls
SIP trunks are likely to support multiple inbound DID numbers so your dial plan will have to be able to match each number and route the call correctly. However, different service providers use different techniques to send the dialled number to your PBX. It is very likely that you will have to add some special code to the Asterisk dial plan to extract the dialled number from the To header in the SIP INVITE. There is no point re-inventing the wheel, so I recommend you check out this link for details of how to use the CUT function in Asterisk to get the dialled number:
http://www.freepbx.org/support/documentation/howtos/how-to-get-the-did-of-a-sip-trunk-when-the-provider-doesnt-send-it-and-
Diagnosing problems and monitoring your connection
The following Asterisk CLI commands are extremely useful for checking if things are working:
To check it has registered with the VoIP service provider: sip show registry
To see information about defined sip peers: sip show peers
To see detailed information about one peer: sip show peer <peer_name>
To view all SIP packets sent to-from Asterisk: sip set debug on
To view SIP packets sent to-from one peer: sip set debug peer <peer_name>
To switch off sip debug: sip set debug off
I recommended you add the parameter "qualify=yes" in your peer definition. If you did, then the command "sip show peers" will be able to show you if the peer is reachable and what the approximate delay is for packets sent to that peer. This is shown in the last column, "Status". Note that, if this status appears as "unreachable", then Asterisk will not attempt to send any SIP requests to it - an outbound call via that peer will fail as soon as it is dialled.
If you are getting problems with one-way audio or simply with making or receiving calls over your SIP Trunk, then the chances are it will be because your Asterisk server is behind NAT. This is a very common problem and usually can be cleared by setting a couple of parameters in the general sectio of the sip.conf file (sip_general_custom.conf on Trixbox/FreePBX) and possibly setting some port forwarding on your firewall. Read my article here for details:
http://www.smartvox.co.uk/astfaq_configbehindnat.htm
Internet Bandwidth
So you've got your SIP trunk working and in theory it can carry several simultaneous calls. One thing you must remember is that each call requires a significant amount of bandwidth on your broadband connection. If you are using one broadband connection for both data and voice, then there will probably be times when the voice quality suffers because there is too much contention for the bandwidth available. If possible (and if you want to carry several simultaneous calls) it is best to use a dedicated broadband connection for voice traffic. Remember that voice uses equal amounts of upload and download bandwidth whereas ADSL has much more download capacity then upload. Try one of the many free web based broadband speed comparison tests to see how your broadband connection is performing at different times of the day. Ideally, use SDSL or a leased line solution. If you are using one Internet connection for voice and data, consider using QoS mechanisms to manage the bandwidth and prioritise voice over data. Also consider using the more compressed codecs such as GSM or G.729 instead of the uncompressed G.711 codecs (A-Law and u-Law), even if it does mean you'll have to purchase some G.729 licenses for your Asterisk server.
The following links provide useful data about the bandwidth demands for various codecs:
http://www.ozvoip.com/voip-codecs/
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml
We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on SIP trunks in Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/index.php/asterisk/telephony-connections/sip-trunks-telephony-connections/taking-the-plunge-with-sip-trunks-part-3/ |
Configuration for Outbound calling
Part 2 looked only at the configuration for receiving inbound calls, but the SIP Trunk configuration form in Trixbox/FreePBX has to also include the settings for making outbound calls. It may not even work at all if you only use the inbound call settings shown in part 2.
You will need a peer definition in sip.conf that includes "type=peer" and has the user ID and password required by your VoIP service provider. I also recommend that you duplicate the settings for "context=" and "insecure=" that were described in part 2 because Asterisk can be annoyingly unpredictable about separation of inbound and outbound call handling.
Outbound calls are authenticated with "username" and "secret" during call set up. Some service providers may also check that your PBX is registered, but this is usually unnecessary for outbound calls. Where the user ID assigned to you by the VoIP service provider is also your DID number, then assign that value both to the "username=" and the "fromuser=" as shown above. Otherwise, set "fromuser" as your DID number. The "host=" parameter tells Asterisk where to send the INVITE request when making a call. The "qualify=yes" parameter tells Asterisk to ping the service provider at frequent intervals - this allows Asterisk to monitor the connection and to maintain some measure of its latency (the time it takes for packets to get from one end of the connection to the other).
For those of you who prefer to use raw Asterisk instead of Trixbox or FreePBX, you will need to add a similar section in sip.conf to the one shown above for FreePBX:
[smartvox-out]
type=peer
username=432112345
secret=mysecret
fromuser=43212345
fromdomain=mysipsp.com
qualify=yes
context=from-trunk
insecure=invite
host=mysipsp.com
In fact, the above peer definition (plus the registration) should be all you need for handling both inbound and outbound calls. Inbound calls are matched against known peers by checking the address given for "host=". When there are two peers defined in sip.conf with the same host address, it is usually the last one that takes precedence. However, in the latest release 1.6 of Asterisk, this unwritten rule seems to have been reversed - the first matching peer is used. If you only have one peer definition capable of handling both inbound and outbound calls (as shown above) then there is less scope for confusion.
Matching the DDI/DID number for inbound calls
SIP trunks are likely to support multiple inbound DID numbers so your dial plan will have to be able to match each number and route the call correctly. However, different service providers use different techniques to send the dialled number to your PBX. It is very likely that you will have to add some special code to the Asterisk dial plan to extract the dialled number from the To header in the SIP INVITE. There is no point re-inventing the wheel, so I recommend you check out this link for details of how to use the CUT function in Asterisk to get the dialled number:
http://www.freepbx.org/support/documentation/howtos/how-to-get-the-did-of-a-sip-trunk-when-the-provider-doesnt-send-it-and-
Diagnosing problems and monitoring your connection
The following Asterisk CLI commands are extremely useful for checking if things are working:
To check it has registered with the VoIP service provider: sip show registry
To see information about defined sip peers: sip show peers
To see detailed information about one peer: sip show peer <peer_name>
To view all SIP packets sent to-from Asterisk: sip set debug on
To view SIP packets sent to-from one peer: sip set debug peer <peer_name>
To switch off sip debug: sip set debug off
I recommended you add the parameter "qualify=yes" in your peer definition. If you did, then the command "sip show peers" will be able to show you if the peer is reachable and what the approximate delay is for packets sent to that peer. This is shown in the last column, "Status". Note that, if this status appears as "unreachable", then Asterisk will not attempt to send any SIP requests to it - an outbound call via that peer will fail as soon as it is dialled.
If you are getting problems with one-way audio or simply with making or receiving calls over your SIP Trunk, then the chances are it will be because your Asterisk server is behind NAT. This is a very common problem and usually can be cleared by setting a couple of parameters in the general sectio of the sip.conf file (sip_general_custom.conf on Trixbox/FreePBX) and possibly setting some port forwarding on your firewall. Read my article here for details:
http://www.smartvox.co.uk/astfaq_configbehindnat.htm
Internet Bandwidth
So you've got your SIP trunk working and in theory it can carry several simultaneous calls. One thing you must remember is that each call requires a significant amount of bandwidth on your broadband connection. If you are using one broadband connection for both data and voice, then there will probably be times when the voice quality suffers because there is too much contention for the bandwidth available. If possible (and if you want to carry several simultaneous calls) it is best to use a dedicated broadband connection for voice traffic. Remember that voice uses equal amounts of upload and download bandwidth whereas ADSL has much more download capacity then upload. Try one of the many free web based broadband speed comparison tests to see how your broadband connection is performing at different times of the day. Ideally, use SDSL or a leased line solution. If you are using one Internet connection for voice and data, consider using QoS mechanisms to manage the bandwidth and prioritise voice over data. Also consider using the more compressed codecs such as GSM or G.729 instead of the uncompressed G.711 codecs (A-Law and u-Law), even if it does mean you'll have to purchase some G.729 licenses for your Asterisk server.
The following links provide useful data about the bandwidth demands for various codecs:
http://www.ozvoip.com/voip-codecs/
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml
Subscribe to:
Posts (Atom)
