Sie sind auf Seite 1von 62

Net-Net Session Director Concepts

Module Objectives

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-1

Net-Net Session Director Concepts

Topic 1: Realm and Realm Bridging


This section discusses realm and realm bridging. It will cover what a realm and realm bridging is, and what realm bridging models are.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-2

Net-Net Session Director Concepts

Realms
A realm is a logical definition of a network or groups of networks made up in part by devices that provide real-time communication sessions comprised of signaling messages and potentially media flows. These network devices might be call agents, softswitches, SIP proxies, H.323 gatekeepers, IP PBXs, etc., that are statically defined by IP addresses. These network devices might also be IP endpoints: SIP phones, IADs, MAs, media gateways, etc., that are defined by an IP address prefix. On the Net-Net SD, you configure realms and their associated configuration objects to identify the interfaces, resources, and policies supporting signaling messages and media flows. All realms reference network interfaces on the Net-Net SD. This reference is made when you configure a list of network interfaces in the realm configuration. The process of the configuration is as follows: Configure a physical interface and network interface. Associate the network interface and therefore the associated physical interface to the realm. Configure a signaling port or ports for which the Net-Net SD will listen for signaling messages on and associate this port to a realm. Configure session agents that identify upstream and downstream signaling devices located in a realm. The purpose is to apply constraints for admission control as well as use these session agents for defining trusted sources to accept signaling messages. Session agent will discussed later in the course.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-3

Net-Net Session Director Concepts

Realm Bridging
The goal of the Net-Net SD is to bridge realms either statically or dynamically. When a SIP message is received on a SIP Interface, the Net-Net SD determines whether the originator is a member of the associated realm. Ingress realm membership is determined by the receiving signaling interface and associated realm prefix. Realm Bridging may be static or dynamic. Static realm bridging is a one to one association accomplished by using: SIP-NAT bridge (legacy configuration); H.323 stack association; Local policy; or Home realm default (SIP only). Dynamic realm bridging is a one to many association accomplished by either dynamic local policy (resolution to next signaling hop can be based on time-of-day, day-of-week, phone number, URI, domain, etc.) or third party routing/redirect.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-4

Net-Net Session Director Concepts

Before Session Border Controllers


Carriers are seeking ways to evolve their networks by interconnecting with other VoIP service providers over IP using SIP, H.323 or SIP-H.323 interworking as the signaling protocols. This relationship will provide new sources of termination and transit traffic and increase revenue for the service provider. Interconnecting over IP provides a more cost effective means of interconnection than TDM and opens additional opportunities for service providers to reach additional customers and markets. Peering networks create a secure virtual VoIP network between service providers as well as protecting the providers service infrastructure and customer and supplier relationships.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-5

Net-Net Session Director Concepts

Peering Architecture
Carriers are seeking ways to evolve their networks by interconnecting with other VoIP service providers over IP using SIP as the signaling protocol. This relationship will provide new sources of termination and transit traffic and increase revenue for the service provider. Interconnecting over IP provides a more cost effective means of interconnect than TDM and opens additional opportunities for service providers to reach additional customers and markets. Peering networks create a secure virtual VoIP network between service providers as well as protect the providers service infrastructure and customer and supplier relationships. In the peering model, security policies are applied to individual traffic flows to perform network layer abstraction via Network Address Translation (NAT), application layer abstraction via call signaling manipulation, and voice call traffic management. The NetNet SD uses a gateway method to achieve this goal where flows are terminated internal to the Net-Net SD and re-originated to their final destination. The Net-Net SD is deployed at the IP border between the customers core network and the transport network between their external peer and customer networks. The Net-Net SD terminates and re-originates VoIP signaling and media for sessions that traverse the network boundary and provides a number of critical border functions. This can also be categorized as a Network to Network Interface (NNI) solution.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-6

Net-Net Session Director Concepts

