Acme/Oracle SBC Useful Commands

To get the box-id (useful for licensing, etc.)

show version boot


To get the current amount of sessions

show sessions


To check the state of session agents

show sipd agents

To lookup a number in the local routing table
If you had created an LRT policy called inboundnums

show lrt route-entry 15555551212

To backup the config

backup name_of_backup

To verify the config

verify-config

Acme SBC & ASC - Two Legged Call Issues

I recently ran into a strange problem using Oracle's (formerly Acme Packet) SBC. In this situation, the SBC gets authorization from calls by querying the ASC (Application Session Controller) - which, in turn, queries an application server. If the person calling is acceptable or the person being called is acceptable (in the case of inbound.)

This is useful in a couple of scenarios:

• You're presenting a virtual number. For instance, you want customers to be able to call a sales rep, but you don't want to give out the direct DID/number for the salesperson. In this case, the SBC accepts the inbound call, matches on the destination DID in the LRT (provided you are using an LRT) and sends the call to the ASC. The ASC either rejects the call (if the number is not authorized) or accepts the call. If it's the latter, it will open a second call (using the SBC) to the "real" number (which the ASC obtains from the application server) and then bridges the two calls together. Thus, a two-legged call. In this case, the ASC leaves the from field the same and changes the to field and the number on the invite to be the "real" number."
• You want to do some sort of processing/reporting on the call from a call manager. In this scenario, the call is routed to the SBC from another SBC or PBX. The SBC accepts the call based on the "FROM" key in the LRT. The SBC sends the call over to the ASC. If the ASC is okay with the call, it creates the second leg and bridges the call. It's possible to even send the call back to the originating call manager or SBC.

I ran into a strange problem  in the second scenario. I had restricted the codecs on the SBC for a given session-agent. The first leg was established with no issue. The call was forwarded over to the ASC. However, the second leg was the problem. The ASC opened the second leg, but the TO and FROM fields were reversed, breaking the call.

After investigating the issue (the logs from the ASC were not helpful,) I realized that the ASC was missing the appropriate codec (in this case, G729) and, I believe, was trying to send back an error message from the sender.

The fix, of course, was to enable the codec on the ASC.

Saving Acme Packet Configs using Rancid

No one has yet written a Rancid module for Acme Packet's (now Oracle) Session Border Controller/SBCs/SIP routers. I played around with it because I wanted a quick and easy way to diff Acme config revisions. This method works for me with SBCs using 6.2 of the Acme software. It produces several errors at the top of the config, since the Cisco module tries to run a lot of commands.

1. I created an SSH key as the rancid user, with no password:

/bin/su - rancid -c "ssh-keygen -b 2048 -t rsa"

2. I created an SSH key based user on the SBCs (I have a HA pair, so I did this on the primary) - and I used the public key I created in step one (i.e., ~rancid/.ssh/id_rsa.pub    - just remember that the format is very strict. You should match, more or less, the example below. The comment goes at the beginning, and not at the end like openssh)

ssh-pub-key import authorized-key rancid

IMPORTANT:

       Please paste SSH public key in the format defined in RFC 4716.
       Terminate the key with ";" to exit.......

---- BEGIN SSH2 PUBLIC KEY ----


Comment: My rancid user's public key

AAAAB3NzaC1yc2EAAAasdasdawdawdhZj07+93RKwx0RXcwaaadawdawdaefZuc6ePw+3G9jiZUcyxFb8Td9sc700HtZLN0CtezZKHsC+bJPp0oocb9ykAIzO9xs3vOs55aadwdad21d12fq==


---- END SSH2 PUBLIC KEY ----;

I usually create host file entries for rancid, as not all of the hosts are in dns, and some have multiple addresses. But, it's entirely up to you. The key format above is strict. Make sure there are no empty spaces at the end of lines. 

3. modify .cloginrc and add the following (assuming your SBC is called mysbc1.myfqdn.local

add password mysbc1.myfqdn.local noRealPasswordNecessaryJustFillThisInWithGarbage

add autoenable mysbc1.myfqdn.local 1

add user mysbc1.myfqdn.local rancid

add method mysbc1.myfqdn.local ssh


4. log into the SBC with the actual rancid user, just so the rancid user will add the host to its ssh_known_hosts file


5. add the SBC to the router.db for your particular environment:


mysbc1.myfqdn.local:cisco:up


 6. Now, you should be all set. Run Rancid as you would, normally. For instance, I have a COLO called pac1:


/bin/su - rancid -c "/usr/local/rancid/bin/rancid-run pac1