Views
VoIP FAQ
This FAQ is a collection of brief answers to some questions Evariste frequently receives as part of our consulting engagements and extensive support involvement in the open-source VoIP community. We hope that you find it a beneficial resource.
Disclaimer: All positions expressed in this document reflect the professional opinion of Evariste Systems personnel only and should not be construed as having been endorsed or reviewed by third-party organizations, including developers, vendors, or other collectives or individuals bearing relation to some of the products, platforms, and other proper nouns referenced therein.
Note: This FAQ is a work in progress.
General Telecommunications
PSTN Operations (USA only)
How do I perform LNP dips?
In general, you can't. LNP dips require access to the NPAC database operated by Neustar, Inc. Unless you are a carrier, you don't have NPAC access.
How do I identify what carrier a number belongs to?
While it is possible to identify the underlying carrier to which a number is homed with a reasonable probability of accuracy, it is not possible to do so with a high degree of accuracy without being able to issue Local Number Portability (LNP) queries. Information on numbering space assignments that is publicly available is based on assignments of "number blocks" (also known by a variety of other names, including "central office codes," "office codes," and more); within those blocks, it is possible that a number is ported to a carrier other than the one to which the number block is assigned. Individuals and private organizations that are not local exchange carriers do not have access to LNP information.
PSTN number resources in North America are allocated by the North American Numbering Plan Administration, or NANPA. Number spaces are assigned by NANPA in blocks of 10,000 numbers based on NPA-NXX (area code and exchange code). For example, the NANPA block 404-713 includes all numbers from 404-713-0000 to 404-713-9999. NANPA publishes a convenient spreadsheet of all current block assignments.
More recently (post-2000), in light of the appearance of small competitive carriers with low number space requirements in a given area ("rate center"), inefficiencies in such large allocations appeared. A scheme to split NANPA 10,000 blocks into blocks of 1,000 numbers (e.g. 404-713-1xxx, 404-713-2xxx, etc.) known as "number pooling" was enacted; consequently, for a large and growing number of allocations in metropolitan areas, traditional NANPA blocks are no longer a meaningful way to determine number block ownership. Number pooling is administered by Neustar, Inc., a clearinghouse operator chartered by the US federal government to operate and manage a variety of services in the technical environment that emerged after local loop deregulation in the late 1990s.
Pooled block assignments can be looked up at the National Pooling web site, although, unlike NANPA, Neustar is evidently not disposed to export these in a format that lends itself to machine processing. We can only speculate as to the motives for this limitation.
Local Calling Guide is an extremely convenient resource that -- among its other useful functions -- superimposes pooling data on top of NANPA block allocation data. Without knowing whether the number block to which a number belongs is pooled, your easiest and most convenient way to get the best information you can on a number block is to enter the NPA and NXX (i.e. 404 and 713, per the above example) here. The result set will reveal whether number pooling is applicable. This type of data is also available at various other web sites such as Telcodata.US.
There is a possibility that the number you are querying is ported. Beyond the information above, there is no method of finding out whether a number is ported -- and if so, to whom -- available to members of the general public. Because portability information is granular to the single number level, it is considered confidential by the consortia of incumbent carriers involved in the operation of the Neustar's LNP infrastructure.
The intercarrier routing process is only going to become more LNP-dependent as more numbers get ported. As it stands, it is now not considered practical in almost any area to operate a switch without LNP capabilities.
How do I find out ILEC local calling areas?
The official answer is that rate center information (i.e. whether two endpoints are in the same rate center) is buried in lengthy and recondite tariffs (documents detailing pricing and terms for various classes of services offered) filed by local exchange carriers with the FCC and state regulators. There is no straightforward way, although there are various consultancies and other professional organizations such as CCMI that watch tariff changes and publish such information in machine-processable database export formats on a commercial basis.
The unofficial answer is that this information is available from Local Calling Guide. The origin of the information on that web site is mysterious and apocryphal, but it is generally highly accurate and up to date.
Also, note that these local calling areas pertain to ILEC services. Private competitive carriers operating their own transport and switching infrastructure are free to define calling areas as they wish and rate calls placed through their network by their users however they please.
VoIP
General
What kind of Internet connection do I need at my business to use VoIP?
This depends on a number of factors:
- Amount of users;
- Amount of concurrent calls in typical use;
- The quality of your Internet Service Provider (ISP), including its upstream providers and peering arrangements as well as transport facilities oversubscription;
- The type and amount of other data traffic on your connection in typical use.
- Your investment in appropriate equipment on your end to manage QoS and network contention of VoIP with other traffic.
- Where your VoIP service is being provided in relation to you and your ISP.
In general, running VoIP over ADSL or cable modem is possible in a very small office. However, we always recommend that you invest in a T1 or higher calibre dedicated circuit for bearing voice and data. ADSL and cable modem are highly oversubscribed and comparatively unreliable services designed that way in order to meet price points expected by residential consumers in the mass-market; they are not really suitable for mission-critical business data, let alone something as demanding as voice.
If you are determined to use a low-grade broadband connection (i.e. typical ADSL or cable modem), we recommend that you obtain your Internet connectivity and VoIP service from the same source if possible, as this way your liability to the variable conditions of the Internet beyond your provider's internal network is minimized. However, if you have a decent connection (T1 and higher), this is not necessary--although you should still choose your VoIP provider carefully for the same fundamental reason.
Should I use a hosted PBX or run it in-house?
The single biggest mistake many organizations we talk to make is to cling stubbornly to the idea that they need to run their own VoIP PBX on their own premises. Perhaps it is because they are thinking about IP telephony in the same way they thought about their legacy digital PBX system/key system.
The various limitations of the Internet notwithstanding, you should definitely seek hosted service from an outside vendor whenever possible. This is for the same general reason for which you divest your other operational processes of things which are not aligned with your core competency. It is also far less capital-intensive; in many cases, little to no up-front investment is required. The level of service and features you will receive will be far better than what you can come up with on your own, and no wheel reinvention is required.
That said, there are plenty of valid and legitimate reasons to operate your own IP telephony infrastructure. If it is tightly coupled with other business applications and processes or requires heavy customization, you probably don't have a choice. Bear in mind, however, that most businesses do not have the internal infrastructure and/or bandwidth to maintain a highly available telephone system internally. Many think they do, but they pay the price when the weakest link breaks. If you choose to operate your own system, consider colocating it in a real, carrier-grade data center instead of a server closet down the hall. (This is also something we recommend for other mission-critical IT systems.)
Still, if your use of IP telephony can generally be framed in standard business PBX terms, we encourage you to think carefully about whether there are genuine and viable reasons for running your own present in your situation. Otherwise, it can be a phenomenal waste of money and time.
Is spoofing caller ID legal?
Depends on jurisdiction.
In the US, rewriting caller ID to achieve certain ends is legal if the ends aren't deceptive. For example, setting the caller ID on all outbound calls coming out of your organization - regardless of handset and/or applicable direct numbers - to your main office number is acceptable. Likewise, if you use different providers for termination (outbound) and origination (inbound) -- which is quite common in the VoIP world -- your termination provider is obviously not going to know to set your caller ID to match your inbound number from another service provider entirely. In that case, you may provide to them a caller ID to set on your behalf.
Do note that "caller ID" as most people know it is a rather cosmetic concept, and not the same as ANI (Automatic Number Identification). If you do anything that prompts law enforcement investigation, they'll find you; manipulating caller ID won't get you far.
What is media path optimization/media release, and why is it important?
Media path optimization/media release is a way for a VoIP service delivery platform to instruct external endpoints of a call set up through it to pass media directly amongst themselves instead of continuing to remain in the path of that media. Of course, the VoIP platform can pivot the media path and re-insert itself into it if it is required to provide a feature (music on hold, recording, channel barging, call transfer, etc.). The platform can also remain in the signaling path continuously, so this does not prevent accounting or fundamental call control from taking place.
Without media path optimization/media release, media flow looks like this:
With it, the flow looks like this:
The same principle applies to media interactions between users and PSTN gateway equipment located at a POP in a different place than your service platform, or even your upstream carrier's VoIP network edge.
Media path optimization/media release is an essential design consideration in the design of any VoIP service delivery platform. If you are providing VoIP services over the Internet, you should make every effort to get out of the media path for calls you are merely intermediating.
This can enhance the user's quality of service as it removes your POP as a routing hop in the media path. It also greatly reduces your capital requirements as you are not burdened with the need to scale computing resources to handle increasing amounts of expensive media, and saves on your bandwidth bill while removing your Internet connection as a governing limitation on your call capacity.
As with any lucrative improvement in efficiency, there are drawbacks from an engineering perspective that need to be considered. One is the impact this has on NAT traversal for users in certain scenarios. Another is that depending on where your users are located and your peering arrangements relative to Tier 1 IP backbones, their BGP routing path to your equipment may actually be less expensive (i.e. in terms of latency, reliability, total bandwidth, core and access router load, etc.) than the path amongst themselves.
I want to be a VoIP provider; am I regulated by the government? (USA only)
Yes. The Federal Communications Commission (FCC) has leveled certain regulatory obligations on VoIP service providers, although they are not nearly as extensive as those faced by Local Exchange Carriers (LECs).
To be a regulated VoIP provider, you must meet the FCC's definition of "interconnected VoIP provider" as outlined in CFR 47 Section 9.3. This definition is rather broad, and at the present time consists of the following criteria:
- Your service enables two-way voice communications in real time.
- Your service requires a broadband connection at the user premise.
- Your service requires Internet Protocol-compatible customer premise equipment (including software phones, ATAs, etc.)
- Your service permits users generally to receive calls that originate on the public switched telephone network and to terminate calls to the public switched telephone network.
There are plenty of unresolved ambiguities hinging on the exact part of the service chain occupied by various application-level service providers, as well as just what kind of thing constitutes "service" from a technological perspective. The FCC's stance -- characteristically of government agencies -- tends to be "if in doubt, the definition applies to you."
We are not telecommunications lawyers, so we are not equipped to make such interpretations for you. For the most reliable information, consult the FCC or a lawyer.
What regulatory obligations do interconnected VoIP providers face? (USA only)
For a robust answer of immaculate detail, contact the FCC or a telecommunications lawyer.
Broadly speaking, VoIP' providers government-mandated obligations fall into four provinces at the time of this writing:
- Universal Service Fund (USF) contributions - VoIP providers must make contributions to the Universal Service Fund (USF). This is a fund to which telecommunications service companies are required to contribute that subsidises the deployment of enhanced broadband and telephony services to "underserved" areas, including poor and rural communities.
- Enhanced 911 (E911) - VoIP providers must be able to provide end-users with a means of reaching a PSAP (Public Safety Answering Point) by dialing 911 as much as the underlying technology will allow, and must deploy technology to provide PSAPs automatically with address/geographic information (a technology known as ALI - Automatic Location Identification). This is the chief defining attribute of the "E" in E911 - Enhanced 911 services. The full guidelines are defined in the FCC's E911 order.
- CALEA - VoIP providers must have equipment compliant with the requirements set forth in the Communications Assistance for Law Enforcement Act (CALEA) and must file reports with the FCC illustrating their compliance. Subpoenas for wiretapping and other law enforcement functions can be served directly to VoIP providers, not just the underlying carriers, and the penalties for noncompliance can be stiff.
- LNP - VoIP providers must accommodate Local Number Portability (LNP) requirements in partnership with their underlying carriers. LNP allows numbers to be ported among fixed-line (and wireless, in the form of the WLNP regime) carriers pursuant to certain guidelines.
The good news is that a lot of these obligations can be met through underlying wholesale carriers from whom you purchase trunking, particularly E911 and LNP.
Which SIP phones do you recommend?
We're not really in the business of supporting phones as such, so we can't make any informed recommendations. We personally tend to use Snom, Polycom and Cisco SIP phones.
Asterisk
I want to provide VoIP service; should I use Asterisk inside my platform?
There is considerable and extensive debate about this, but a lot of the discourse is specious or orthogonal to the concern.
From a reliability standpoint, there is no particular reason not to use Asterisk inside a VoIP service delivery platform; it has matured into a robust and well-developed product with an installed base estimated to be in the millions.
Most of the concern relates to scalability and capacity, but the answer depends on the intended application. For example, we do not recommend the use of Asterisk as a general point of transit for voice calls or as a call router. That can be accomplished in a far more scalable and efficient way by other means that more closely mimic the topology of large-enterprise platforms. However, Asterisk is an excellent choice for various specialized and dedicated component roles.
If you design your platform the right way and use Asterisk appropriately, the answer is yes.
How do I scale a single Asterisk installation across multiple hosts?
There's no simple, canned answer. As always, it depends on the precise application. What can be said with certainty is that it can be done.
To the extent that it is possible to formulate an answer in general terms, it generally revolves around the following two initiatives:
- Front Asterisk with a SIP request distributor/load balancer proxy, and possibly other outboard components (such as a dedicated standalone registrar).
- Find ways to genericize functionality executed on one host so that it can be distributed across multiple hosts; this typically means centralizing some of the logic.
Does Asterisk have SIP interoperation problems?
Few things in the SIP world don't. Interop quirks are a leading problem with SIP.
In our experience, Asterisk has one of the most tolerant, flexible and generally interoperable SIP stacks out there. It seems that Asterisk is more likely to play well with another vendor's SIP implementation in an average case than another proprietary implementation.
Can I use Asterisk for a call center?
Yes. Asterisk is very good for that because it -- like many things that are foundationally open-source -- provides a great deal of integration paths by way of various APIs.
Can Asterisk handle a channelized DS3?
There are no hardware DS3 interfaces for PCs running Asterisk. The highest-density hardware interfaces available are 4-port T1/E1 cards, which imposes a practical limit of ~4-8 DS1-level circuits per host.
The way to handle a channelized DS3 would be to break T1s/E1s out of an M13 mux into multiple Asterisk hosts. This is quite practical in some situations.
Is Asterisk a (soft)switch?
As innumerable polemics on this subject have shown, that largely depends on how you define "softswitch." If a softswitch is simply a software-driven (in the balance of things) facility to switch voice calls among various interface technologies, seemingly the answer is yes.
Because we operate in the carrier and service provider space, we do not consider it meaningful to describe Asterisk as a softswitch. It is a "switch" in the above sense only to the extent that a PBX is a switch, which isn't what telecom operators mean when they say "switch."
Asterisk's primary architectural distinction from that of a softswitch is that it does not separate the signaling and bearer plane; they are handled in a unitary process. This has enormous implications for its ability to scale to very high call volumes and perform other functions characteristic of a telco switch, but is appropriate for a PBX, which is what Asterisk was designed to be.
Thus, no, we do not say that Asterisk is interchangeable with "softswitch," and would not deploy it in situations that would call for the sort of thing that a softswitch is in telco parlance. Beyond that general pronouncement, the issue seems to be semantic.
Can I use Asterisk as an SS7 switch?
Asterisk's SS7 driver currently supports ISUP, but not TCAP or other elements of a relatively complete SS7 stack required of a telco switch. If ISUP is all you need (for example, if you have some small access trunks signaled as SS7 instead of ISDN PRI from your telco), yes.
Beyond that, Asterisk is not equipped to play the role of a switch, as spoken to in the previous question. It does not separate bearer and signaling components like a telco switch. For using Asterisk to handle SS7, this has the specific implication that you cannot control bearer trunks (CICs) that are not physically connected to the same machine as the one hosting the SS7 link set. This essentially limits you to a few T1/E1s worth of trunks, and there are no DS3 interfaces available.
Large telco switches approach this problem architecturally by separating "smart" signaling agents from "dumb" media gateways, which are functions that Asterisk fuses together. Dense media gateways are instructed to deal with particular trunks by the signaling agent using a separate call control mechanism such as H.248/MEGACO or MGCP (Media Gateway Control Protocol). Asterisk does not support H.248/MEGACO and does not support MGCP nearly to the extent necessary to control media gateways in this manner; its MGCP support is intended for phones.
How do I build a prepaid calling card service with Asterisk?
That depends on the size of the operation and the complexity of your requirements.
There are a great deal of commercial solutions geared toward this aim. Smaller, low-end setups seem to frequently rely on the free, open-source A2Billing package. Some prepaid platforms work on a simpler principle and use OpenSER/Kamailio/OpenSIPS in combination with AG Projects' CDRTool and RADIUS.
If your requirements have more logic and complexity than these cookie-cutter approaches can accommodate, we can assist you with custom development.
Can I run Asterisk inside a virtual machine?
For small-scale uses, it may be okay. Our experiences with Asterisk in a virtualized environment have not been good; generally speaking, the artificial timing and scheduling environment inside a virtual machine is not of a sufficiently low tolerance to support handling of large loads of real-time media services.
Because of the delay sensitivity of voice, VoIP media consists of a very large amount of very small packets per conversation (compared to other data applications), and it is important that these packets are relayed quickly and without much variation in the interval with which they are sent (this variation is known as "jitter"). It is our impression that this requires from execution in a native, hardware-bound operating system environment to work reliably at this time, at least under nontrivial load.
If you have a different perspective, drop us a line; we'd love to hear about it!
Can I run Asterisk inside a computing cloud?
Please see the previous question, "Can I run Asterisk inside a virtual machine?"
Are there free Asterisk-based predictive dialers?
There are various Asterisk-based products that attempt to provide this functionality with varying degrees of sophistication.
We have not been sufficiently impressed by any of the open-source options that we are aware of to recommend them for serious use in outbound telemarketing. If you have a good suggestion, please send it to us.
Does Asterisk support T.38?
At the time of this writing, not natively. But you can combine Asterisk with something like t38modem.
Kamailio/OpenSIPS (OpenSER)
I thought the project was just OpenSER? What is Kamailio and OpenSIPS?
Kamailio is the new name adopted by the OpenSER project in August 2008 after running into name conflicts and/or trademark issues with one or more undisclosed parties. Presumably those parties had preexisting identities or product names containing the particle "SER."
In an unrelated turn of events some time shortly thereafter, the new project was forked. Bogdan-Andrei Iancu of Voice System, who was one of the personalities behind the original SER/OpenSER fork in 2005 and a leading code contributor, started a new fork of the Kamailio code base called OpenSIPS. Most of the remaining actors in the development team remained with Kamailio.
Should I use Kamailio or OpenSIPS?
At the time of this writing, there is no substantive difference between the two in terms of either new functionality or compatibility. That may not be the case indefinitely; if it were, the would not be much point to the fork.
Just about any answer to this question is presently a political one and may carry ad hominem weight that is additionally toxic in a commercial atmosphere that is already damaged by the name changes and the fork.
Nevertheless, we need to standardize our offering and process (just like any business), and consequently are put in the position of having to pick one -- like all other users of the former OpenSER.
Although we support both projects, we prefer, recommend and deploy Kamailio at this time. The primary reason for this is that we have an existing relationship with the development and project management team, and we believe they are doing a better job of building a stable, reliable business environment around the project that commercial adopters can count on. There are particular concerns of commercial users in large-scale environments that differentiate them from those of other kinds of users and are especially important for commercial use: quality control, graduated change control, backward compatibility, reliable support, and political stability.
What holds true for us and our clients may not hold true for other business organizations. Thus, we would like to refrain from making any recommendations based on technical criteria or other details. We have standardized upon Kamailio because we have good reason to believe it is in our best interest and that of our clients to use it long-term from a business perspective, and because we, along with the rest of the project ecosystem, were put in the awkward and uncomfortable position of having to make a choice. We do not find there to be a constructive case beyond that at this time.
Additionally, we would like to emphasize that both projects are completely open-source. Both projects liberally take patches from the other for bug fixes and feature enhancements, as those patches are all publicly accessible. In our view, the smart project team will exhibit better management characteristics while taking valuable innovation and bug fixes from the other in the long run.
Is there a resource or forum related specifically to integration of Asterisk and Kamailio/OpenSIPS?
Yes. We established and continue to operate the SER-Asterisk-Interwork mailing list.
Can Kamailio/OpenSIPS be used as a Session Border Controller (SBC)?
As with the question, "Is Asterisk a (soft)switch?," the answer largely depends on what exactly you expect of something that you would call an SBC.
Kamailio/OpenSIPS can be and is deployed as a user-facing point of entry at the edge of a SIP platform and can be used to provide security, enforce certain class of service restrictions, limit DoS exposure, and assist far-end NAT traversal. In this role, it can be likened to an SBC.
On the other hand, commercial SBCs typically have a back-to-back user agent (B2BUA) that enables additional subscriber features and topology hiding (i.e. not allowing your users to see upstream media and signaling hops). Topology hiding prevents user endpoints from having visibility into the internal architecture of your platform or gaining knowledge about your wholesale carrier and interconnection relationships. Kamailio/OpenSIPS is a SIP proxy, not a B2BUA (although some components of it hack on additional functionality that allows it to mimic user agent behaviour in a limited way, it is fundamentally and emphatically not a user agent).
The other key distinction of common commercial SBCs is that they handle media (RTP) as well as signaling (SIP). Higher-end ones can handle very large amounts of media streams concurrently using dedicated, embedded hardware designed for that purpose (ASICs). Kamailio/OpenSIPS is a SIP proxy only and does not handle media. However, it does provide integration with various media proxies (which can reside on other machines), some of which are quite economical to deploy in farms of commodity hardware as compared to the cost of a proprietary SBC.
It is probably accurate to characterise Kamailio/OpenSIPS as something suitable for "lightweight SBC" duty. It is not the same thing as a high-end commercial SBC. Of course, it doesn't mean that it is impossible to do with it what you might otherwise do with such an SBC, just that it is not an apples-to-apples equivalent.
Do I have to use a media proxy with Kamailio/OpenSIPS for a far-end NAT traversal solution?
Not necessarily, although it may be desirable in various cases for reasons having to do with accounting or topology hiding.
Use of a media proxy is strictly necessary only in cases where there is no logical network-layer reachability between the media endpoints of a SIP session. An example would be media passing between a public and a private (RFC1918) address space with no NAT on the private side, and a SIP proxy that is connected to both; there is no way for the public endpoint to address the private endpoint.
NAT-traversal fixups revolve around substituting received IP and port information (Layer 3 & 4) in place of that provided by the endpoints themselves. If the endpoints can reach each other at the rewritten coordinates, there is no reason to proxy the media.
I'm a carrier; can I use some combination of Asterisk and Kamailio/OpenSIPS in place of a traditional switch?
It depends on what you are looking for in a switch. If all you need to do is route calls between SIP endpoints and over SIP trunks, it is quite possible -- depending on the exact intended application.
As the telecom world evolves further toward adoption of pure SIP in the network core, it is likely that the answer will slowly become "yes" in more and more situations.
If the question is specifically framed in terms of a "traditional" telco switch, however, the answer is no. Despite the claims routinely made by companies that supposedly put out Asterisk "switches" and/or "carrier-grade Asterisk softswitches," Asterisk is not a "switch" in the way that carriers asking this type of question mean.
Kamailio/OpenSIPS is a SIP-only server and proxy; it is of limited relevance.
Please see:
The main ways in which Asterisk falls short of a "real" switch are:
- Lack of reliable high-density TDM interfaces.
- Lack of distributed/scalable architecture that separates signaling from bearer processing systemically.
- Lack of (large-scale, comprehensive) SS7 support.
However, you could definitely use Asterisk and Kamailio/OpenSIPS to replace some hitherto expensive and complicated components of your network, such as proprietary feature servers for voicemail and other subscriber line features. You can also use them at the network edge for things like private peering and least-cost routing.
Can I make Kamailio/OpenSIPS talk to a Session Border Controller (SBC)?
Absolutely.
Cisco voice / IOS
Can I use an AS5300/5400/5800 with Asterisk?
Yes. It's our PSTN gateway of choice.
Actually, you can use any Cisco equipment that supports a voice feature card, which includes most well-known router chassis.
Can I use a Cisco VoIP gateway to pass VoIP-to-VoIP (SIP-to-SIP) calls?
Generally No. They do not have a SIP back-to-back user agent (B2BUA).
Cisco VoIP gateways do support the "hairpinning" of TDM calls. So, you could, for example, route a call from one ISDN PRI interface to another. However, an incoming VoIP call must cross the VoIP-TDM horizon; if the call comes in as VoIP, it must leave the gateway as TDM.
Some Cisco voice gateway platforms (i.e. Cisco AS5400XM) can do SIP-to-SIP calls.