Access-Backbone Architecture
The access-backbone network solution focuses on the border point between the backbone network and the access network to deliver hosted IP interactive communication (IC) services to business, residential, or mobile subscribers. Hosted IP interactive communications services offer new revenue opportunities and in many cases presents access into new, otherwise unreachable markets. These services include a variety of subscriber-based services including IP Centrex, residential broadband VoIP, presence & instant calling, video services, gaming and more. Access network technologies include leased line, ATM, Frame Relay, DSL and Cable. Acme Packet Net-Net SDs provide the missing link needed to interconnect these different carriers and access networks, and provide the following service provider benefits: Protect providers service infrastructure and customer/supplier relationships; Overcome the NAT barrier to the delivery of high margin multimedia services; Guarantee capacity and quality on congested or oversubscribed access links/networks; Enable service provider to deliver and report on SLAs; Protect against bandwidth and QoS theft; Increase market reach and revenue by inter-working incompatible signaling; and Satisfy emerging law enforcement requirements. This is also known as a User Network Interface (UNI) solution.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-7

Net-Net Session Director Concepts

Architecture Implementations
The diagram in the slide presents an example of implementations of both SIP peering and access architectures, such as in an enterprise environment, i.e. an organization that maintains voice infrastructure for itself. The functions that the Net-Net SD performs are based on where the Net-Net SD resides in the network. SIP trunking/peering with service provider which typically defines a handoff of voice traffic to an external company, such as a service provider. SIP trunking/peering to branch offices with private network which provides traffic to diverse sites within the enterprise. Access-backbone with the Internet the most common application being an individual remote worker who must use the internet to reach the enterprise voice services. SIP trunking/peering for hosted services which typically includes external vendors who provide the enterprise with a service, such as contact center, as opposed to connectivity. The implementations of the peering and access architectures with the Net-Net SDs solve the following problems: Interworking issues, such as Vendors SIP interpretation issues and SIP and H.323 interworking Addresses security issues, such as IP border protection and encryption Enabling business continuity, such as data center disaster recovery, remote worker connectivity, remote site survivability. Regulatory compliance, such as lawful interception (LI) or emergency call handling

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-8

Net-Net Session Director Concepts

Models
Models are best practice configurations. The following aspects, in order of priority, are considered when selecting a model: Performance: minimizing the use of heavier configuration objects, such as SIPNAT, to streamline the message flow through the Net-Net SD and reduce CPU usage. By eliminating the use of SIP-NAT, the Net-Net SD reclaims some processing power. Flexibility: how resilient the configuration is, and how adaptable the configuration is when turning up new connected networks (for example). Scalability: minimizing redundant configuration objects and setting a templated foundation to allow overlay configuration with minimal disruption. Compatibility: working with other popular devices in carriers VoIP networks.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-9

Net-Net Session Director Concepts

Realm Bridging Models SIP


Some best practice configurations, or models, are suitable for either a peering or access architecture. There are a few that are not. Regardless of architecture, all use a subset of the available SIP routing and translation features from the Net-Net OS. In the next section we will be examining these features atomically. We will look at how they are combined in the specific models in a later module.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-10

Net-Net Session Director Concepts

Realm Bridging Models H.323


As with SIP there are two architectures for H.323, peering and access. The recommended peering configuration is the GW/GW model. Local policy will be used to bridge both realms, resembling the Policy-based Realm Bridging SIP configuration. For the access architecture there are two recommended models, registration caching and registration proxy. Registration caching is the most straightforward configuration and is the preferred mode when handling registrations from IP private branch exchanges (IP PBX). In this mode the Net-Net SD will aggregate terminal aliases under a single registration request (RRQ) towards the core gatekeeper (GK). When you configure the registration proxy feature by setting the q931 and dynamic ports in the core h323-stack, a unique RRQ is sent to the core GK per endpoint in the access network, and a different callSignallingAddress port is dynamically allocated for each registering endpoint. The range of dynamic ports for H.245 connections is also defined. In this mode the Net-Net SD passes most of the parameters in the RRQ transparently from access to core. Registrations are routed to the core according to the associated stack field of the access h323-stack. This model allows for 1-to-1 or many-to-1 access/core configurations.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-11

