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.
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.