7.3. Live ABC SBC Information

The Frafos ABC SBC allows to inspect its internal state in the administrative GUI.

7.3.1. Registration Cache

Registration Cache plays a significant role in off-loading registers, see Section Registration Caching and Handling for more details. The actual Content of the ABC SBC registration cache can be inspected using the web interface under the “Monitoring ‣ Registration cache” link, see Fig. Registration cache.


Figure 1: Registration cache

The following information is displayed for each entry:

  • AoR - Address of Record. SIP URI address that is associated with none, one or more user Contacts by the SIP registration procedure.
  • Contact-URI - Contact registered by the user agent and associated with an AoR.
  • Expires Value (registrar-side) - registration expiration at registrar side. This is the time when both the downstream registar and the ABC SBC will let the contact expire.
  • Expires Value (UA-side) - registration expiration at client (UA). This is the time when the ABC SBC expects the client to re-register. Failures to re-register timely are ignored to keep the client reachable even if it its re-registration procedure doesn’t work accurately. Because of REGISTER throttling feature (see Section Registrar off-load) the actual value may be different (earlier) from Expires Value at registrar-side.
  • Source IP - IP address where the REGISTER was received from
  • Source Port - port where the REGISTER was received from
  • User Agent - user agent identity (content of User-Agent header in REGISTER message)

7.3.2. Live Calls

“Monitoring ‣ Live calls” shows list of active calls, i.e. calls that have been forwarded and established. The calls appear there from the timepoint when a 200 SIP response is received from a downstream SIP element, till the call is terminated. Calls that are in so-called “early media” or “ringing” status do not show, neither are locally processed calls shown (e.g. calls processed using Onboard Conferencing).

Since the ABC SBC acts as a SIP B2B user agent, two call legs are shown for each established call:

  • A leg (originating leg) - SIP dialog established with caller
  • B leg (terminating leg) - SIP dialog established with callee.

Information displayed for each call leg include:

  • Source IP - IP address where the REGISTER was received from
  • Source Port - port where the REGISTER was received from
  • Call-id - SIP dialog identifier
  • Remote party - URI of remote party (equals the From URI for A leg and the To URI in case of B leg)
  • Remote target -Contact of remote party
  • Local party - Local URI.
  • Dialog state - Current state of the SIP dialog
  • Call start time - Time of call setup

The administrator can manually terminate the call using the “kill“ link and inspect call status details using the “Call Status Information” link.


Figure 2: Live Calls

7.3.3. Destination Blacklists

“Monitoring ‣ Destination Blacklists” shows IP addresses that have been found to be unresponsive. See section IP Blacklisting: Adaptive Availability Management to find out how to configure the ABC SBC to handle routing to unresponsive SIP destinations.

The Figure Screenshot: Destination Blacklists shows the user-interface for monitoring the unavailable IP addresses. It shows a single IP address and time-to-live to remain on the availability blacklist.


Figure 3: Screenshot: Destination Blacklists

7.3.4. User Recent Traffic

The ABC SBC always keeps track of the most recent SIP traffic. This is particularly useful when a problem is identified which doesn’t occur anymore and needs to be troubleshooted retro-actively. Another reason to look-back in this stored traffic is it includes even IP packets that are filtered at IP layer (see Section Police: Devising Security Rules in the ABC SBC) and cannot be troubleshooted at higher layers.

The administrative page “Monitoring ‣ User Recent Traffic” allows administrators to retrieve SIP traffic for a specific IP address. Also a secondary IP address can be included in which case packets matching either IP address will be retrieved. The retention policy for the stored traffic can be configured as shown in the Section PCAP Parameters.

To retrieve the SIP traffic, a user must choose the time interval within the availanle retention period (configuration of which is described in Section PCAP Parameters), IP address, and press the “Get PCAP file” button. Processing can take up to several minutes depending on the time interval chosen. The traffic comes in an archive in PCAP format along with TLS session keys that can be used to decrypt SIP traffic that came over TLS connections.

Wireshark can be used to inspect encrypted TLS traffic using the session keys, see the following link for a detailed HOWTO: https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/


Figure 4: Screenshot: User Recent Traffic