Net-Net Session Director Concepts

Realm Configuration
Realms are configured under the media-manager>realm-config branch of the ACLI hierarchy. The identifier parameter, i.e. the name of a realm, should be in lower case and unique, and indicate the relationship on the service provider border. Best Current Practice (BCP) Document 520-0006-00, Configuration Naming Conventions, states that if a realm represents a peering partner, that realm should be called access-[partner]. Its core side complement (for a VoIP bridging scenario) should be called core-[partner]. The -[partner] portion of the identifier is referred to as the realm suffix. In configurations where there is one core-side realm, it should be called core. In configurations where there is only one access-side realm, it should be called access. The network-interfaces parameter specifies the physical and network interface(s) that you want this realm to reference. These are the network interfaces through which this realm can be reached by ingress traffic, and through which this traffic exits the system as egress traffic. In the example on the slide, the realm peer is assigned to the network interface M00:0. One network interface may be bound to more than one realm, but one realm is only bound to a single network interface. The addr-prefix parameter, consisting of IP address and subnet mask, establishes a set of matching criteria for the realm, and distinguishes between realms that you assign to the same network interface. The default for this parameter is 0.0.0.0, meaning that all addresses match.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-12

Net-Net Session Director Concepts

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-13

Net-Net Session Director Concepts

Review: Topic 1 Realm and Realm Bridging


Answer the following questions to see how much you have learned from this section. What element is a Layer 5 logical definition of VoIP networks and container for set of their resources? Under which branch can we configure this element? Can multiple realms be bound to a single network interface? What architectures are supported for SIP and H.323? Is realm a grouping of a network or networks that can be comprised of multiple IP addresses?

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-14

Net-Net Session Director Concepts

Review: Topic 1 Realm and Realm Bridging


Answer the following questions to see how much you have learned from this section. What element is a layer 5 logical definition of VoIP networks and container for set of their resources? The element which is used for the Layer 5 logical definition and container is the realm. Under which branch can we configure this element? media-manager Can multiple realms be bound to a single network interface? Yes What architectures are supported for SIP and H.323? The architectures support by both SIP and H.323 are peering and access-backbone. Is realm a grouping of a network or networks that can be comprised of multiple IP addresses? Yes

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-15

Net-Net Session Director Concepts

Summary: Topic 1 Realm and Realm Bridging


The Net-Net SD, as an SBC provides session aware SIP, H.323, MGCP/NCS and H.248 routing policy and real-time constraints. Session routing and signaling functions control media access and feed the QoS performance monitoring function. The Net-Net SD also can act as a SIP edge proxy, B2BUA, or as a surrogate H.323 B2BGK/GW. The Net-Net SD provides routing and translation functions for all of the supported signaling and media protocols. Endpoints are logically segregated into a container called a realm. A primary function within the Net-Net SD is to provide for access control and realm bridging.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-16

Net-Net Session Director Concepts

Exercise 1: Configuring Realms


In this exercise, you will configure realms in the Net-Net SD needed for signaling. One realm is the peer realm, and one is the core realm. The configuration in this exercise will be built on top of the configuration completed in the pint lab.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-17

Net-Net Session Director Concepts

Topic 2: SIP Interfaces on the Net-Net SD


This section discusses SIP interfaces, signaling routing functions, and signaling translation functions.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-18

Net-Net Session Director Concepts

Hardware Packet Walkthrough: Signaling Packet


