Section 13.8. Peer-by-Peer Codec Selection
13.8. Peer-by-Peer Codec SelectionJust as your VoIP network is affected by the design of the IP network it overlays, the IP network will be affected by the decisions you make at the higher layersespecially codec selection. Using a bandwidth-conserving codec on a WAN link is often mandatory to avoid swamping the link with excess voice utilization. In the same way, the less utilization you impose with each call, the more calls you can "squeeze" onto the link. But that doesn't mean your VoIP network will use a highly thrifty codec like G.729A in all circumstances. Processing requirements and sound quality degradation are prime reasons to use bulkier, noncompressed codecs instead of a compressed codec. On a fast Ethernet segment, where there's usually a glut of bandwidth, you can safely use G.711 (or G.722 for even higher quality) as your standard codec. The VoIP servers responsible for enforcing codec policy must therefore be programmed to select certain codecs for use in certain calls. Different vendors have different ways of doing this, but they have one thing in common: they all associate a list of allowed and prohibited codecs with each endpoint, port, or trunk. This way, you can force a group of phones in a remote office with limited WAN bandwidth to use a low-bandwidth codec, while still allowing local phones on the LAN to use a high-quality codec. 13.8.1. Controlling Codec Selection in Asterisk SIP PeersAsterisk's sip.conf file, in /etc/asterisk , contains entries for each SIP endpoint or trunk that can communicate with the Asterisk SIP server agent. Each entry can have multiple allow and disallow keywords, which indicate what codecs are to be used for each peer. The following configuration sets up a group of LAN phones and a group of remote, WAN-connected phones: [general] disallow=all allow=ulaw allow=g279 allow=speex [301] ; phone on same LAN as callerid="Jake" <301> context=Cleveland host=dynamic type=friend username=301 secret=browns [402] ; phone in remote location, connected by WAN disallow=all allow=g729 callerid="Maddie" <402> context=Maui host=dynamic type=friend username=402 secret=aloha
13.8.2. Directory ServicesDirectory services transform your VoIP network from a transport apparatus into a set of user -friendly voice applications. Without directory services, the network can do very little. Sure, you can make IP-to-IP phone calls, and you might not mind memorizing IP addresses instead of E.164 numbers or SIP URIs. But, of course, there's a better way to get hold of people. On the PSTN, that better way is the phone book: that yellow-paged tome that often doubles as a booster chair for toddlers or as a flattener of accidentally crumpled papers. But since transistors are cheaper to make than paper, the phone book has its digital equivalents. Many digital PBX systems add a centralized phone directory that can be accessed from their telephones. Those that offer voice mail also (usually) offer an interactive IVR directory that lets you find a person's extension number by keying in the dial-pad equivalent of the person's name . 13.8.2.1 Directory services: resolution and advertisingThere are two components to directory services in VoIP: resolution and advertising. Resolution translates already-known resource identifiers (like SIP URIs and E.164 numbers) in network layer identifiers (IP addresses and port numbers) so VoIP endpoints can communicate. Advertising tells callers what SIP URIs and E.164 numbers to use when they want to call somebody. It associates the resource identifier with the name of the party to be called. So resolution translates IDs into protocol-friendly addresses, like 10.3.4.10:5060, and advertising translates IDs into human-friendly addresses, like Bob and Pat. The reason for the distinction between these two concepts is so that you can implement them separately or together. Resolution and advertising can be codependent, as in a legacy PBX phone directory, or they can be independent, as in SIP URIs, wherein resolution is accomplished using DNS. Most legacy PBX systems force resolution and advertising to be codependent because the possibility of globally aware phone directories never existed before IP telephony. The PBX always relied upon the PSTN to properly route calls bound for foreign exchanges (resolution), and businesses always relied upon the phone company to publish a phone book for those foreign exchanges (advertising). In the same way, the private exchange publishes its own directory and routes its own calls independently of the rest of the world. Now that the Internet and private global networks are a viable alternative to the PSTN, global directory services are important, and resolution is separating from advertising. In IP telephony, resolution is the responsibility of DNS or some other distributed mechanism, leaving advertising as the true function of the PBX's directory, an LDAP (Lightweight Directory Access Protocol) server, or some other directory authority appointed by you, the VoIP adopter. This directory advertising service is the digital phone book, where your fingers do the walking. 13.8.2.2 Resolution of SIP URIs and E.164 numbersDifferent VoIP protocols handle resolution differently. For example, SIP provides for DNS resolution of its URIs, like HTTP. H.323, conversely, relies upon a gatekeeper for resolution of dialed numbers. A DNS tool like Dig can be used to resolve SIP URIs, while only an H.323 client can allow you to resolve E.164 numbers. A SIP URI can reach you anywhere in the world you're registered via the Internet, but an E.164 number is always tied to a particular H.323 zone. SIP URIs are globally unique, but H.323's extension numbers make no such provision. This poses an engineering challenge for H.323, especially on extremely large networks that are managed by several groups with independent authority over their own numbering within the greater network. Fortunately, large commercial implementations of H.323, like Avaya's MultiVantage and Nortel's Meridian platforms, do offer an in-phone directory that can be centrally maintained and object-based security measures for that directory. Still, SIP offers an open solution to a common problemuse DNS for distributed name resolution, and you don't have to maintain a closed, proprietary directory in order to let people locate one another. For H.323, another standard can provide similar functionality: ENUM. 13.8.2.3 ENUMENUM is the IETF's protocol for resolving E.164 telephone numbers via DNS. It can be used with all kinds of IP telephony endpoints, not just H.323. Its usefulness with H.323 is clear: it's the only way to globally resolve E.164 numbers using DNS. This frees H.323 from the PSTN, allowing it to be the basis of a global, Internet-based voice network. ENUM is described in RFC 2916. 13.8.2.4 DUNDiDistributed Universal Number Discovery is Digium's protocol for failure-resilient, decentralized resolution of phone numbers on VoIP networks. DUNDi uses a peer-to-peer protocol to dynamically discover how to reach users. A reference implementation of this newly developed protocol is available from Digium's public CVS server for Asterisk Versions 1.0 and higher. 13.8.2.5 AdvertisingIn VoIP, user resources like IP phones aren't callable unless you know what their resource identifiers or phone numbers are. You key the phone number into the IP phone, and then it (or your PBX) performs the resolution of the resource identifier. Once resolved, your IP phone knows how, at the network layer, to send and receive data to/from the called endpoint. But how do you know the resource ID of the person you're trying to call? The answer, as in the Yellow Pages, is simple: advertising. On the Web, you won't get far without a URL to begin your browsing. Without a URL, you can do nothing. But go to http://www.google.com, and suddenly the world is at your fingertips. Even though SIP URIs don't work in precisely the same fashion, the basic idea is the same: Google advertises the existence of URLs, making them browsable by you. In effect, Google is a phone book of the Internet. Building your own directory lets you advertise your voice resources within your private network. You may also advertise them to the outside world. It's possible to use LDAP as a directory server for large VoIP networks. You could allow anonymous access to your LDAP server from foreign networks so callers can browse your directory, but beware of the security risks.
Commercial directory services for VoIP don't tend to interoperate , but they are usually very slick and work well as long as you stick with a single vendor's PBX and phones. Cisco's AVVID architecture implements a directory system that is included with the CallManager softPBX. It uses XML to drive the displays and command buttons on the 7960/7970 SCCP phones to make an interactive, searchable directory of users and endpoints registered with the CallManager. Most high-end PBX vendors offer something similar.
 |
EAN: 2147483647
Pages: 172