BroadWorks calls it "URL Dialing": calling from your hosted PBX VoIP phone or SIP Trunking device to a random SIP URI. 
Lately, Polycom has been handing out SIP URIs and inviting people to test out their video bridges. Let's say you want to call to sip:1234@opensips.org -- how should it work?
Most VoIP services providers -- such as those built on BroadWorks and Metaswitch -- don't allow calls from their subscribers to sip:1234@opensips.org to go through. How do you send in a SIP URI complete with domain anyway? Most users just think of dialing telephone numbers. And maybe extensions. Oh, and feature codes like *67. But definitely not "sip:lindsey@e-c-group.com".
If you're going to send it from the SBC, one big problem with allowing arbitrary outbound access to the Internet is that you have to allow arbitrary inbound SIP and RTP from the Internet. It's hard to predict in advance where you're going to be getting SIP from, and so it's really hard to make appropriate session-agent or access-control statements to protect the SBC against CPU overload. Auto-blacklisting (such as "access-control-trust-level low" on the Oracle/Acme Packet SBC) can help some here though.
Option 1: Punt on Security, NAT Traversal, Billing, Support, etc.
The easiest option is just a separate button on a Polycom that sends the call where-ever on the Internet you want: of course this doesn't solve every problem. You've got NAT traversal. And your phones might not even have Internet access. But for a certain class of situations, this might get you what you want. This is how I "normally" do it: direct from my Polycom, or more likely, EyeBeam.
Option 2: SIP URI Calling to a few specific cases
If you just have a few specific cases, then you can pretty readily set them up as BroadWorks AS Identity/Device Profiles; that actually does allow a specific domain and an outbound proxy, which you could set to be the SBC. This doesn't require any setup on the Network Server, and it could allow the SBC to do the DNS lookups.
Option 3: Arbitrary dialing with DNS Server Support
But let's say you can get OK with the security issues, and you need end users to make call to any SIP URI you want -- including NAT traversal support and the SBC security, and BroadWorks/Metaswitch CDRs, etc. E.g., you want a polycom user to be able to type in a SIP URI on their desk phone and have it work as long as the SIP URI is valid.
To do this with BroadWorks, I'd have to resort to a special DNS server configuration that returned SRV records. Any time the AS/CFS does and SRV query for a random domain, the DNS server would respond with an SRV record sending the traffic to the right interface on the SBC. Then the SBC would do the *true* DNS lookups and route the request across the Internets.