The Physical interface (PHY) cards perform Layer 2 checksum calculations on incoming packets, forward well formed frames to the Network Processor (nP) and drop damaged frames. The PHY cards are responsible for adding checksums to frames received from the nP and forwarding them onto the connected interface. The header from the received packet is examined to determine Ethernet type, protocol, if the packet is fragmented, transport protocol and application type. The network processor then builds a search key based on interface, VLAN tag, source IP, destination IP, protocol, source port, and destination port, with which it queries Content Addressable Memory (CAM). A resultant from the CAM query includes routing information. Cells are then forwarded to the traffic management subsystem. These cells are temporarily stored in resident memory until the traffic manager schedules them for egress transition to the host subsystem. The traffic manager is also responsible for performing flow metering and traffic shaping functions based on policing header results. Cells forwarded to the host subsystem for processing are subject to a lookup done in configuration to determine routing and translation functions. The host sub-system processes protocols such as VoIP protocols, SNMP, ICMP, TELNET, FTP, etc. Protocols such as G.711 (codec) and RTP/RTCP are not handled by the host.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-19

Net-Net Session Director Concepts

Enabling SIP Configuration on the Net-Net SD


In order for the Net-Net SD to support SIP, you must enable SIP configuration on the Net-Net SD. This is done in the sip-config element. sig-config is a single instance element that provides global SIP controls for the Net-Net SD. This element is RTC supported. In the sip-config element, you can enable or disable dialog transparency. Dialog transparency, enabled by default, prevents the Net-Net SD from generating unique call-IDs and modifying dialog tags. This preserves call identifiers end-toend. When dialog transparency is disabled, the Net-Net SD generates new call-IDs and inserts dialog cookies into the From and To tags of all messages it processes. These dialog cookies are in the format: SDxxxxxNN-. Using these cookies, the Net-Net SD can recognize the direction of a dialog. However, this behavior makes call transfers problematic because one Net-Net SDs Call-ID might not be properly decoded by another Net-Net SD. This can result in asymmetric header manipulation and failed call transfers.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-20

Net-Net Session Director Concepts

SIP Interface
The SIP-Interface defines both the target address that provides incoming SIP messages a service pipe to SIP daemon (sipd) for processing and policy for access to this service pipe. SIP interface performs SIP edge proxy function: Listening for SIP signaling on one or more configured IP addresses/ports/transport protocols within the network range of attached network interface. Providing service pipe to the SIP daemon (sipd), such as allowing incoming signaling packets to be presented to the SIP daemon (sipd) for processing. Providing policies for SIP processing Multiple SIP ports can be configured per SIP interface, but only one SIP interface per realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-21

Net-Net Session Director Concepts

SIP Interface Configuration


SIP interfaces define signaling addresses and characteristics on a per realm basis. These include SIP interface elements, which act as the signaling interface (service pipe) to the Net-Net SD B2BUA. Further, SIP interfaces contain one or more SIP ports, as sub-elements. SIP ports define the IP addresses/ports/transport protocols and access control policy for the SIP interface.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-22

Net-Net Session Director Concepts

Example: SIP Interface Configuration


The Net-Net SD is typically configured with at minimum two SIP interfaces: In a SIP peering environment, one SIP interface is for the peer realm, and the other is for the core realm. In a SIP access-backbone environment, one SIP interface is for the access realm and the other is for the service providers backbone realm. Each SIP interface may have a unique set of signaling and security attributes. In the sip-interface element, sip-port is a sub-element that provides the addressing component defined by the [IP] address, port number and transport protocol (UDP, TCP or TLS). Access policy is defined by the allow-anonymous property. Multiple sip-port elements may be associated with a singular sip-interface element, but only one sip-Interface is allowed per realm. Each sip-port may be defined independently of the others, with the only underlying requirement being that the IP address assigned must be within the network space for its realm, as defined by the bound network-interface(s) IP address(es) and subnet mask(s).

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-23

Net-Net Session Director Concepts

SIP Ports Configuration


