Denver,
You covered a lot of ground in that Post #1731. I'm in agreement with you where most of it is concerned, but at one point I have to ask you why you stipulated a programmable switch, when you did:
>>If there is no programmable switch on the other end, it could go to a voice capable computer as is.<<
IMO, a standard switch would do just as well in that situation, unless there is something you are taking into account that I am not aware of. Stated another way, the call could have taken the path option that you mentioned next, using a standard tandem switch or even an end office switch, without the need for a programmable, IMO:
>>It could be converted back to voice by the ISP at the other end, sent to the public switched network at the local access number and go to a standard telephone POTS line.<<
IOW, I didn't see anything that warrants the additional expense of the programmable there. I'm not saying that they aren't worth the extra expense; I'm saying that in your example I didn't see where a programmable was warranted. Again, I may have missed your intent. It happens. <g>
Let me offer you my perspective on this off the top of my head. The primary reasons for using the programmable switch in the VoIP hybrid configuration IMO are [once you get beyond the sizing factors and pricing, and the scalability for startups]:
(1) they are SS7 A-link equipped, and the definitions that you want to assign to those links can be edited or drafted by the carrier itself through the open API, without 'absolute' dependency on the carrier or the SS7 provider;
(2) rapid turnaround on new features - which can be performed or programmed by the carrier itself, without waiting sometimes for over a year for the switch manufacturer to come out with the next generic release;
(2) through programming, you can define features that interact with the universal SS7 overlay network, and the AIN SCP functions, like follow me, ACD functions, pre-paid billing functions, CLASS functions, ring back, etc., and assign customized billing features. NOTE: When these features are incorporated on the carriers own hosts, the costs for "dips" into the larger carriers' databases are minimized or eliminated for certain functions entirely, and profits for the smaller VoIP carriers are thus enhanced, dramatically. BTW, these are those nickel and dimer value-added features that can either make or break the smaller carrier when all of those "dips" are counted at the end of the month.
(3) they have algorithm trans-coding built into to them by virtue of their DSPs that allow for the integration of disparate compression schemes on the same call or confernece, and handing off from one carrier type to another (cellular to VoIP, e.g. or, POTS to Cellular/PCS) in a seamless manner, without the need for external conversion devices;
(4) they include teleconferencing boards that will enable multiline audio and video conferencing using the inputs from multiple and disparate formats;
(5) they can be leveraged for things other than, or in combination with, VoIP and normal POTS, such as specialized corporate private line telecomm requirements, trading room ring down-type circuits, ISDN PRI and BRI, E911, Coin operations, etc., and all taking place in the same unit without physical changes to the box, thus extending the mileage of every spent dollar;
(6) virtually anything within reason can be programmed into any of the above features and capabilities without dependence on the vendor.
Again, this is off the top of my head, and I'm not listing everything associated with the programmables here, rather, I've merely listed some of the issues that I think that a prospective, and comprehensive, ITSP might be looking for, in addition to their other routing and facilities-based needs. Like you've stated, there are too many feature possibilities to cover in a post.
Hope this has helped, and, Best Regards,
Frank Coluccio |
