520-0013-06 TECH NOTE Theory of the Session-Agent

TECH NOTE May 24, 2011 Document: 520-0013-06

A. Khindari/M. Archer Acme Packet, Inc.

Theory of the Session-agent

Status of this memo

Acme Packet Informational and Best Current Practices documents are working documents of the Professional Services department of Acme Packet, Inc. Note that other groups may also distribute working documents in the Informational category.

Informational and Best Current Practices documents are working documents valid until explicitly obsoleted, and may be updated, replaced or obsoleted by other documents at any time. It is recommended to use Informational documents as reference material as well as to cite them in other works in progress.

Applicability

This document is applicable to NN3000 (S-C610 & above), NN4000 (S-C600 & above) and NN9200 (S-D600 & above) series Session Directors.

Abstract

This document describes the function, features and expected behavior of the session-agent configuration objects. It is intended for all Session Director (SD) system administrators.

1. Introduction.................................................... 1 2. Functional Overview............................................. 2 3. Session-Agent ACLI monitoring commands.......................... 2 4. External-session-agent versus internal-session-agent............ 3 5. Feature Descriptions............................................ 3 5.1 Transport Address Determination................................. 4 5.2 Status Determination by pinging................................. 4 5.3 Constraint limiting............................................. 6 5.4 Privacy implementation.......................................... 7 6. Normative References............................................ 7 7. Authors Address................................................ 7 8. Full Copyright Statement........................................ 7

1. Introduction

Session Agent configuration object (hereafter Session-agent) defines a previous hop or next-hop in the network.

This document describes the usage, functionality and various features that can be enabled on a session-agent. Also, it will cover the monitoring aspects by covering the ACLI monitoring commands. A session-

TECH NOTE Theory of the Session-agent May 2011

520-0013-06 Acme Packet Proprietary and Confidential Page 2 of 8

agent can be defined for application protocols SIP and H.323. This document covers the session-agent defined for SIP protocol only.

2. Functional Overview

Session-Agent is essentially a building block of a network. It explicitly defines a previous hop or next-hop in a network. A session-agent configuration can be used for grooming traffic, rate limiting, security, routing, privacy, etc.

The configuration of a session-agent governs the means by which various constraints and other features are applied, overwriting the generic feature set defined in sip-interface or the realm to which it is associated. A session-agent is loaded at the time of a reboot or activate-config in a lookup-table. At this point session-agent is put IN-Service state by-default.

A session-agent can be the next-hop of a local-policy, any previous-hop, home-address, home-proxy-address or an Ext-proxy-address of a sip-nat. A session-agent which is the home-address of a sip-nat object is an internal-session-agent. The SD by default creates session-agents for home-address and home-proxy-address of all sip-nats (internal-session-agents) if they are not explicitly configured by the user. All session-agents outside the home-realm subnet are external-session-agents If a session-agent is defined with a realm-id * it is treated as a global-session-agent. Such a global-session-agent can be defined as a next-hop in various local-policies with different realm-ids.

Two or more session-agents can be associated to form a Session-agent group (SAG).

When an INVITE comes into the sip-interface, SD matches the previous-hop with an external-session-agent/global-session-agent. If the allow-anonymous is set to agents-only and the previous hop is not defined as a session-agent the call is rejected with a 403 Forbidden. If the previous hop is defined as a session-agent, then the SD checks for the constraints. If the constraints are not exceeded the private IP address space is natted and a next-hop is determined. The constraints are checked on the egress side external/internal session-agent as well. If the constraints are not exceeded the call is routed. If the constraints are exceeded at any point the call is appropriately rejected with a 503 Service Unavailable.

3. Session-Agent ACLI monitoring commands

The following ACLI commands can be used to monitor the session-agent status and statistics.

Show sipd agent Show sipd agent Show sipd group Show sipd group v (for verbose output)

The various possible states for a session-agent are: I: In-Service



O: Out-of-Service D: Disabled C: Constraints exceeded S: Transitioning from O to I.

4. External-session-agent versus internal-session-agent

Feature-set/Constraints can be defined on the ingress and/or egress side on either the external-session-agent or the internal-session-agent.

A peering SIP NAT bridge scenario can have 4 session-agents; external-proxy-address of ingress realm, home-address of ingress realm, external-proxy-address of egress realm, home-address of egress realm. Below are the governing rules under which SIPD will check the feature-set/constraints of external-session-agent versus that of internal-session-agent.

An external-session-agent defined with the same realm-id as the internal-session-agent. If the call originates from the external-session-agent, only it is taken into account and all the configured features and constraints are checked. If the call terminates on the external-session-agent, only it is taken into account and all the configured features and constraints are checked. The internal-session-agent is not checked at all. The output of the command show sipd agent will show call statistics for only the external-session-agent.

An external-session-agent defined with a different realm-id than the internal-session-agent. Only the internal-session-agent is taken into account and all the configured features and constraints are checked. The external-session-agent is not checked at all. The output of the command show sipd agent will show call statistics for only the internal-session-agent.