The SIP port defines the IP address, port number and transport protocol to be used on the SIP interface. For each SIP interface, one or more SIP ports may be specified as follows: The address and port parameters specify static IP address and port number. A SIP interface may optionally be configured to listen on multiple port addresses (e.g., port 5060 plus multiple others). Every SIP interface is associated with a unique Realm ID and Network Interface (VLAN). The allow-anonymous parameter specifies the access control to the SIP interface for the realm. The SIP interface may optionally be configured to process requests only from registered endpoints, explicitly provisioned proxy servers, or devices that fall within a specified subnet. The values of the allow-anonymous parameter can be: all: allow all anonymous connections agents-only: only allow requests from session agents realm-prefix: allow requests from session agents and requests from the address that matches the realm prefix. registered: allow requests, such as INVITE, from session agents and from registered endpoints. REGISTER is allowed for any endpoint. register-prefix: allow requests, such as INVITE, from session agents and from registered endpoints. REGISTER only from session agents and endpoint whose address matches the realm prefix is allowed. The first SIP port listed will be selected as the source IP address for all messaging egressing the associated realm, although any SIP port may be the target for signaling ingressing the realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-24

Net-Net Session Director Concepts

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-25

Net-Net Session Director Concepts

Review: Topic 2 SIP Interfaces on the Net-Net SD


Answer the following questions to see how much you have learned from this section. What are the SIP virtual signaling interfaces in the Net-Net OS? What is the purpose of dialog transparency? What are the functions of a SIP Interface? How is a SIP interface bound to a realm? How many SIP interfaces can be configured per realm?

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-26

Net-Net Session Director Concepts

Review: Topic 2 SIP Interfaces on the Net-Net SD


Answer the following questions to see how much you have learned from this section. What are the SIP virtual signaling interfaces in the Net-Net OS? SIP interface with SIP port What is the purpose of dialog transparency? Determines whether the Net-Net SD will change CALL-IDs on re-originated messages. What are the functions of a SIP Interface? Sending and receiving for SIP processing Providing service pipe to SIP daemon (sipd) Providing policies for SIP processing How is a SIP interface bound to a realm? Using the realm-id parameter in the sip-interface element How many SIP interfaces can be configured per realm? Only one SIP interface is allowed per realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-27

Net-Net Session Director Concepts

Review: Topic 2 SIP Interfaces on the Net-Net SD


Answer the following questions to see how much you have learned from this section. What are the SIP virtual signaling interfaces in the Net-Net OS? What is the purpose of dialog transparency? What are the functions of a SIP Interface? How is a SIP interface bound to a realm? How many SIP interfaces can be configured per realm?

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-28

Net-Net Session Director Concepts

Review: Topic 2 SIP Interfaces on the Net-Net SD


Answer the following questions to see how much you have learned from this section. What are the SIP virtual signaling interfaces in the Net-Net OS? SIP interface with SIP port What is the purpose of dialog transparency? Determines whether the Net-Net SD will change CALL-IDs on re-originated messages. What are the functions of a SIP Interface? Sending and receiving for SIP processing Providing service pipe to SIP daemon (sipd) Providing policies for SIP processing How is a SIP interface bound to a realm? Using the realm-id parameter in the sip-interface element How many SIP interfaces can be configured per realm? Only one SIP interface is allowed per realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-29

Net-Net Session Director Concepts

Summary: Topic 2 SIP Interfaces


SIP interface performs SIP edge proxy function: Listening for SIP signaling on one or more configured IP addresses/ports/transport protocols within the network range of attached network interface Providing service pipe to the SIP daemon (sipd), such as allowing incoming signaling packets to be presented to the SIP daemon (sipd) for processing Providing policies for SIP processing Multiple SIP ports can be configured per SIP interface to allow multiple realms bound to one SIP interface. But only one SIP interface per realm. IP interface is configured in the sip-interface and sip-port elements.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-30

Net-Net Session Director Concepts

Exercise 2: Configuring SIP Interfaces


In this exercise, you will enable SIP configuration, and configure two SIP interfaces: one for the peer realm, and the other for the core realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-31

Net-Net Session Director Concepts

Topic 3: Media Services on Net-Net SD


This section covers media proxy function, media manager configuration, steering pool and its configuration, and RTP session-based call admission control.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-32

Net-Net Session Director Concepts

Media Proxy Function


