Yes Asterisk or Freeswitch is not limited to final client use. I know here a lot of providers using it, and most of our providers have Asterisk machines.
Using full IP telephony avoid using expensive traditionnal telephony trunks (E1, BRI or PRI), and save the cost and complexity of expensive ToIP bridge hardware.
In the case where we deal with multisite client installations, and using full IP telephony (SIP or IAX trunk to the provider) we have to deal with ANI transmission. If not, as soon as the client mask its CID, the provider has no means to get the proper client ANI in the trunk. Then the call can be terminated without ANI, causing problems to urgency services, or billing problems if the client need independant billing for each location.
IAX trunk mode is the only simple solution to save bandwith when using G729. That is one of the reasons why providers have some asterisk machines to deal with a large number of calls even for clients using small ADSL or DSL links. It’s possible to send about 50 G729 calls or more in an IAX trunk on a low cost ADSL2+ link. In this case, the link between the client and provider is fully IP, there is no traditional telephony link transmitting an ANI.
We should be able in this case to set an ANI for each client location, and an independant or masked CID. So the provider could see the right ANI anytime in the final client trunk (a multisite client will have one ANI for each location, but can have many CID for each location). All this needs to be transmitted in the final trunk to the provider.
SS7 take care of this. Inside SS7 ANI is the Charge Number. ANI is a generic term of the past but we are using it for simplicity, because it does not have the same name inside each protocol.
A solution is to use SS7 over IP between the client and the provider, but this is far too complicated and expensive for most cases.
The futur of telephony is not here yet. When IPBX softwares and IP telephony switches will be able to communicate a bit better with the SS7 world, then we’ll be able to start a true and efficient migration. As of today, with Full IP telephony, service quality drop down because we have to deal with a high number of interoperability problems. It is not rare today to see 3 or 4 codec translations for the same call, destroying audio quality. I would be curious to see what would arrives if today we were suppressing all the SS7 hardware inside telcom providers and replacing by SIP softswitches. For sure, we would have a big disaster, with enormous billing problems, codec negotiation problems, and bandwith problems.
There is no need to reinvent the wheel, just see what has been done inside SS7 and traditionnal links (ATM technology), and smartly translate to IP. Reading the RFCs is not sufficient. A big effort is necessary to implement them reliabily as the RFCs allow for to much interpretation and do not cover enough SS7 / SIP interoperability problems. Most SS7 / SIP interoperability documents are only old drafts done by isolated engineers.
Big providers are very happy to see the slow developpement of SIP / SS7 interoperability, because they are not yet ready to switch to IP at client sites. This is a fantastic opportunity for them to prepare the future and see the small providers fighting with erratic SIP communications :=(
I hope that the opensource telephony community will soon understand this and start to developpe smart things like intelligent codec negotiation, bandwith and call priority (an urgency call should be able to drop an active call inside an IP trunk to allow to terminate it, a saturated trunk should stop accepting new calls automatically), really test and debug the new 16, 32 and 48 Khz codecs, and more generaly implement reliabily all the basic things working since decades in the traditionnal telephony world be fore to put toys for geeks like Asterisk does.