Definitive MPLS Network Designs [Electronic resources] نسخه متنی

Figure 6-19. Managed Voice Service Deployment in Data Centers

Data Center Layer 3 MPLS VPN Design," the NAT and virtual firewall entity can ensure basic connectivity among the call managers and IP phones. However, this is insufficient to ensure proper VoIP signaling operations. VoIP signaling protocols encode IP addresses and port numbers inside the body of their messages to communicate those to other entities involved in VoIP signaling. (For example, the call manager tells an IP phone the IP address of the remote IP phone to transmit the voice stream to.) Although regular NAT operations would translate address and port information inside the IP packet headers, they would not automatically translate address and port information buried inside the VoIP signaling. That information would be received as sent and thus would be meaningless to the entity receiving the VoIP signaling message. This NAT- traversal problem is not specific to VoIP signaling. It is generic to any application involving signaling of address and port information. A common solution to this problem involves activation of an application-level gateway (ALG) on the NAT device. This ALG understands the specific protocol involved and performs the necessary translation of address and port information wherever it may appear inside the protocol messages. In the context of EuroBank, such an ALG has been activated on the NAT and firewall device to ensure proper VoIP signaling operation. This ALG supports the specific VoIP signaling protocol used by the call manager and IP phones in EuroBank.

We will now discuss in more detail how the VoIP Signaling ALG operates in conjunction with the call manager and VoIP signaling to achieve proper call handling in a EuroBank VPN as well as across VPNs.

On-Net Voice Call Within a EuroBank VPN

[SCCP] and Session Initiation Protocol (SIP); see [SIP].) However, the key conceptual steps generally include the following, as illustrated in Figures 6-20 and 6-21:

IP phone registering phase This is shown in Steps A and B in Figure 6-20. This phase happens whenever an IP phone boots. It contacts the call manager to indicate its presence and IP address.

When doing so, the IP phone encodes its "inside" address. The ALG intercepts this signaling message and replaces the inside IP address with a dynamically allocated outside IP address. The NAT and virtual firewall device stores the corresponding address/port translation state. The signaling messages finally reaches the call manager, which sees only an outside address for the registering telephone and which populates those outside addresses in its telephone number translation table.

Call signaling phase This phase happens when a user dials a telephone number on an IP phone.

The calling telephone conveys via VoIP signaling to the call manager the called telephone number as well as the (inside) IP address and port number it will use for the media stream (Step 1 in Figure 6-21).

The call manager looks up the called telephone number in its telephone number translation table, which returns the outside address of the called IP phone. (The translation table was populated in synchronization with the NAT and virtual firewall device, as discussed in the registering phase.)

The call manager sends a VoIP signaling message to the called IP phone (Step 2 in Figure 6-21), which includes the IP address and port as signaled by the calling telephone in Step 1 (hence, in inside format).

The ALG intercepts this message. Because it realizes that both the calling and called telephone are in the same "inside" domain, the ALG does not translate the IP addresses and port numbers in this signaling message.

The called telephone returns its inside IP address and port number to the call manager (Step 3 in Figure 6-21), which eventually signals those to the calling phone (Step 4 in Figure 6-21). Similarly, the ALG does not translate the (inside) IP address and port number encoded by the called telephone, because the calling telephone is in the same "inside" domain.

At this stage, both IP phones have been provided with the "inside" IP address and port number of the remote telephone. They can exchange the voice media streams directly with each other using those (Step 5 in Figure 6-21).

Hence, although signaling messages are exchanged between the shared VPN and a nonshared VPN (the UKI VPN in Figure 6-21) and they transit through the NAT and virtual firewall device (and its VoIP signaling ALG), the media stream travels directly from telephone to telephone inside the VPN without transiting through the NAT and virtual firewall device.

On-Net Voice Call Across Two EuroBank VPNs

Figure 6-22 illustrates the steps involved in establishing a voice call from IP phone 2 in the UKI VPN to IP phone 3 in the GerBank VPN.

The same signaling steps occur as those described previously for a call in a VPN. The key difference in the case of a call across VPNs is that the VoIP signaling ALG in the NAT and virtual firewall device realizes that the two telephones are not in the same VPN. Thus, it translates the "inside" address and ports signaled to the remote telephone in the body of the signaling messages into "outside" address and port. The net result is that each IP phone believes it is talking to an IP phone located in the Shared VPN, and the NAT and firewall device is responsible for performing the corresponding NAT function on the media stream. Note that the virtual firewall device allows communication only between two nonshared VPNs for flows explicitly recognized as properly signaled voice calls.

So, in the case of a voice call spanning multiple nonshared VPNs, signaling messages are again exchanged between the shared VPN and a nonshared VPN (the UKI VPN and GerBank VPN in Figure 6-22). They transit through the NAT and virtual firewall device (and its VoIP signaling ALG). However, the media stream travels between two nonshared VPNs via the NAT and virtual firewall device. This is how calls can be established between telephones located in different VPNs and using incompatible (and potentially overlapping) "inside" addresses and also without compromising the fundamental EuroBank requirement to isolate devices in different nonshared VPNs.

EuroBank considered another approach to integrate the Managed Telephony Service inside its environment. The idea was to create an additional VPN (a "voice VPN") in which to attach all the IP phones and call managers and that would be isolated from all the other devices. However, EuroBank dismissed this option because it could not cope with telephony applications that are not based on dedicated telephone hardware (such as softphone applications running on PCs, which EuroBank was considering deploying). Also, extending an additional VPN to every location raises serious issues for some locations, such as the branches connected via a managed VPN or Frame Relay network.

Layer 3 MPLS VPN Design Within PhoneNet and EuroBank Off-Net Voice Calls

Let's leave the EuroBank intranet environment for a moment and consider the infrastructure PhoneNet uses to build its Managed Voice Services for EuroBank as well as many other customers. PhoneNet chose MPLS and Layer 3 MPLS VPN technology as the basis for its VoIP infrastructure because it easily addresses PhoneNet's requirement for isolation across its many Voice Services customers. This technology also allows all these customers to access some PhoneNet shared resources such as media gateways and media gateway controllers providing interconnection to the PSTN.

This is achieved using the well-known rainbow VPN design. Rainbow VPN ensures that devices attached to that VPN can communicate with devices attached to VPNs of any "color"in other words, with devices attached to any VPN. In this design, the following rules are followed:

Each managed voice customer belongs to a separate VPN over the PhoneNet Layer 3 MPLS VPN network (such as EuroBank being supported as its own dedicated VPN over the PhoneNet network).

All the shared PhoneNet resources (PSTN media gateways and media gateway controllers) are attached inside a rainbow VPN.

All the routes in the rainbow VPN are redistributed into every Voice Services customer VPN.

All the (necessary) routes in every Voice Services customer VPN are redistributed into the rainbow VPN.

The two last points are very easily achieved through appropriate additional route target import and export statements at the PE routers.

Figure 6-23 shows the VPNs PhoneNet uses to support its managed Voice Services in this manner.