Yes, but this is standard of any telecom provider, and Twilio is charging you for it because their underlying providers are charging them. Also inbound legs are generally an order of magnitude cheaper per minute for standard phone numbers.
Standard call:
- A places an outbound leg to C. A pays for this leg
- C receives an inbound leg from A. C pays for this leg
Forwarded call with B (your Twilio/some other telephony API provider number) in the middle:
- A places an outbound leg to B. A pays for this leg
- B receives an inbound leg from A. B pays for this leg.
- B places outbound leg to C. B pays for this leg
- C receives an inbound leg from B. C pays for this leg
In this scenario the two "sides" of the call could be going through completely different underlying telcos so there's no "Oh it's just forwarding!" The two different telcos don't really care about that. To them they're still each setting up 1 outbound & 1 inbound leg.
Although the billing structure is standard, Twilio is not considered a low cost provider for what they offer. They kind of rely on their customers being software people that need an API but don't know enough about telecom billing to demand better.
The value-add is real though, you would never want to go about this on your own. Companies like Twilio (and their competitors) gloss over the millions of rough edges that exist when working with a telco directly. It's just that the markup is very high for Twilio.
Are there alternatives that have as simple and well documented an interface for development... considering how much some of the SIP providers I've seen charge for SMBs, I think it kind of evens out depending on usage.
Pick up call - start recording - forward call to another line - collect recording & post it to S3, in no more than 100 lines, and that was before they had an SDK.
Standard call:
- A places an outbound leg to C. A pays for this leg
- C receives an inbound leg from A. C pays for this leg
Forwarded call with B (your Twilio/some other telephony API provider number) in the middle:
- A places an outbound leg to B. A pays for this leg
- B receives an inbound leg from A. B pays for this leg.
- B places outbound leg to C. B pays for this leg
- C receives an inbound leg from B. C pays for this leg
In this scenario the two "sides" of the call could be going through completely different underlying telcos so there's no "Oh it's just forwarding!" The two different telcos don't really care about that. To them they're still each setting up 1 outbound & 1 inbound leg.
Although the billing structure is standard, Twilio is not considered a low cost provider for what they offer. They kind of rely on their customers being software people that need an API but don't know enough about telecom billing to demand better.
The value-add is real though, you would never want to go about this on your own. Companies like Twilio (and their competitors) gloss over the millions of rough edges that exist when working with a telco directly. It's just that the markup is very high for Twilio.