The Net-Net SD media proxy function is responsible for NATting media between bridged realms. RTP processing is entirely hardware-based on the Net-Net SD.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-33

Net-Net Session Director Concepts

Hardware Packet Walkthrough: Media Packet


RTP processing is entirely hardware-based (the host subsystem is not involved). Received RTP packets are treated in the same way as signaling packets in the nP, with one exceptionCAM lookups must yield exact matches, or the RTP packet is dropped. These exact match entries are instantiated by the host subsystem based on successful call setup signaling.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-34

Net-Net Session Director Concepts

Media Manager Configuration


The media manager configuration is available from the media manager branch of the ACLI configuration tree. It is here that media-related characteristics, such as media latching, timers and traffic shaping behaviors are configured. Media latching determines how the Net-Net SD reacts to dynamic media flows. When it is enabled, the Net-Net SD will lock down a flow upon receipt of the first packet at an allocated media port on the Net-Net SD. HNT RTCP determines whether support of RTCP in the Net-Net SD is enabled when the Net-Net SD performs hosted NAT traversal. Details of media latching and HNT will be discussed in a later module.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-35

Net-Net Session Director Concepts

Steering Pools
Steering pools define sets of ports that are used for steering media flows from one realm to another, through the Net-Net SD. When the Net-Net SD is communicating with a SIP device in a specific realm defined by steering pool, it will use the IP address and port number (from pool of ports) to send media to. The port that the Net-Net SD chooses to use is identified in the Session Description Protocol (SDP) of the SIP message.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-36

Net-Net Session Director Concepts

Steering Pool Configuration


The steering-pool element allows you to provide a target IPv4 address, using the ip-address parameter, and a target port range, using the start-port and endport parameters, to steer the flow of media to a location defined by the SIP proxy. Any valid port range can be specified in the start-port and end-port parameters. When you plan steering pool port ranges, you should do the following: Take into account the total sessions available on the Net-Net SD, Determine how many ports these sessions will utilize per media stream Then, assign that number of ports to all of the steering pools on your Net-Net SD. This will allow for the maximum number of ports that you would need to use for the NetNet SD, but not use extra resources on ports that the Net-Net SD is never going to use. For example, if your Net-Net SD can accommodate 500 sessions and each session typically utilizes 2 ports per session, you should assign 1000 ports to each steering pool. The realm-id parameter contains the identifier of the steering-pool elements realm. This parameter is used to restrict the steering pool to only the flows that originate from this realm. This is a required field. In the example on the slide, the steering pool dictates that media coming from the realm named peer, will use the IP address 192.168.0.11 and some unused port in the pool of port numbers 20000-20999.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-37

Net-Net Session Director Concepts

Call Admission Control


You can configure admission control based on RTP flows through the Net-Net SD in the steering pool configuration. You set a valid UDP port range for RTP flows per IP address. You can set this range to be as large or small as the number of concurrent sessions (remember that one voice session uses two ports per steering pool) that you want to allow concurrently. This will also allow for the maximum number of ports that you would need to use for the Net-Net SD, but not use extra resources on ports that your Net-Net SD is never going to use. For example, if your Net-Net SD can accommodate 500 voice sessions and each session typically uses 2 ports (one for RTP and one for RTCP) per session, you should assign 1000 ports to each steering pool.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-38

Net-Net Session Director Concepts

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-39

Net-Net Session Director Concepts

Review: Topic 3 Media Services on the Net-Net SD


Answer the following questions to see how much you have learned from this section. The Net-Net SDs media proxy function is responsible for what task? What configuration element is used to define where media traffic is sent? What configuration element is used to globally disable or enable management of media traffic in the Net-Net SD ? What are steering pool ports used for?

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-40

Net-Net Session Director Concepts

Review: Topic 3 Media Services on the Net-Net SD