Only internal-session-agent is configured. No external-session-agent is defined. The internal-session-agent is taken into account and all the configured features and constraints are checked. This applies to both ingress and egress side. The output of the command show sipd agent will show call statistics for only the internal-session-agent.

Only external-session-agent is configured. Only the external-session-agent is taken into account and all the configured features and constraints are checked. This applies to both ingress and egress side. The output of the command show sipd agent will show call statistics for only the external-session-agent.

All of the above applies if external-session-agent/internal-session-agent is replaced by global-session-agent.

5. Feature Descriptions

The following sections describe major areas of Session Agent functionality. Features deemed adequately described in Acme Packets product Configuration Guides have not been included below.



5.1 Transport Address Determination The simplest and most static manner in which to determine the transport address (IP address and port) of a Session-agent is to configure the ip-address, transport-method and port objects directly. If however the network uses DNS, then depending on the level of information configured, the SD will use one of three DNS lookups to determine the transport address.

Firstly, if the transport-method (e.g. UDP) and port (e.g. 5060) are configured, but ip-address is left as 0.0.0.0 the SD will determine the IP address of the Session-agent via the result of a DNS A-record lookup using the configured hostname as the query name.

Secondly, if the transport-method (e.g. UDP) is configured, but ip-address and port are set to 0.0.0.0 and 0 respectively, the SD will determine the port of the Session-agent via the result of a DNS SRV-record lookup using the configured hostname prepended with _sip._udp as the query name. An A-record lookup will follow to determine the IP address.

Lastly, should the transport-method be set to UDP+TCP, and ip-address and port are set to 0.0.0.0 and 0 respectively, the SD will determine the transport type of the Session-agent via the contents of the DNS NAPTR-record response service field (e.g. SIP+D2U for UDP). Follow-on SRV-record and A-record lookups will determine port and IP address respectively1.

Valid SIP services for NAPTR records are described in [2] and listed on the IANA website at

http://www.iana.org/assignments/sip-table The SDs DNS cache can be queried with the ACLI show dns cache-entry command. Here is an example from the 3000/4000 Series SDs, hampden# show dns cache-entry core SRV:_sip._udp.opensips.selab.com

Query--> Q:SRV _sip._udp.opensips.selab.com ttl=217 Answers-->

prio=0 wgt=1 opensips.selab.com:5060/UDP hampden# show dns cache-entry core A:opensips.selab.com

Query--> Q:A opensips.selab.com ttl=134 Answers-->

172.16.50.101

5.2 Status Determination by pinging

A session-agent can be checked for its availability by enabling a ping-method, ping-send-mode and ping-interval. The ping method can be OPTIONS or INFO. The ping-send-mode can be set to keep-alive or continuous. When

1 This behavior will also determine a next-hop when a session agent is not explicitly defined where the egress sip-interface is configured for both TCP & UDP



the ping-send-mode is set to keep-alive, SD periodically (equal to the ping-interval) sends OPTIONS or INFO to this session-agent. A response to OPTIONS or INFO lets the SDs SIP proxy know that the agents SIP stack is functioning with the assumption being that it is therefore capable of receiving customer traffic. So, the SD keeps the session-agent IN-Service on getting a response. A single ping transaction-timeout causes the Session-agent to go OOS O, affecting the SDs route logic to avoid sending transactions to that agent until it is again capable of receiving new transactions.

Pings sent to global-session-agents will egress using the SIP home-realm-id (defined in sip-configuration). To override this behavior (if for example you are using a SIP NAT bridge using a loopback home realm), you may configure the egress-realm-id. This will force the pings to be sent through the sip-interface associated with the egress-realm.

When a session-agent is unable to respond to the OPTIONS message sent by the SD, SD retries several times before the transaction times out and the session-agent is marked OOS. In this re-try mechanism SD sends OPTIONS at 0 sec, .5 sec, 1 sec, 2 sec, 4 sec, 4 sec, 4 sec etc. until it reaches the trans-expire timer defined in the sip-configuration. In this above example 4 is equal to the max-timer in the sip-configuration.

When the SA is marked OOS, any further INVITEs intended FOR this SA are responded to with a 503 Service Unavailable message. At this point if the OOS SA sends an INVITE to the SD; with time-to-resume parameter defined the SD moves the SA to the state S which signifies the Transitioning state. Upon expiry of this timer the SA is moved to In-Service state. If time-to-resume parameter is not defined then on receipt of any SIP traffic from this OOS SA, SD moves it to the state S. After 1 sec, the SA moves to In-Service state . This is true for all SAs with hostname being an FQDN or an IP address. There are no behavioral differences between a FQDN or IP address Session Agent.

