Diagnosing a troubled SIP call has a tendency to be a real pain. Whether it’s running wireshark, tcpdump, or collecting debugs, having to sort through duplicate packets and attempting to merge different pcap files together does not provide a simple way to troubleshoot a single call while looking at both sides of the call in a single ladder diagram.

Fortunately the Acme Packet SBC now includes a free tool embedded in the code that once enabled, allows it turns the SBC into a SIP capture device. The distinct advantage here is seeing both sides of a call in a single ladder diagram. Even better, extra (and very useful) information is included in between each step of the ladder diagram referencing internal “logic decisions” as they occur as traffic passes through the SBC.  Finding a particular capture is easy using Search Filters which allow you to specify just about any criteria.

Pop-up context provides tool tips and additional information about a call depending on what area you are hovering over. It is also possible to export a capture locally so it may be emailed and viewed by others  rather than having a variety of users logging into the SBC’s web interface. Alternatively, captures may be exported as ASCII text files with proper and readable formatting of the call information.

There are three main parts to viewing a captured call. The first is the Session Summary view which contains information such as source and destination IP addresses, URI’s, Realms, etc..

 

The second viewing pane is SIP Message Details. This is the actual ladder diagram and SBC events.

 

The third pane is for viewing QoS statistics such as jitter, packet loss, delay, and MOS scores for the specified call.

In order to enable web browser viewing of SIP Monitoring and Tracing the web server must be set to the enabled state.

ATL# configure terminal
ATL(configure)# system
ATL(system)# web-server-config
ATL(web-server-config)# state enabled

The next step is to create one or more filters. In the following example there is a filter called hostedIpPbx and in the user portion of the filter any SIP messages containing the phone number digits 781801 will be captured.

The next step is to enable sip-monitoring and identify which monitoring filter should be used. Applying the filter here enabled the filter globally on the system. Usually filters are best applied to specific realms or session agents (under monitoring-filters) to capture only interesting traffic.

In this particular network there are IP phones behind a Cisco ASA firewall which NAT to the public internet and need to register to a SIP softswitch which is being “hidden” behind the SBC in a Service Provider core network.

IP_Phone——Cisco_ASA——-[APKT_SBC_Public<>APKT_SBC_Private]—-SIP_Registrar
<–Customer_Prem->NAT>           <–SIP Monitoring and Tracing–>
192.168.1.198    72.12.135.253    72.12.135.250      10.12.135.250       10.12.135.140

