Published via Inbox: 2013-05-15 13:57:25
May 15, 2013 06:56
Table Of ContentsIP Communication Solution for Group Applications Configuration Example||Introduction||Prerequisites||Requirements||Components Used||Related Products||Conventions||Configure||Network Diagram||Configurations||Cisco 3845 Router||Verify||Verification Screens: Examples||Cisco CallManager Screen Examples||Cisco CME Screen Examples||Cisco Unity Express Screen Examples||Troubleshoot||Troubleshooting Reference Documents and Commands||Related Information
Deploying SIP trunking can be a big step towards simplifying your organization’s telecommunications and towards preparing for the latest real-time communications enhancements, but the biggest motivation for most organizations is immediate and substantial cost savings.||Save money on long distance serviceLong distance service typically costs significantly less with a SIP trunk connection.||Eliminate IP-PSTN gateways (or even your entire PBX)Because SIP trunks connect directly to your ITSP without traversing the publicly switched telephone network, you can get rid of IP-PSTN gateways and their attendant cost and complexity. Some ITSPs will even host a PBX for you, taking over both the PBX hardware and user administration if you choose, with substantial cost savings from reduced complexity, maintenance, and administration.||Eliminate a redundant networkDeploying SIP trunking is a logical step towards the goal of having a single, IP-based network, rather than redundant telephone and data networks.||Eliminate BRI and PRI subscription feesWith a SIP trunk connected directly to an Internet telephony service provider, you can dispense with costly BRIs and PRIs, replacing them with service that can cost significantly less. Furthermore, with SIP trunking you don’t need to buy lines in blocks of 24 or 32. Instead, you can buy the bandwidth you need, in smaller increments, and at better prices.||Extend the capabilities of Office Communications Server with new services from ITSPsWith a SIP trunk in place, you can extend existing capabilities with additional services, such as E9-1-1 emergency calling. In the future, we expect ITSPs will to new services, such as greater integration with mobile phones and presence information on devices that are not running Office Communicator.
With increasingly wide applications of the IP multicast technology, many industries start using IP multicast as the solution for their application deployments. At the same time, the virtual private network (VPN) technology has become more and more popular. Currently, enterprise networks such as e-government networks and power data networks are almost all constructed based on the BGP/MPLS IP VPN architecture. In these networks, inter-department data isolation is achieved by setting different departments into different VPNs. Similarly, multicast services such as video conferencing and data sharing within a department also involve VPN-based data isolation. Therefore, the demands for multicast VPN are increasingly growing. However, RFC 4364 defines solutions for unicast VPN services only, without specific recommendations for the deployment of multicast VPN services. Therefore, how to deploy multicast services in the VPN environment is an urgent issue to be solved.||Internet service providers (ISPs) expect to provide multicast VPN services based on existing BGP/MPLS IP VPNs networks because this solution can fully leverage the multicast capability of the backbone networks and provide scalability. On the other hand, VPN users hope that the CE devices of each site establish PIM neighboring relationships only with the corresponding PE device but not the CE devices of a remote site, so that the VPN users can deploy multicast VPN without having to modify their network configurations or affecting the existing multicast implementations, such as the current PIM model, RP location, and RP discovery mechanism. In addition, implementation of multicast services in BGP/MPLS IP VPNs networks involves the following issues:
(1) Overlapped private network address spaces. A BGP/MPLS IP VPNs network allows overlapped private network address spaces. Therefore, the same multicast source and group addresses may be used by different VPN users, so the PEs need to forward the private network multicast traffic correctly to the users belonging to the same VPN.||(2) Public network supports for multicast. Private network multicast traffic is expected to be forwarded not only within the private network but also over the public network via multicast to reduce the load of the public network and thus to save the network bandwidth.||(3) RPF check on private network multicast data in the public network. Different from the forwarding mode in unicast, multicast packets are subject to an RPF check based on the multicast source address and the incoming interface. Only the multicast packets passing the check can be further forwarded. In BGP/MPLS IP VPNs networks, however, the P device in the public network cannot obtain the private network routing information, and thus cannot forward private network multicast traffic directly.||(4) Private network multicast traffic forwarding on demand. A VPN comprises multiple sites, each of which connecting to a different PE. If not required by users in all sites, private network multicast traffic should be forwarded to only the specific PEs to reduce PE burden.||(5) Minimum changes to existing networks. As the BGP/MPLS IP VPN technology has been widely deployed, implementation of multicast services should bring minimum changes to the existing network to reduce the network construction cost.
