CAB-C.sdcs.6.j.pm

Net-Net Session Director Concepts

Copyright @ 2011 Acme Packet, Inc. sdcs.6.j.pm-1

Module Objectives



Topic 1: Realm and Realm BridgingThis section discusses realm and realm bridging. It will cover what a realm and realm bridging is, and what realm bridging models are.



RealmsA 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.



Realm BridgingThe 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.



Before Session Border ControllersCarriers 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 provider’s service infrastructure and customer and supplier relationships.



Peering ArchitectureCarriers 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 provider’s 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 Net-Net 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 customer’s 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.



Access-Backbone ArchitectureThe 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 provider’s 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.



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 Vendor’s 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



ModelsModels 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 SIP-NAT, 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 templatedfoundation to allow overlay configuration with minimal disruption.

• Compatibility: working with other popular devices in carriers’ VoIP networks.



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.



Realm Bridging Models – H.323As 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.



Realm ConfigurationRealms 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.





Review: Topic 1 – Realm and Realm BridgingAnswer 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?



Review: Topic 1 – Realm and Realm BridgingAnswer 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



Summary: Topic 1 – Realm and Realm BridgingThe 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.



Exercise 1: Configuring RealmsIn 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.



Topic 2: SIP Interfaces on the Net-Net SDThis section discusses SIP interfaces, signaling routing functions, and signaling translation functions.



Hardware Packet Walkthrough: Signaling PacketThe 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.



Enabling SIP Configuration on the Net-Net SDIn 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-to-end.

• 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.



SIP InterfaceThe 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.



SIP Interface ConfigurationSIP 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.



Example: SIP Interface ConfigurationThe 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 provider’s 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-interfaceelement, 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).



SIP Ports ConfigurationThe 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.





Review: Topic 2 – SIP Interfaces on the Net-Net SDAnswer 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?





SIP interface with SIP port


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


• 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.






• What are the functions of a SIP Interface?


• How many SIP interfaces can be configured per realm?





SIP interface with SIP port


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


• 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.



Summary: Topic 2 – SIP InterfacesSIP 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.



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



Topic 3: Media Services on Net-Net SDThis section covers media proxy function, media manager configuration, steering pool and its configuration, and RTP session-based call admission control.



Media Proxy FunctionThe 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.



Hardware Packet Walkthrough: Media PacketRTP 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 exception—CAM 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.



Media Manager ConfigurationThe 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.



Steering PoolsSteering 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.



Steering Pool ConfigurationThe 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 end-port 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 Net-Net 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 element’s 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.



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.





Review: Topic 3 – Media Services on the Net-Net SDAnswer the following questions to see how much you have learned from this section.

• The Net-Net SD’s 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?



Review: Topic 3 – Media Services on the Net-Net SDAnswer the following questions to see how much you have learned from this section.

• The Net-Net SD’s 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



Summary: Topic 3 – Media ServicesIn 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.



Exercise 3: Configuring Media ServicesIn 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.



Topic 4: SIP Services on the Net-Net SDThe 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 local-policy configuration element.



Local PolicyThe 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.



Example: Local Policy ConfigurationThe example on the slide shows a local policy configuration.



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.



Example: Complete RulesetThe 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.



Session AgentsA 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.



Session Agent ConfigurationThe 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.



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.



Session Agent Group ConfigurationThe strategy field identifies the session agent allocation options for the session-agent-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 max-sessions 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.





Review: Topic 4 – SIP Services on the Net-Net SDAnswer 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?



Review: Topic 4 – SIP Services on the Net-Net SDAnswer 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



Summary: Topic 4 – SIP Services on the Net-Net SDIn 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.



Module Summary - 1In 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)



Module Summary – 2This 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.



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.



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



Documents

CAB-C.sdcs.6.j.pm