Vous êtes sur la page 1sur 8

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.
2.
3.
4.
5.
5.1
5.2
5.3
5.4
6.
7.
8.

Introduction....................................................
Functional Overview.............................................
Session-Agent ACLI monitoring commands..........................
External-session-agent versus internal-session-agent............
Feature Descriptions............................................
Transport Address Determination.................................
Status Determination by pinging.................................
Constraint limiting.............................................
Privacy implementation..........................................
Normative References............................................
Authors Address................................................
Full Copyright Statement........................................

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-

1
2
2
3
3
4
4
6
7
7
7
7

TECH NOTE

Theory of the Session-agent

May 2011

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 INService 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-sessionagents) if they are not explicitly configured by the user. All sessionagents outside the home-realm subnet are external-session-agents If a
session-agent is defined with a realm-id * it is treated as a globalsession-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 allowanonymous 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 <hostname>

Show sipd group

Show sipd group v (for verbose output)

The various possible states for a session-agent are:

I: In-Service

520-0013-06

Acme Packet Proprietary and Confidential

Page 2 of 8

TECH NOTE

Theory of the Session-agent

O: Out-of-Service

D: Disabled

C: Constraints exceeded

S: Transitioning from O to I.

May 2011

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; externalproxy-address of ingress realm, home-address of ingress realm, externalproxy-address of egress realm, home-address of egress realm. Below are
the governing rules under which SIPD will check the featureset/constraints of external-session-agent versus that of internalsession-agent.

An external-session-agent defined with the same realm-id as the


internal-session-agent. If the call originates from the externalsession-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-sessionagent 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-sessionagent 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.

520-0013-06

Acme Packet Proprietary and Confidential

Page 3 of 8

TECH NOTE

Theory of the Session-agent

May 2011

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 ipaddress, 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 ipaddress 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 SRVrecord 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 pingmethod, 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

520-0013-06

Acme Packet Proprietary and Confidential

Page 4 of 8

TECH NOTE

Theory of the Session-agent

May 2011

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 sessionagent IN-Service on getting a response. A single ping transactiontimeout 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 homerealm-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 InService 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 nonping 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 sessionagent OOS. When set to 0, the SA will NOT be marked OOS based on nonping 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.

520-0013-06

Acme Packet Proprietary and Confidential

Page 5 of 8

TECH NOTE

Theory of the Session-agent

May 2011

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.

520-0013-06

Acme Packet Proprietary and Confidential

Page 6 of 8

TECH NOTE

5.4

Theory of the Session-agent

May 2011

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 PPreferred-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: akhindari@acmepacket.com marcher@acmepacket.com
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.

520-0013-06

Acme Packet Proprietary and Confidential

Page 7 of 8

TECH NOTE

Theory of the Session-agent

May 2011

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.

520-0013-06

Acme Packet Proprietary and Confidential

Page 8 of 8