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.