Thursday

The H.323 Protocol Specification


The H.323 protocol suite allows dissimilar communication devices to communicate with each other. H.323 (which is implemented primarily at versions 4 and 5 as of the time of this writing) is a sometimes Byzantine international protocol published by the ITU that supports interoperability between differing vendor implementations of telephony and multimedia products across IP-based networks. H.323 entities provide for real-time audio, video, and/or data communications. Support for audio is mandatory; support for data and video is optional.
The H.323 specification defines four different H.323 entities as the functional units of a complete H.323 network (see Figure 1). These components of an H.323 system include endpoints (terminals), gateways, gatekeepers, and multipoint control units (MCUs).

 
Figure 1: H.323 Entities
Endpoints (telephones, softphones, IVRs, voice mail, video cameras, etc.) are typically devices that end-users interact with. MS Netmeeting is an example of an H.323 endpoint. Endpoints provide voice-only and/or multimedia such as video and real-time application collaboration.
Gateways handle signaling and media transport, and are optional components. Gateways typically serve as the interface to other types of networks such as ISDN, PSTN, or other H.323 systems. You can think of a gateway as providing “translation” functions. For example, an H.323 gateway will handle conversion of H.323 to SIP or H.323 to ISUP (ISUP (ISDN User Part) defines the interexchange signaling procedures for the trunk call control). Another way to think of this is that a gateway provides the interface between a packet-based network (e.g., a VoIP network) and a circuit-switched network (e.g., the PSTN). If a gatekeeper exists, VoIP gateways register with the gatekeeper and the gatekeeper finds the “best” gateway for a particular session.
Gatekeepers, which are also optional, handle address resolution and admission to the H.323 network. Its most important function is address translation between symbolic alias addresses and IP addresses. For example, in the presence of a gatekeeper, it is possible to call “Tom,” rather than 192.168.10.10. Gatekeepers also manage end points’ access to services, network resources, and optionally can provide additional services. They also monitor service usage and provide limited network bandwidth management. A gatekeeper is not required in an H.323 system. However, if a gatekeeper is present, terminals must make use of the services offered by gatekeepers. RAS defines these as address translation, admissions control, bandwidth control, and zone management. The gatekeeper and gateway functionalities are often present on a single physical device.
MCUs support multiparty conferencing between three or more endpoints. The H.323 standard allows for a variety of ad hoc conferencing scenarios, either centralized or decentralized.
Back-end servers (BES) are an important supplementary function in an H.323-based environment. BES may provide services for user authentication, service authorization, accounting, charging and billing, and other services. In a simple network, the gatekeeper or gateway provides such services.

Sunday

Frequently Asked Questions | PSTN Architecture


Q: Is the PSTN of today able to handle the demands of the customers and technology of the future?
A: The answer is yes, since telecommunications companies are always enhancing the PSTN by providing more affordable or fully featured services to their customers. These changes often increase reliability while adding the capacity to offer more services. Tomorrow’s PSTN is likely to have much more packet-based technology than ever imaged. Now communications companies are burying fiber-optic cable and installing broadband wireless antennas as additional ways to deliver rich bandwidth, and cable companies often have outside plant capabilities that rival that or the primary LEC.
Q: Why is fiber-optic cable a better delivery medium than coaxial cable or twisted pair mediums?
A: Fiber-optic cable allows carriers to deliver services farther from central offices and is not readily affected by lightning strikes like copper wire, though WDM can offer more capacity through a single fiber than a single CO could sustain in copper 15 years ago. Delivering services further from the central office allows carriers to condense network equipment, reduce service truck roll outs, and provide more service to more people for a cheaper cost. And the extra bandwidth increases the scope and range of network capabilities available to all of us.
Q: Has VoIP been used by carriers prior to end-user deployments?
A: Yes, for some time large carriers have used VoIP to deliver calls within their core networks for long distance and toll calls. Bringing the technology to the rest of us took some considerable planning, significant costs, and a vision that VoIP would be the next huge push in the delivery of voice traffic.
Q: Should I be worried about my carrier’s SS7 network?
A: In general, no. But as more carriers connect and that network moves from its own dedicated, dark fiber and on to shared IP networks, there should be more attention paid to security and associated SS7 standards. It’s not a problem yet, but if the standards and industry best practices aren’t ready to implement in a few years we could see some disastrous consequences.
Q: Can I really trust my caller ID?
A: Sure, about as much as you can trust your e-mail. It won’t lie to you every day but it’s not hard to fool if you’re determined.I’d like to try phone phreaking or blueboxing sometime.
Q: Where can I go to find out more?
A: First of all, just don’t do it. It’s way too easy to get caught, and most of the old techniques won’t work. If you’re determined, you won’t find it hard to get the information you’re looking for if you Google the right names. Personally, I think it’s more fun reading the history anyway.
Q: I heard that Kevin Poulsen still drives the Porsche 944 he nabbed from KIIS. Is that true?
A: According to several reports, he’s been spotted in a red Porsche from time to time.
Q: People that sell me network equipment are always telling me that “circuit” is dead. Is that really true?
A: Let’s put it this way: without a live circuit to run on, the Internet is dead. Any questions? P.S. Anyone who really knows about packet and circuit knows that they both need each other in the end.