Answer the following questions to see how much you have learned from this section. The Net-Net SDs media proxy function is responsible for what task? The media proxy function in the Net-Net SD handles the NATting of the media or RTP traffic between the ingress and egress realms. What configuration element is used to define where media traffic is sent? The steering-pool element allows you to provide a target IPv4 address and a target port range to steer the flow of media to a location defined by the SIP proxy. What configuration element is used to globally disable or enable management of media traffic in the Net-Net SD ? The media manager What are steering pool ports used for? Steering media flows from one realm to another, and providing constraints on the number of concurrent RTP sessions allowed on the Net-Net SD

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-41

Net-Net Session Director Concepts

Summary: Topic 3 Media Services


In this section we discussed the information required by the Net-Net SD to process media flows. Further, we examined how the Net-Net SD gathers this information during call setup.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-42

Net-Net Session Director Concepts

Exercise 3: Configuring Media Services


In this exercise, you configure media-related elements: a media manager, and two steering pools, one for the peer realm and one for the core realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-43

Net-Net Session Director Concepts

Topic 4: SIP Services on the Net-Net SD


The Net-Net OS SIP daemon (sipd) acts as a back-to-back user agent (B2BUA), or logical entity that receives a request and processes it as a user agent server (UAS) in the ingress realm, while it acts as a user agent client (UAC) and generates requests in the egress realm. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. It is a concatenation of a UAC and UAS, terminating and re-originating calls. That means that, regardless of what other SIP features are configured, the Net-Net SD provides translation functions for the VIA, Contact, Call-ID, Route and Record-Route fields. Local policy provides the routing function only. Messages routed by way of local policy will receive translation treatment by sipd, but no more than that. As such, Local Policy based Realm Bridging is commonly used when topology hiding is not a priority, or when Domain Name (DN) based Address of Records (AOR) are used. Header Manipulation Rules (HMR) provide translation functions only. They specify how particular fields or values should be re-written. It is dependent on other SIP features to provide the routing function. In fact, it is commonly used in conjunction with the localpolicy configuration element.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-44

Net-Net Session Director Concepts

Local Policy
The local policy element is used to determine where session signaling messages (SIP or H.323 requests) are routed and/or forwarded. The called and calling party identifiers are matched with the content of the local-policy element within constraints set by the previous hop session-agent element to determine a set of applicable next-hop destinations. State and activation information about the local policy is stored in this element, as is information about source and destination address(es), the next hop server (i.e., destination), and policy attributes.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-45

Net-Net Session Director Concepts

Example: Local Policy Configuration


The example on the slide shows a local policy configuration.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-46

Net-Net Session Director Concepts

Header Manipulation Rules (HMR)


HMR allows the Net-Net SD to add, modify and delete SIP headers and header elements. HMR are configured as rulesets applied to session agents, realms or SIP interfaces inbound or outbound.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-47

Net-Net Session Director Concepts

Example: Complete Ruleset


The example on the slide presents a ruleset with From and To manipulations composed of previous two manipulation rules. By including both header rules in a single SIP manipulation ruleset, we may apply them both by attaching the ruleset to a session agent, realm, or a sip interface.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-48

Net-Net Session Director Concepts

Session Agents
A session agent defines an internal signaling endpoint. For each session agent, concurrent session capacity and rate attributes can be defined. A session agent functions as a single logical next hop for a signaling message, for example, where a SIP INVITE message is forwarded. In addition, session agents can provide information regarding next hops or previous hops. You use the session-agent element to describe one or more SIP next or previous hops. This element also allows you to set constraint parameters for specific hops.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-49

Net-Net Session Director Concepts

Session Agent Configuration


The hostname parameter acts as the unique identifier for the session agent and must be configured. This parameter may be populated with the domain name or IP address for a valid next hop SIP or H.323 signaling element. The ip-address parameter is the IP Address for the session agent if it is identified by an domain name. The port parameter represents the UDP/TCP port that the session agent is listening for signaling. Session agents may be taken in and out of service by toggling the state field between enabled and disabled. The app-protocol parameter specifies the signaling application protocol for the session agent. The transport-method field identifies what OSI Layer 4 transport protocol is going to be used in communicating with the session agent. The realm-id field signals which realm the session agent belongs to. This may be set to *, to indicate that the session agent may participate in all realms.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-50