Acme Packets ping keep-alive function will suppress the transmission of OPTIONS ping if there is consistent traffic to the session-agent, for exactly this reason. If at least one INVITE going to that session-agent is answered, SD resets the ping-interval to the time the INVITE was sent and does not send out OPTIONS. The incoming traffic does not suppress sending out OPTIONS. OPTIONS are sent at stipulated time intervals equal to ping-interval. If an OPTIONS transaction fails and re-transmissions are on-going, at this time incoming traffic from this OOS SA marks the SA I. This postpones the retransmission of OPTIONS. When the incoming traffic stops, a second later the retransmission of OPTIONS resume. This time transmission of OPTIONS is dictated by something other than the ping-interval.

A session-agent can go OOS for a non-ping transaction timeout as well. When a session-agent is defined for OPTIONS ping, 10 consecutive non-ping transaction timeouts will mark the SA OOS. This default behavior can be changed by addition of an option trans-timeouts=X where X is the number of non-ping transaction timeouts that will mark the session-agent OOS. When set to 0, the SA will NOT be marked OOS based on non-ping transaction timeouts. The re-try mechanism until the transaction times out is same as mentioned above for OPTIONS. Next OPTIONS is sent at stipulated time intervals equal to ping-interval.



If no constraints and no ping method are configured (i.e. default at session agent creation), the SD will never consider this Session Agent as anything other than In-Service.

For essential reading on this topic including best practices for configuring SIP keepalives, see [1]

5.3 Constraint limiting

A session-agent can be configured for max-outbound-sessions, max-sessions, max-burst-rate and max-sustain-rate.

Max-outbound-sessions and max-sessions give the max number of allowed concurrent sessions.

The session-agent's "max-burst-rate" and "max-sustain-rate" are used to throttle the calls per second (CPS) of traffic sent to and by that session-agent. Each of these parameters has its own configurable window by which the statistics are gauged for constraint exceptions.

For the sustained-rate, the average is calculated over the previous window (equal to the sustained-rate-window) and current "window fragment." The "window fragment" will be between 0 and the configured sustained-rate-window upon receipt of an Invite. Once the window fragment increments and reaches the sustained-rate-window, this rotates and becomes the "previous window" -- and a new window fragment begins at 0. At this point all calculations are recalibrated accordingly.

For example if the sustain-rate is set to 15 and the sustain-rate-window is set to 10 seconds. When an invite is received the SD will add the amount of Invites received in the current window fragment and the previous window and divide by the number of seconds to get the average for that period. This average is then compared to the 15 cps derived from the sustain-rate and the sustain-rate window. If the Session-agent per the previous and current window is above 15 cps when the Invite is received, the Invite will be rejected.

The max-burst-rate and burst-rate-window interact by limiting the CPS rate for a burst of traffic over the window. Using your example below, with a max-burst-rate of 20 and a burst-rate-window of 10, the SD will permit 200 sessions within the first 10 seconds and then reject all new sessions until it exits constraint mode.

As for a session-agent in constraint, it does not come out of constraint mode when traffic drops below its constraint thresholds; it comes out of constraint mode after 60 seconds, unless a configured time-to-resume value dictates otherwise. Even though the session-agent is out of the constraint mode after time-to-resume seconds show sipd agent will show it back into In-Service mode only if the traffic flows to/from that session-agent.

On exceeding its constraint the session-agent is marked C.



5.4 Privacy implementation

The trust-me parameter in the session-agent makes it either trusted or un-trusted. It is used for privacy implementation based on RFC 3323 and 3325. The privacy implementation works as below unless pai-strip parameter is enabled in the realm-config.

If the ingress external/global-session-agent is trusted and privacy header is set to id, SD passes the P-asserted-identity header to the egress side.

If the egress external/global-session-agent is trusted and privacy header is set to id, SD passes the P-asserted-identity header.

If the ingress or egress external/global-session-agent is untrusted and privacy header is set to id, SD strips the P-asserted-identity header. The SD will also strip the Proxy-Require Header if its value is set to privacy. Also the SD will change the FROM field of SIP header to Anonymous. SD will also strip the Privacy Header.

If the ingress external/global-session-agent is trusted or the Privacy Header is not id and the request or the response contains the P-Preferred-Identity header, then SD will insert the P-Asserted-Identity header field with the value taken from the P-Preferred-Identity header field and shall delete the P-Preferred-Identity header value.

6. Normative References

[1] Timmons,P., Archer, M., SIP keepalive ping techniques, 520-0004-01

[2] Rosenburg,J., Schulzrinne, H., RFC3263 SIP: Locating SIP Servers

7. Authors Address

Anima Khindari/Marc Archer Acme Packet, Inc. 100 Crosby Dr Bedford, MA 01730

email: [email protected] [email protected]

8. Full Copyright Statement

Copyright Acme Packet (2011). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implantation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to Acme Packet or other referenced organizations, except as needed for the purpose of developing open standards.



The limited permissions granted above are perpetual and will not be revoked by Acme Packet or its successors or assigns.

This document and the information contained herein is provided on an AS IS basis and ACME PACKET DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Documents

520-0013-06 TECH NOTE Theory of the Session-Agent