Acme Packet 4500Signaled sessions 40,000Media Sessions 16,000Transcoded Sessions 7,200IPSec Tunnels 200,000Route Table Size 2MUsing the platforms as Session Routers implies that no media is handled; the Session Router only processes signaling messages.Call Detail Records (CDRs)File System Related CommandsFormat: Bulds partitions with file-systems on a newly added hard disk drive.Unmount: Unmounts a partition or the whole hard drive so it can be removed.Mount: Mounts a newly inserted (or previously unmmounted) formatted hard disk drive.show space : Show available/max space of partition6100/6300/4600A conversation or a session is established by exchanging some call control information (signaling).Establishing a call means enabling the orderly, controlled, and predictable flow of "media"SIP RFC 3261The SIP (Layer 5,6 and 7):Provides the signaling plane of a session-based multimedia systemProvides establishment, control, and teardown of session, plus some services.Is agnostic to the media type the session uses.Is used together with other proptocols in order to form a complete communication system:SDP, RTP, DNS, HTTP, ENUM, RADIUS, DIAMETER.Is Request-Response model-based.Message are textual.Can be user over UDP, TCP or TLS transports.User Agent (UA)User Agent Client (UAC)User Agent Server (UAS)Basic SIP Entities: ServersProxy ServerProvide proxy services and message forwarding.RegistrarRegistrar end-points so they are known in a domain.Creates location database entries (bindings) of the form: [end-point identity + current IP-address:port]Back-to-Back User AgentA device that serves as a termination ppint for calls, processes them and re-originates them.Has "Isolation" effect, thus suitable for security and other value added services.SIP MessagesStructure ASCII-Based, (of both requests and responses):Star line = "Request Line" or "Status Line" (in responses)Header = Several lines called "Header Fields"Body = (Optional)Session Description Protocol (SDP)XML informationInstant messaging textOther dataThe start-line in a request contains a request Uniform Resource Identifier (request-URI):The request URI identifies the address where the request is sent to and is written in the form of user@host.The initial request-URI of the message should be set to the value of the URI in the "To" field.Several Header fields are normally found in a SIP message:"Via" header:Indicates the transport used for the transacion (transaction = request and all its related responses) and identifies the location where the response(s) to this request should be sent.The essence of the Via header field is to provide an IP address and port for responses."To" header:Specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request.Is informational and not used for routing decisions."From" header:Indicates the request initiators logical identity AOR in the form of user@host.Is informational and not used for routing decisions."Contact" header:Provides an IP address and port where the device directly receives request. (Location)"Call-ID":A string, made as random as possible, that identifies this call."CSeq":An integer and the method itself. This integer increases in each transaction in the dialog.INVITE sip:112125555@192.168.0.13:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.0.103:5070;branch=z9hG4bK-1880-1-0 From: sipp ;tag=1 To: sut Call-ID: 1-1880@192.168.0.103 CSeq: 1 INVITE Contact: sip:sipp@192.168.0.103:5070 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 137There is usually no "response to a response" but one exeption does exist: This is the ACK request that is sent in order to acknowledge the receipt of a successful response (200 OK) to an INVITE (session beginning) request.SIP RequestRequest DescriptionINVITE Indicates that a client is being invited to participate in a call sessionACK Confirms that the client has received a final response to an INVITE requestBYE Terminates a call and can be sent by either the caller o the calleeCANCEL Cancels any pending requestOPTIONS Queries the capabilities of serversREGISTER Registers the address listed in the To header field with a SIP server. To and From header fields contain the same AOR.SIP Responses---------------------------------------------------------------------Type Examples ||Non-Final 1xx Provisional 100 Trying|180 Ringing |183 Session in Progress |---------------------------------------------------------------------2xx Success 200 Ok |3xx Redirection 302 Moved Temporarily |Final 4xx Client Failure 403 Forbidden|404 Not found |5xx Server Failure 500 Server Internal Error |503 Service Unavailable |504 Server Time-out |6xx Global Failure 600 Busy Anywhere |604 Does Not Exist Anywhere |---------------------------------------------------------------------Session Description Protocol (RFC 4566): Defines media descriptionSIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent form the server to the cliente.If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response.The ACK for a 2xx response to an INVITE request is a separate transaction.Dialog:A dialog is a peer-to-peer relationship between two UAs that persists for some time.A dialog is established by SIP messages, such as a 2xx response to an INVITE request.A dialog is identified by a call identifier local tag, and a remote tag.Responses to the INVITE MessageContain the status line and most header fields that are copied from the request. The responding device has added the "To:"tag and (optionally) a display string. The 200 OK also provides the "Contact" information of the called device.Staless Proxy: Provides the normal forwarding functions but without any events or keeping any state information in its memory.Transaction-Stateful Proxy: Will track and mark all state transitions of a transaction. Uses "CSeq:" and the branch parameter (in the "Via:") to identify the transaction it is tracking.Dialog-Stateful Proxy: Keeps track of the whole dialog. The proxy needs to somehow "convince" the two devices to keep working through the proxy for the entire dialog. This is how it is done:The proxy adds a "Record-Route" header field with its own IP address and port to the request it relays. This tells the receiving device: "Route the next transactions through me".This addes header field is copied to the responses and propagates back to the initiating device. Now the initiating device too knows that it needs to route its next transactions through the proxy.The device that sends the next request will include a "Route:" header field with the proxy IP address and port and send it out. B2BUA can perform is translating exlicit IP addresses that appear in the SIP messages. B2BUA changes explicit IP addresses in the request-URI, Via: and Contact:. Often a device add its own IP to the Call-ID string to improve its uniqueness. The B2BUA hides that IP address too by generating a brand new Call-ID.B2BUA re-originated SIP messages, B2B isolates betwenn SIP enviorenments.Session Border ControllersSession Border Controllers are session-sware devices that enable control of end-to-end, interactive communications across IP network borders.Session: Any real-time, interactive voice, video, or multimedia communication using IP signaling protocols.Border: IP-IP network borderControl: Functions spanning security, service reach maximization, SLA assurance, revenue and profit protection, and regulatory compliance. Interactive sessions.SBCs are the source and destination for all signaling messages and media streams coming into and leaving the providers network.Session-aware networking is our acrhitectural model for enabling high-quality, end-to-end interactive communications across IP networks.The SBC provides access-control, signaling constraints, and topology hiding/NPAT.The SBC interfaces to multiple networks. To each such network, it presents itself as a proxy for signaling and as a source/destination for media.SIPD application, which is a B2BUA, is the significant component. It is the termination point for an incoming session for which it will originate an outgoing session toward the final destionation. It will then bridge the two sessions while blocking information that needs to be blocked, translating information that needs to be translated, and letting other information items pass unchanged.Provides signaling proxy functions for SIP, H323, and MGCP/NCS protocols.Platforms Boot ProcessThe operation system is a suite of applications, services, and processes that use a real-time operating kernel. Bootloader code -> Inspects the boot parameters (residing in a NVRAM) -> Find out the Image file, and load it to the RAM -> The Kernel starts running and initializes the whole OS envioronment.Release Naming ConventionsS - SBC, SR, USM (Unified Session manager)E - ESBCP - Enterprise Communications BrokerM - Security GatewayL - Subscriber Aware Load BalancerC - 4250Cx - 3810/3820, 4500Cz - 4500, 4600, 6x00 and virtual machineD - 92004500 - SBC, ESBC, USM, SG, SLB, SR.Operating System Functions and ServicesMedia Control: Border gategar funtion, provides the interface bewteen IP transport domains for session media. Support the following:Dynamic access controlTopology hidingDynamic NAPT/NAT relayQoS markingUpstream and dowmnstrem bandwidth policingMedia supervision timersQoS measurementsDTMF extractionLawful intercept (CCC)Security Front End (SFE): TLS, DoS, Security hardware module (SSM) provides dedicated encryption.Resource and Bandwidth Control: The resource and bandwdth control function is responsible for enforcing bandwidth policies for admission control and controlling the opening and closing of media gates for bearer control.Signaling Services:SIP B2BUA/IMS P-CSCF/IMS I-BCFH.323 Gatekeeper and GatewaySIP-H.323 Inter-working ModuleMGCP/NCS b2b virtual gateway and call agentH.248 b2b virtual media gateway controller and gatewayNAT Relay: The NAT Relay functions provide application-layer gateway (ALG) services for non-multimedia protocols including TFTP, HTTP, and DNS.Routing Policy and Accounting: Routing all traffic to a well-known proxy or routing all trafiic from network A to Network B. Local routing policies work in conjuntion with DNS and ENYM to determine next-hop routing behavior.Call admission and routing decisions are based on a wide range of policies enabling advanced routing and traffic management capabilities.Accounting and QoS Reporting: Provides RADIUS CDRs that include accounting information and provides per-session QoS metrics.show features - Licensed feautures by typingshow version - OS image version by tipingshow version boot - Boot-loader version by typingACLI ModesUser modeSuper modeConfiguration mode - bootparam - media-manager - security - system - session-router - ntp-syncprompt-enabled enabledUp to five simultaneous Telnet/SSH session are supported. Configuration mode can be entered within only one session at any given time. (Multiple configuration session for training purposes)Bootparam: * Boot-related parameters. When changed, a rebbot is required.* If stored in a NVRAM, no explicit saving is required.System:* Elements of a global nature: system parameters, physical interfaces, network interfaces, and so on.Media-manager:* Media-related elements: media-manager, realm-config, steering-pools, and so on.Session-router:* Signaling-related elements, sip-config, sip-interface, session-agent, and so on.Security:* Security-related elements: certificates, IP-Sec, and so on.NTP-SYNC:* NTP servers configurationConfiguration Element:Is a logical grouping of parameters with values assigned to them.Can be multi-or-single-instance, parent element or subelement (nested) or bothGeneralAt any given time there are two configuration loaded in the SBCs RAM: The "Running" configuration that determines how the SBC provides its services and the "Editing" configuration which is initially identical to the running configuration an can be changed at any time without affecting the service.If changes where made in the editing config an have been saved in the dataDoc.gz file (Last Saved Configuration). Now the two configs in the RAM are different, but kept in non-volatile files. When the SBC is rebooted the editing configuration RAM area will be loaded from the dataDoc.gz and the running config RAM area will be loaded from the dataDoc_nn.gz (Last Running Configuration) file.Lets assume that the last save config is now made to be the runn-config. The runn-config RAM area will now be overwritten with data from dataDoc-gz file. Upon the next reboot both editing and running configuration RAM areas will be loaded from the dataDoc.gz file.When an element is created (or modified) and the key you specified is alredy in use, "error 409" is displayed when done is issued.Flash File System display-current-cfg-version - to see configVer.datdisplay-running-cfg-version - to see runVer.datBackup operations on the SBC save backup copies of configurations, which are relatively xmall XML files.backup-config ! when all configuratiosn are syncbackup-config runningbackup-config editingbackup-config savedRestoring backup file is as if you manually created a new configuration in the Editing Configuration RAM area.restore-backup-config restore-backup-config save (dataDoc.gz)restore-backup-config running (dataDoc_nn.gz)display-backupsdelete-backup-config Clearing the Configurationdelete-config ! Configuration files in /code/gzConfig/ will be deleted, configuration version will reset to 1. The following will not change:Boot parametersLicensesPasswordsSystem data and time++++++++++++++++++++++++++++++++++++++++++++Create a Phy-interface for every physical interface to be used.Use the M naming conventionRemember to change operational-type to "media" for the media interfaces.A network-interface created on top of a media interface will only support VoIP protocols (SIP, H.323, RTP, MGCP/NCS).Network interfaces define the IP subnet, default gateway, VLAN, and other operational parameters.Network interfaces thar are bound to media phy-interfaces will only respond to VoIP protocols.Management protocol can be remporarily enabled.Media phy-interface RedundancyPhysical port redundancy is available when only two out the four ports are actively used.configure terminalsystem system-configlink-redundancy-state enableddoneexitexitexitswitch-redundancy-link 0 1 ! Switchover can be done manuallyLinks are sensed every 1 second.Configuration:phy-interface name M00 operation-type Media port 0 slot 0 virtual-mac admin-state enabled auto-negotiation enabled duplex-mode FULL speed 100 wancom-health-score 50 overload-protection disabled last-modified-by admin@127.0.0.1 last-modified-date 2015-10-08 15:50:27 network-interface name M00 sub-port-id 0 description Conexion to SoftPhone hostname ip-address 192.168.10.1 pri-utility-addr sec-utility-addr netmask 255.255.255.0 gateway 192.168.10.254 sec-gateway gw-heartbeat state disabled heartbeat 0 retry-count 0 retry-timeout 1 health-score 0 dns-ip-primary dns-ip-backup1 dns-ip-backup2 dns-domain dns-timeout 11 signaling-mtu 0 hip-ip-list 192.168.10.1 ftp-address icmp-address 192.168.10.1 snmp-address telnet-address ssh-address last-modified-by admin@127.0.0.1 last-modified-date 2015-10-08 15:57:26Realms and Realm BridgingA realm:Is a collection of VoIP entities residing in one or more networks.Typically maps to a SP, enterprise, or end-user population environment. It is defined by a configuration element that contains many parameters that apply to the enviorenment.Is considered as a "Layer 5" definition and a "container" of resources.Realm Bridging:Is the routing of a signaling messages coming from a given ingress realm to a "next hop" in an egress realmThe routing rules (routes, relative cost, and so on) are provided by either "Local-Policy" or "SIP-NAT" configuration elements.Static bridging: Ingress and egress realms are unconditionally "paired". Example: A->C; C->ADynamic bridging: Egress realm can be any, depending on time-of-day, called number, and so on.The object of the Oracle Communications SBC is to bridge realms either statically or dinamically.-------------------------------------------------------------------------------------------------------------------------------------------------------It is very important to remember that the SBC bridging decisions are based solely on information found in the signaling messages--never L3 information.-------------------------------------------------------------------------------------------------------------------------------------------------------Peering ModelThe peering model is generally characterized (and there are some exceptions) by the fact that no REGISTER requests traverse the SBC.This model is commonly configured in an SBC that resides between realms:SP - SPSP - its point-of-presenceSP - Served enterpriseAccess-Backbone ModelThe Access model generally characterized by the fact that endpoints send REGISTER request to a registrar that resides in a different realm.This model is normally configured in an SBC that resides between realms:SP - Served end-user populationEnterprise - Remote worker populationEnd users are registered at the service providers registrar.Realm Bridging Models for SIP|---------------------- SIP -----------------------|| |Peering/Trunking --------------------------------- Access/Remote Worker| | | | || | | | |Header Manipulation | Policy-Based| Single SIP-NATRules Realm bridging | Realm bridging |Homed in Access (HMRRB) | (PBRB)| Network (SSNHAN) | || | | |-----------------------| | Open-Access | Single SIP-NAT Internet (OAI) | Homed in Trusted SIP-NAT Bridge Network (SSNHTN) (SNB)PBRB: Simplest, most versatile, but not always capable of addressing all issuesHMRRB: Most cmmonly used in peering deploymentsSSNHTN: Used in many access deployments if HMRs do not work optimallySSNHAN and SNB: Archaic, no longer in common useRealm Bridging Models for H.323Peering/Trunking - B2BGK - B2BGWAccess/Remote Worker - Registration-Caching - Registration-ProxyCreating a Realm Configuration Elementrealm-config identifier core description addr-prefix 0.0.0.0 network-interfaces M10:0 mm-in-realm disabled mm-in-network enabled mm-same-ip enabled mm-in-system enabled bw-cac-non-mm disabled msm-release disabled max-bandwidth 0 fallback-bandwidth 0 max-priority-bandwidth 0 max-latency 0 max-jitter 0 max-packet-loss 0 observ-window-size 0The SBC configuration is very flexible: A realm can use a dedicated network-interface or share a network interface with other realms.SIP InterfacesThe sip-config element:Must be created in order for the SBC to handle SIP, is a global, single instance.The SIPD is the B2BUA application responsable for most of the SBCs signaling behavioral features.The SIP-Interface (The EDGE proxy function) is the SIP protocol stack and makes the SBC look like a SIP proxy.Receives and transmits SIP signaling messages, provides a service pipe to the SIP daemon (sipd).Define SIP signaling IP addresses, ports, transport protocols, and various SIP processing policies.sip-interface state enabled realm-id peer1 description sip-port address 192.168.10.1 port 5060 transport-protocol UDP tls-profile allow-anonymous all multi-home-addrs ims-aka-profile -----------------------------------------A realm can only have one sip-interface.-----------------------------------------show virtual-interfaces+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++SBC Media ServicesThe SBC media proxy, provides network address and port translation (NAPT) of media (RTP) packets coming from the ingress realm and going out to the egress realmThe media-manager-config ElementMust be created in order for the SBC to handle media, is a global, single-instance.Defines media handling state, latching, HNT, timers, traffic shapping, and so on.Latching: RTP source IP address will be taken from the first RTP packet rather from SDP body. When enabled, the SBC will "lock down" a flow upon receipt the first RTP packet at an allocated media port.The steering-pool:Is the SBCs media interface (for a given realm)Receives and transmits RTP packetsDefines a media IP address and pool (range) of ports from which port(s) are dynamically allocated for every established session.Provides call admission control (CAC) by setting a limit of session going into and out of a realmSteering pools define sets of ports that are used for steering media flows from one realm to another through the SBC, through the SDP body, will indicate to the device to send media there.In the rewritten SDP body, the SBC replace:The original IP address with the steering pools IP address.The original port with a port allocated from the pool.Steering Pool ConfigurationA steering-pool must be assigned to every realm in which media is handled by the SBC.----------------------------------------------------------------------------------------------------A steering pool can only be assigned to ONE realm. But a realm can have more than one steering pool.----------------------------------------------------------------------------------------------------Steering Pool-Based Call Admission ControlThe steering pool size limits the maximum number of current calls (incoming+outgoing) in a realm.A call can "consume" two or four UDP ports.steering-pool ip-address 192.168.10.1 start-port 20000 end-port 29999 realm-id peer1 network-interface last-modified-by admin@127.0.0.1 last-modified-date 2015-10-11 00:25:08++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Routing consists of:Identifying a SIP requests ingress realm,Applying relevant rules, andDetermining the egress realm and the destination in it where the re-originated SIP request will be sentIt is based on information in the SIP message, NOT on L3 information.SIPD SIP-NAT Local-PolicyRouting NO YESYES Static and limited Very FlexibleTranslation YES YESNO For request-URI For any Header Via, call-ID, ContactRoute, and record-routeonlyLocal PolicyLocal policy mechanism provides SIP and H.323 signaling routing based on:Ingress realmCalling and/or called number patternRoute priority (cost and availability time)Multiple local policies can be (and typically are) createdThe Local Policy configuration element contains:Matching criteriaZero or more "policy-attributes" subelements, each of which defines a "route"The SBC is ALWAYS able to determine the ingress realm by:* Looking through which network-interface then request arrived. If there is only one realm using that network-interface, then this is the ingress realm. Or...* Looking at the requests source IP address. If that IP is known as a session-agent, that session-agent belongs to the ingress realm looked for. If that doesnt work then...* Looking at the requests destination IP address. This IP address is the sip-interface that serves in ingress realm.Routing Decisiona. Determines the ingress realm (always possible)b. Look at all LPs configured for the ingress realmc. Ignores LPs that have no match to "From" and "To"d. Looks at all routes available at this time, in all remaining LPse. Then selects the route (using this procedence):1. With the lowest COST2. Matching MEDIA CODEC3. In the LP with the most specific TO ADDRESS match4. In the LP with the most specific FROM ADDRESS match5. With the narrowest DAY IN THE WEEK range6. With the narrowest TIME OF THE DAY range7. First configured in the LP that has FROM/TO set to *Session AgentIs an external signaling entity that the SBC interacts with Is known by the SBC through a corresponding configuration elementIs viewed by the SBC as as more "privileged" deviceBenefits of a SA:The SBC can apply constraints on signaling traffic to/from that device.The SBC can apply various translations and header manipulations to signaling messages to/from that deviceThe SBC can reject incoming signaling messages from other (non-SA) devicesIts name can be user as a next-hop in LPIt can be agruped with other SA in order to form a single logical entity (Think about redundancy and load-balancing)Session Agent Groups (SAG)is a single local element that refers to a group of functionally equivalent session agents.Individual constraints might differ for session agents in the group.Commonly used for load balancing, a session agent group can functions as a (single logical) next-hopThat way, traffic sent to this next hop can be load-balanced and never sent to a group member that is downThe load-balancing scheme can be set to:Hunt (First SA listed in the group that is responsive)Round-robinLeast-loadedPropdistLowsusrate++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Header Manipulation Rules (HMRs)Is an extremely powerful tool by which ANYTHING, in ANY header, can be manipulated.HMRs are based on the "sip-manipulation" configuration element, also referred to as a "rule set"A rule set contains "header rules"; a header rule may contain "elements rules"- A header rule "works" on an entire header- An element rule "works" on items within a specific header.When properly applied, a rule-set acts on SIP messages that go through:A session agent, orA realm, orA sip-interfaceA rule-set can be applied so it affects either inbound or outbound traffic, oir both.An element rule functions on a specific item that can be:A parameter - Example: ;tag=b5hsskkA non-parameter Example: +6182928-------------------------------------------------------Parameters in a header have the form ;=:Referenced by "name"Other items have various formsEasily referenced by predefined "types"--------------------------------------------------------"Applying Rule SetsFor an existing rule-set to function, it must be "applied" to:- A session-agent and/or- A realm and/or- A sip-interfaceDoing so also determines whether the rule-set will act upon incoming or outgoing SIP traffic-----------------------------------------------------------------SIP manipulations may be applied incoming (BEFORE REALM BRIDGING HAS OCURRED) or outgoing (AFTER REALM BRIDGING HAS OCCURRED)-----------------------------------------------------------------The header manipulation rules (HMR) mechanism is a key feature for interopeability.With HMR, any header and any element in a header can be added, replaced, or removed.Actions can be unconditional or taken on conditions that can be very simple to very complex.Rule sets can be tested by SBC commands before being applied.++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Peering PBRB ModelIs preerred because it:Provides the best performanceIs the simplest to configurePossible issues:Topology hinding is not guaranteed for all headers fieldsThe limitation of this model is that the topology is not completely hidden, simply because LP is a routing element and does not affect the SIP message "From:" and "To:" header fields. Those fields and more non-routing header-fields will go througth the SBC unchanged.steering pools -- realm-id, address, portssip-interfaces -- realm-id, address:port, transport protocolrealms -- id, net-intnetworl-interfaces -- MXX:Y, addressphysical-interfaces -- MXXsystem-config, sip-config, media-managerPeering HMRRB ModelThe Header Manipulation Rules Realm Bridging (HMRRB) model is the best in most deployments because it:Provides the best topology hiddingAllows any additional header manipulationPossible issues:The need to configure and test HMRs.SIP Peering Access ControlSIP peering access control is archived by configuring the combination odf address-prefix and allow-anonymousrealm-config identifier peer1 description addr-prefix 192.168.10.0/24 network-interfaces M00:0 mm-in-realm disabled mm-in-network enabled mm-same-ip enabled mm-in-system enabled bw-cac-non-mm disabled msm-release disabled sip-interface state enabled realm-id peer1 description sip-port address 192.168.10.1 port 5060 transport-protocol UDP tls-profile allow-anonymous realm-prefixThe SBC looks at the IP address in the "Via:" header field and checks wheter it matches the add-prefix pattern, The allow anonymous parameter, which can be set differently in each SIP port of a given SIP interface, acts like an "access mode" control.For more flexibility, more than one prefix can be set in a realm. This is done using the add-additional-prefix and remove-additional-prefix ACLI commands.Allow-anonymous Signaling Traffic allowed add-prefix all From any source Ignored agents-only From session-agents only Ignored (all other traffic is rejected) Realm-prefix From session-agents AND from Applied (should any source whose IP address be non-zero) matches the add-prefix in the realm-configConfigurationlocal-policy from-address * to-address * source-realm core description activate-time deactivate-time state enabled policy-priority none next-hop 192.168.10.254 realm peer1 action none terminate-recursion disabled app-protocol methods lookup single next-key last-modified-by admin@127.0.0.1 last-modified-date 2015-10-11 14:30:18local-policy from-address * to-address * source-realm peer1 description activate-time deactivate-time state enabled policy-priority none next-hop 172.16.0.100 realm core action none terminate-recursion disabled app-protocol methods lookup single next-key last-modified-by admin@127.0.0.1 last-modified-date 2015-10-11 14:29:39 sip-manipulation name NAT_IP description split-headers join-headers header-rule name To_hr header-name To action manipulate comparison-type case-sensitive msg-type request methods INVITE match-value new-value element-rule name To_er parameter-name type uri-host action replace match-val-type ip comparison-type case-sensitive match-value new-value $REMOTE_IP header-rule name From_hr header-name From action manipulate comparison-type case-sensitive msg-type request methods INVITE match-value new-value element-rule name From_er parameter-name type uri-host action replace match-val-type ip comparison-type case-sensitive match-value new-value $LOCAL_IP last-modified-by admin@127.0.0.1 last-modified-date 2015-10-11 15:16:09session-agent hostname phone-ivan ip-address 192.168.10.254 port 5060 state enabled app-protocol SIP app-type transport-method UDP realm-id peer1 sip-interface state enabled realm-id peer1 description sip-port address 192.168.10.1 port 5060 transport-protocol UDP tls-profile allow-anonymous agents-only multi-home-addrs ims-aka-profile ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Access-Backbone Configuration ModelsPolicy-Based Realm Bridging (PBRB) - preferredSingle SIP-NAT Homed in Trusted Network (SSNHTN) - provides additional topology hidingSingle SIP-NAT Homed in Access Network (SSNHAN) - very rarely usedSIP-NAT Bridge (SNB) - no longer being deployedAccess realm: A population of endpoints and proxies; some endpoints or proxies are behind a NAT device (for example, a firewall)Backbone realm: Proxies, registrars, SIP application servers, and gateways.The Access-backbone model is asymmetrical, in cntrast to the Peering model, which is symmetrical. A key differentiator of an Access-Backbone model is that REGISTER messages do cross the SBC.Access to Backbone - Local Policy or SIP-NATBackbone to Access - Registration CachingRegistration Caching: PurposeThe SBC maintains a cache with an entry for each endpoints so that it can:a. keep endpoint informationPhone numberIP address and port within the access realmWhether or not it is behind a NAT deviceIf yes, the NATed IP address and portb. Route requests from backbone realm to access realmCannot use local policies--too many next-hopsc. Efficiently handle endpoints and registrarsWhen the SBC receives a REGISTER request from an endpoint, it:a. Finds out whether the endpoints is behind a NAT deviceb. Re-originates a REGISTER request and sends it to the registrar in the backbone realmc. Receives from the registrar a 200 OK response with expires=x secondsd. Creates a registration cachinf entry for this endpointe. Re-originates the 200 OK response with expires=y seconds and sends it to the endpointshow sipd endoint-ipEnabling Registration CachingRegistration-caching is set per sip-interface (= per realm)If set to enabled:All endpoints will be cached when registeredIf set to disabled:Only endpoints behand NAT will be cached ! only if the nat-tranversal parameters ( is set to "always")session-router -> sip-interfaceRouting by registration cachingWhean A calls B:The SIP device puts Bs contact URI (from the local database) into the INVITEs start-lineThe SBC looks up the registration cache for this URIs user-pasrt and finds out the endpoints IP addressWhen A calls B:The SBC, by the default, will use the registration cache entry information and route the call through itself only.This is not always desirable.In order to have the SBC route the call to the SIP device, set the "route-to-registrar" parameter enabled, will not use the registration cache for routing, so any message will be routed to the SI device (normally using the LP mechanism).SIP Hosted NAT TraversalHNT is a technique that a carrier-hosted border device uses in order to provide persistent reachability for SIP endpoints located in private LANs behind NAT devices.Address issues of:Ip address and port inconsistencies between L3 and L4 and application Layer (SIP). This issue also applies to media IP addresses in the SDP body.Blocking IP packets considered by the NAT device as "unsolicited". This applies to signaling as well as to media.The SBC compares IP addresses in the IP packet and in the SIP message to find out whether the endpoints IP addresses has been NATed.Keeps all endpoints related IPa addresses and ports in the registration cache, including a flag indicating "behind NAT"Manipulates registration expiration time in order to make an endpoint re-register freuently, thus keeping the NAT device open for incoming calls.The SBC may uses "Adaptative HNT" to optimize for that.Media Laching (Media Addresses and ports issues)Two big issues:1. The initiators SDP body indicates to the other device to send its media to a destination that is unreachble2. Any media packet sent to the initiator will be rejected as unsolicited packet (no media port is open in the firewall)The SBC must wait until the first RTP packet is sentOnly then will the IP:port the media comes from be known and latched by the SBC.Is a mechanism by which the SBC will "lock down" a flow upon receipt of the first RTP pacjet at an allocated media port.Is always enabled when an endpoint is determined to be behind a NAT device.Symmetric LatchingIs defined as "symmetric" when:The endpoint is determined to be behind a NAT deviceMedia to the endpoint is sent by the SBC to the same IP:Port where it comes from (regardless of the IP:Port in the SDP body)Access PBRB ModelThe policy-based realm bridging (PBRB) model is preferred because it:Provides the best performanceIt the simplest to configurePossible issues:Topology hiding is not always guarantedendpoints should use domain-name-based AORs.It is common for the devices in the backbone to be configured as session agents. These devices are typically services providers registrars, proxies, switches, gateways, messaging systems, and son on.Some registrars will reject registration requests if the "To:" field does not include the backbone domain.Access SSNHTN ModelIt uses:PBRB:LP for access to backbone routingRegistration-caching backbone to access routingAnd in addition:SIP-NAT mechanismo for good topology hindingThe SIP-NAT environment involves:One home realmThe SBC is said to reside in this realmAny number of external realms thah can bePairs of peering realmsAccess realmsBackbone realmsA SIP-NAT configuration element per each external realm that provides static routing and topology hiding.In Access-backbone, the backbone realm is normally considered to be a "trusted network" (SP Network). Id the backbone realm in an Access-Backbone deployment is assigned as a home realm, then we have an HTN (Homed in Trusted Network) model. We can have several access realms (all externals)If the home realm is an access realm, , then we have an HAN (Home in access network). Here we are limited to one access realm, but we can have more than one backbone realm.If traffic is exchanged between peering external realms, it must cross the home realm. This path will be subject to two sip-nat translations (one for each external realm) and is called SNB (SIP NAT Bridging)If traffic is exchanged only between an external realm and the home realm, the path is only subject to one sip-translation ans is called SSN (Single SIP-NAT)SIP-NAT logical modelThe SIP-NAT element contains the IP addresses translations and the list of header subject to themExternal-proxy-address (EPA)External-address (EA)Home-address (HA)Home-proxy-address (HPA)session-router -> sip-nat+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Border Element Redundancy Protocol (BERP), interfaces wancom1 and wancom2 to checkpoint health, state, media flow, and signaling information.The HA cluster functioning is closely related to the alarm subsystem.