Net-Net Session Director Concepts

Session Agent Group (SAG)


In addition to functioning as a single logical next hop for a signaling message, session agents can provide information regarding next hops or previous hops for packets in SAG agent, including providing a list of equivalent next hops. These session agents can also be bundled together to create session agent groups (SAG). A SAG is a group of session agents. SAG members are logically equivalent and can be used interchangeably. This allows for creation of constructs like hunt groups for application servers or gateways. Session agent groups are defined and allocation strategies are selected to achieve the desired load balancing. You use the session-agent-group element construct a session agent group.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-51

Net-Net Session Director Concepts

Session Agent Group Configuration


The strategy field identifies the session agent allocation options for the sessionagent-group element. Strategies are used to select the session agents that will be made available by this session-agent-group element. The strategy options include Hunt, RoundRobin, LeastBusy, PropDist, and LowSusRate. By default, the strategy field value is set to Hunt. The Hunt strategy selects session agents in the order in which they are listed. For example, if the first agent is online, working, and has not exceeded any of the defined constraints, then all traffic is sent to the first agent; if the first agent is offline or if it exceeds any defined constraint, the second agent is selected; if the first and second agents are offline or exceed any defined constraints, the third agent is selected, and so on. The Round Robin strategy selects each session agent in the order in which they are listed in the dest list. Each agent is selected in turn, one agent per session. The Least Busy strategy selects the session agent that has the fewest number of sessions relative to the max-outbound-sessions constraint or the maxsessions constraint (i.e., lowest percent busy) of the session-agent element. The PropDist (Proportional Distribution) strategy proportionally distributes the traffic among all of the available session-agent elements. The LowSusRate strategy routes traffic to the session agent with the lowest sustained rate of session initiations/invitations.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-52

Net-Net Session Director Concepts

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-53

Net-Net Session Director Concepts

Review: Topic 4 SIP Services on the Net-Net SD


Answer the following questions to see how much you have learned from this section. What elements can be configured to modify specific SIP Headers?

If external realms are private, is the home realm private or public?

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-54

Net-Net Session Director Concepts

Review: Topic 4 SIP Services on the Net-Net SD


Answer the following questions to see how much you have learned from this section. What elements can be configured to modify specific SIP Headers? Sip-manipulation If external realms are private, is the home realm private or public? Public

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-55

Net-Net Session Director Concepts

Summary: Topic 4 SIP Services on the Net-Net SD


In this section we discussed the signaling functions on the Net-Net SD. We focused on the SIP and H.323 virtual signaling interfaces, as well as the routing and translation functions provided in the Net-Net OS.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-56

Net-Net Session Director Concepts

Module Summary - 1
In this module we looked at the signaling services and features of the Net-Net OS on the Net-Net SD that provide routing and translation functions in support of realm bridging. We also examined media handling. The module also introduced realm bridging models. Topics covered in this module are as follows: Signaling Realms Realm bridging SIP interfaces Media services Local-policy Header manipulation rules SIP-NATs Session agents and session agent group (SAG)

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-57

Net-Net Session Director Concepts

Module Summary 2
This diagram shows the relationship between the physical interfaces, network interfaces, realms, and sip interfaces. More than one network interface can be bound to a single physical interface. More than one realm can be bound to a network interface. Only one SIP interface is allowed per realm. Multiple SIP ports can be configured per SIP interface, but only one SIP interface per realm.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-58

Net-Net Session Director Concepts

Module Summary 3
In this module, we configured realms, sip-interfaces, and steering-pools. This diagram shows how these objects and the phy-interface and network-interface are bounded together.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-59

Net-Net Session Director Concepts

Module Summary - 4
This diagram shows the relationship between a realm and other configuration objects.

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-60

Net-Net Session Director Concepts

Copyright @ 2011 Acme Packet, Inc.

sdcs.6.j.pm-61