Click on the image below to see a full screenshot from the SBC’s SIP Monitoring and Tracing tool showing a SIP phone behind the ASA registering to a SIP Registrar server. As you can see SM&T captures both the ingress and the egress side and displays into one simple ladder diagram. The Session Summary provides additional useful information specific to the SBC that would normally not be seen in 3rd party capture tools.

 

  1. Help says:

    I am trying to turn on the web server and under system it is not available. Do i have an older version? or do i need a license?

    COR(system)# web-server-config
    % command not found

  2. Mark says:

    SIP Monitoring and Tracing was released in version 6.3.9 which is available from their customer portal. It is supported on the 3800, 4500, and the (Linux based) Server Edition and VMWare editions!

  3. Help says:

    Thanks looks like we’ll need a upgrade of code.
    ACMECOR# sh ver
    ACME Net-Net 3800 Firmware SCX6.1.0 MR-4 Patch 2 (Build 682)
    Build Date=03/31/10

  4. Jerry says:

    Hi Mark,

    I am looking for a Voice SP solutions, i am hear about the broadworks, is that a great softswitch for Service Provider side? This is in addition with APKT 4500.

    Kind Regards

  5. Milan says:

    Hi,
    We are looking for the monitoring and reporting solution for our CUBE-SP.
    We need to monitor call statistics of our different adjacencies i.e total calls, successful calls, failed calls and call details.

    Do we have any solution for that?

  6. Mark says:

    The only platform I am aware of is from Secure Logix, but it is intended for fraud prevention by anlyzing call processing through CUBE. It’s not intended for troubleshooting call flows.

  7. Dirk says:

    Hi Mark,

    First I must say great site, it’s already been a helper for me ;-)

    My question towards you is about version NNSCX6.3.9 P7, whats your experience with the 6.3 releases? Are they stable enough?

    I’m very interested in the SIP trace/monitoring feature and I would like to implement this at our customer. They have NN3820′s with the current version NNSCX620M11P1, is it wise to step up to version 6.3.9 P7?

    Thanks,

    Dirk

  8. Mark says:

    Hi Dirk. 6.3.9p7 is very stable. Keep in mind there were different versions of 6.3.x before reaching 6.3.9, so it’s well baked.

  9. Dirk says:

    Thanks for the quick reply ;-)

    I’ve asked Acme Packet a few questions also, but did not receive a conclusive answer.
    So the field experience from others is well appreciated.

    Do you know what the base version was for version 6.3.9P7?
    We found an issue in 620M11P1 (tsipd crash due to null pointer exception Ticket 45111).
    Normally they will implement all fixes into new releases, however in the 6.3.9/6.3.x release there is no reference to previous issues.

    So that’s why we are in doubt for the release 6.3.9 P7. The feature set is very nice, but if we could encounter issues it’s not an option.

    Kind Regards,

    Dirk

  10. Jim Barber says:

    Hi Mark,

    Thank you so very much for putting this site up. It is a great resource and I am sure that many people appreciate it even if they do not voice it.

    I am trying to implement this for all sip calls. What would we use for a wild card that would represent all users? I have tried this:

    filter-config
    name All
    address 0.0.0.0
    user *
    sbc(filter-config)#

    And it does not seem to work. I enabled the filter but to no avail.

    sbc(sip-monitoring)# show
    sip-monitoring
    state enabled
    monitoring-filters All
    trigger-window 0
    sbc(sip-monitoring)#

    Any ideas?

  11. Mark says:

    Hi Jim,

    SIP Monitoring & Tracing isn’t specifically intended to capture all SIP traffic all the time. As the network grows, it will begin to consume more resources if the traffic gets heavy. That being said, in my lab, I created a monitoring-filter that I apply to the Core (private) realm of the SBC facing my SIP server. For example, if my SIP server is 10.12.135.140/24, I create a filter for 10.12.135.0/24. It doesn’t matter what Access realm the traffic comes in on, all traffic the has a next-hop to the Core realm and destined for network 10.12.135.0/24, the SBC will capture the SIP traffic and it’s viewable in SM&T. You can create multiple monitoring filters under filter-config, then go to the realm-config, and use the + symbol to add multiple filters to a single realm.

  12. Jim Barber says:

    Thanks,

    That is really cool. I will definitely look into creating the filters the way you suggest. As for why my captures were not working….

    I found the reason. Feel pretty sheepish now. I forgot to execute the actual capture.

    like so:

    sbc# capture start global *

    this command actually fires off the capture. Working fine now.

  13. Hello Mark,
    I just found your site on a search. You provide some great information and solved a problem for me here. Thank for this. I’ll come back more often and recommend you to associates now.
    Thank,
    Victor

  14. Adam Geffner says:

    Hi Mark,

    The problem we have is that when you go to the ACME via browser session and look at the session ladder stats, it only holds about 30 min worth of calls. Where do I configure to extend the time duration or cache size of calls it can hold? Alternatively I suppose would be to be able to export this data to a NAS drive, then be able to painlessly retrieve it.

    P.S. I was going to ask Ron, but I think he has his hands full lately.

    Thanks – Adam

  15. Mark says:

    Depending on how much traffic you have on the SBC and if you are capturing ALL traffic versus INTERESTING traffic using the filter, the SBC could potentially fill up quite fast. Make sure you only have the filter applied on one realm to reduce the number of captures and avoid duplicates. If you have a 4500 there is an option to add an internal hard drive kits for expanded storage (originally designed for higher CDR capacity).

  16. Denis says:

    Hello.
    Thank you very much for the great blog. Actual answers and a lot of useful info!

    Next version of 4500 OS (6.4p2) have no web server (((.

    Do you know, why they take it out?…

  17. Mark says:

    Hi Dennis,

    Right now you are seeing SCX6.4 posted on the Acme Packet portal which SCX is the traditional stream of code. There is a target date of April 24th to release another stream of 6.4 using the ECX prefix. ECX6.4 series will contain the Web GUI. In addition to SIP Monitoring and Tracing, you will have the ability to save/delete/restore backup configs, access log files, configure the SBC in an Expert mode similar to the command line structure but through the Web GUI, upload LRT files, and more.. Stay tuned!

    The web interface and the provided tools do use some additional CPU overhead/cycles. When SIP Monitoring and Tracing was introduced it was designed for very specific call capturing (replacing packet-trace) but many customers tend to use it for capturing all the traffic on the network. Acme Packet Palladion (formerly IPTEGO) is better suited for this. This one of the primary reasons why SCX has removed the web services.

  18. Mike P says:

    Thanks for this information. We upgraded our 4500 last night. Do you know how far back the history is allowed to go on the call details? Trying to find a setting for this and have been unsuccessful.