Thursday

Solutions Fast Track | PSTN Architecture


  • Outside plant represents cabling, interfaces, and other infrastructure outside of the CO. F1 feeds the SAI and F2 typically connects directly to the subscriber drop cable. SONET or SDH rings sometimes are used to feed an SAI or provide connectivity between COs.
  • Frequency Division Multiplexing (FDM), an analog technology, was replaced with the more efficient and secure Time Division Multiplexing (TDM). TDM is used in various implementations throughout the communications industry.
  • The SS7 stack is similar to the OSI network model and through SIGTRAN standards can also operate over IP. Security measures should be taken with all PSTN signaling protocols.
  • Digital switches still need sophisticated circuit detection capabilities for call processing.
  • When making SIP-based calls through an ISP, one’s call may terminate several hundred miles away and not at the local central office.
  • SIP-to-SIP based calls happen entirely over IP networks. SIP-to-PSTN calls start on an IP network and then get handed off to the PSTN.
  • Use extreme caution around pre-SS7 signaling protocols like ITU-T 5 or R2 (also known as CCITT 5 or R2 because of their toll fraud potential.
  • Even with SS7, take precautions to limit potential damage from fraudulent or corrupted data that could arrive in your SS7 network from other carriers.
  • Do not use ANI or any other ISUP or QSIG information for authentication.

Sunday

PSTN Protocol Security


If you thought that PSTN protocols are more secure than the IP protocols riding on PSTN access circuits, then prepare to be shocked. In some respects, one of the greatest threats to the Internet is the PSTN itself.

SS7 and Other ITU-T Signaling Security

Despite the fact that ITU-T signaling protocols prior to SS7 are notoriously insecure, they continue to be deployed around the world along with older switching equipment that is vulnerable to toll fraud, eavesdropping, and other risks. If your VoIP system will be interfacing with such equipment, take countermeasures to reduce potential exposure and liability, set alarms, and review logs.
That is not to suggest that SS7 is particularly secure, but it is much harder for a subscriber to inject signaling into an SS7 network. That being said, the primary threat for SS7 networks are the peering arrangements (particularly among CLEC partners) for injection of false and/or fraudulent signaling and other messaging information. SS7 as currently defined does not have policy controls built in to address this issue. The risks and countermeasures were summarized quite well by the 3GPP SA WG3 Technical Specification Group in January 2000 for 3G TR 33.900 V1.2.0:
The security of the global SS7 network as a transport system for signaling messages e.g. authentication and supplementary services such as call forwarding is open to major compromise.
The problem with the current SS7 system is that messages can be altered, injected or deleted into the global SS7 networks in an uncontrolled manner. In the past, SS7 traffic was passed between major PTOs covered under treaty organization and the number of operators was relatively small and the risk of compromise was low
Networks are getting smaller and more numerous. Opportunities for unintentional mishaps will increase, as will the opportunities for hackers and other abusers of networks. With the increase in different types of operators and the increase in the number of interconnection circuits there is an ever-growing loss of control of security of the signaling networks.
There is also exponential growth in the use of interconnection between the telecommunication networks and the Internet. The IT community now has many protocol converters for conversion of SS7 data to IP, primarily for the transportation of voice and data over the IP networks. In addition new services such as those based on IN will lead to a growing use of the SS7 network for general data transfers.
There have been a number of incidents from accidental action, which have damaged a network. To date, there have been very few deliberate actions. The availability of cheap PC based equipment that can be used to access networks and the ready availability of access gateways on the Internet will lead to compromise of SS7 signaling and this will affect mobile operators.
The risk of attack has been recognized in the USA at the highest level of the President’s office indicating concern on SS7. It is understood that the T1, an American group is seriously considering the issue. For the network operator there is some policing of incoming signaling on most switches already, but this is dependent on the make of switch as well as on the way the switch is configured by operators.
Some engineering equipment is not substantially different from other advanced protocol analyzers in terms of its fraud potential, but is more intelligent and can be programmed more easily. The SS7 network as presently engineered is insecure. It is vitally important that network operators ensure that signaling screening of SS7 incoming messages takes place at the entry points to their networks and that operations and maintenance systems alert against unusual SS7 messages. There are a number of messages that can have a significant effect on the operation of the network and inappropriate messages should be controlled at entry point.
Network operators or network security engineers should on a regular basis carry out monitoring of signaling links for these inappropriate messages. In signing agreements with roaming partners and carrying out roaming testing, review of messages and also to seek appropriate confirmation that network operators are also screening incoming SS7 messages their networks to ensure that no rogue messages appear.
In summary there is no adequate security left in SS7. Mobile operators need to protect themselves from attack from hackers and inadvertent action that could stop a network or networks operating correctly.
Bottom line: Just because SS7 is harder for subscribers to crack doesn’t mean it is secure overall. SS7 peering in the PSTN is not nearly as robust as its BGP equivalent on the Internet, and this has the potential for dire consequences if it were to be exploited maliciously. It’s not yet clear if or how the ITU-T plans to address these concerns directly in a revision to SS7, although a T1S1 SS7 Security Standard was proposed at one time as part of an overall Study Group 17 (SG-17) effort. RFC 3788, Security Considerations for SIGTRAN protocols, was published by the Internet Engineering Task Force (IETF) in June 2004, and suggests the use of specific TLS and IPSEC profiles when using SS7 over IP, though it also notes that the “Peer To Peer” challenge still exists with SS7. The Network Interconnection Interoperability Forum (NIIF) within the Alliance for Telecommunications Industry Solutions (ATIS) has published many guidelines on the topic of secure interconnections (available to members or to the public for a fee). The good news is that unlike the Internet’s in-band signaling model, which is vulnerable to direct attack, the SS7 signaling network is out of band to the voice and data communication it carries.

ISUP and QSIG Security

Automatic Number Identification (ANI)-based security mechanisms can be spoofed in both directions, although some carriers claim to have clamped down on this practice (I'm not convinced this can be done). This can be used to create false Caller-ID data to subscribers. If your organization uses ANI to verify identity (as a very large credit card user has been known to do), you are asking for trouble. It’s only slightly more difficult than spoofing an e-mail address if you know what you’re doing, so tread carefully here.
Other ISUP and QSIG fields have similar problems, so be very careful with any trust assumptions you make with these protocols. Always assume that CLASS services like distinctive ringing, selective call acceptance, selective call forward, and so on will be fooled by ANI spoofing and similar ISUP or SSIG attacks.

Thursday

PSTN Call Flow


Now that we have discussed what makes up the PSTN, let’s put it all together and walk through a messaging sequence. Here we will start from a caller picking up the phone attempting to make a call. The flow will be broken down into off-hook, digit receipt, ring down, conversation, and on-hook sections. We will start by imagining someone (Party B) picking up the phone to make the call (to Party A, on the same CO switch). The following list outlines, in order, the actions performed by the network:
Party B picks up the phone, and the off-hook sequence begins:
  1. The off-hook state is detected by the switch (loop or ground start).
  2. The switch establishes the time slot and sends a dial tone on the voice path.
  3. The switch awaits digits pressed by Party B.
The digit receipt sequence is as follows:
  1. Party B dials digits on the touch pad.
  2. Each digit is received by the switch and sends a silence tone and starts Inter Digit Timer (IDT).
  3. IDT starts when the switch is awaiting a dialed digit and stops when the digit is pressed.
After Party B dials the last number, the ring down sequence begins:
  1. When the digit receipt stops (or when the maximum dialed digits are pressed), the switch sends the request to the called number to allocate a time slot.
  2. When the called switch allocates a time slot the path is switched to the call handler.
  3. Party A’s phone rings (unless it is already off-hook).
Parties A and B can begin their conversation after the following sequence of steps is completed:
  1. Party A picks up the phone.
  2. The switch receives an answered call indication (off-hook).
  3. The ring-down signals stop.
  4. Parties A and B are able to speak on the established voice path.
After the two parties finish their conversation, the on-hook sequence of steps begins:
  1. The conversation ends with either party hanging up the phone.
  2. The on-hook indication is received by switches on access networks.
  3. The switches release established paths (termination).
  4. The call is ended.
During each of these sections there is traffic traveling in both directions to keep the signal alive. There are numerous acknowledgement requests between the caller and their access network, and the two access networks and the called party and their network, to keep this communication path alive. Most of this traffic is happening along the voice path.
This book is about securing voice over Internet networks, so later in the book you will be introduced to a protocol called Session Initiation Protocol (SIP). Though it is early on in the text we will now walk through a SIP to PSTN call. Remember that PSTN is a voice network and the SIP is originating from a data-only network. We will follow the sections of off-hook, digit receipt, ring down, conversation, and on-hook. To better visualize this call sequence we will use the following illustration (see Figure 1) to help us. Party A will be the SIP user and Party B will be the PSTN user.
 
Figure 1: SIP-to-PSTN Call Flow
Party A picks up the phone, and the off-hook sequence begins:
  1. Party A picks up the phone and dials the number.
  2. An off-hook state is noticed by the SIP client.
  3. The SIP client sends a request to the SIP proxy (at ISP).
  4. The SIP client sends the SIP tel URL with the request.
  5. ISUP message is prepared by the ISP PSTN Gateway.
  6. The ISP Proxy finds the local terminating PSTN to send the call through (Network PSTN Gateway NGW).
The digit receipt sequence of steps begins:
  1. Since Party A already sent the entire dialed number through the SIP phone prior to the call being sent through the Network PSTN Gateway, all the dial information is already there, so when the call is sent to the PSTN the switches already have all the information they need to process and route the call (i.e., no overlap sending is required).
  2. This is sent through ISUP Messaging by the ISP PSTN Gateway.
Now, the ring down sequence begins:
  1. Party A’s switch establishes a one-way voice path.
  2. Party A’s switch sends a ringing tone.
  3. At the same time, Party B’s switch is establishing its voice path.
  4. Party B’s switch completes the set up.
  5. Party B’s phone rings.
Parties A and B can begin their conversation after the following sequence of steps is completed:
  1. Party B picks up the phone.
  2. Switches receive an answered call indication.
  3. Party A’s switch sets communication to bidirectional.
  4. Parties A and B are able to speak on the established voice path.
When the two parties end their conversation, the on-hook sequence of steps begins:
  1. The conversation ends with Party A hanging up the phone.
  2. The SIP client sends a BYE message to Proxy at ISP.
  3. The ISP Proxy sends a BYE signal to NGW.
  4. Switches release established paths (termination).
  5. The call is ended.

Sunday

PSTN: Operational and Regulatory Issues


Public Telephone and Telegraph (PTT) organizations are the highest-level monopoly (or ex-monopoly) in each country, and generally are expected to comply with ITU-T standards for interoperability. Each PTT is regulated by its country of origin. In the United States, AT&T was broken up in 1982 into a long distance unit (AT&T as the Inter-exchange carrier (IXC) was authorized only to carry long distance traffic), and reorganized groups of regional Bell Operating Companies were given a limited Local Exchange Carrier (LEC) role that until recently prevented them from selling interstate (or interLATA) long distance services. Competitive LECs (CLECs), in spite of regulatory advantages, hold less than 10% of local lines.
Warning 
VoIP used for toll bypass is illegal in certain countries. Be sure you understand associated laws before implementing a VoIP system internationally.
As part of the AT&T breakup, 160 local access and transport areas (LATAs) were created around area code boundaries. Initially, LECs could not provide long distance service across and long distance companies could not provide local service, and some states have not removed these restrictions. Similar attempts to promote competitive services within specific countries are underway in various parts of the world.
Related Posts with Thumbnails

Link Exchange