Making outbound calls needs to be better defined

[marcoscaceres]

Making outbound calls doesn't currently describe the sequence of steps that are taken by the telephony service and the interaction with the API.

In particular, it's not defined what to do when (this list will likely expand):

• The remote party's identifier is malformed (i.e., bad phone number, etc.) as per Duplicated description of sendTones method #89.

The intention here is not to replicate what is in actual telephony specs, but rather to provide the bridge between the two systems.

[marcoscaceres]

So, I'm thinking that each state and disconnect reason could define it's event or error as it relates to the API. The sate diagrams currently don't help too much here.

[zolkis]

Only disconnect may give a reason why it happened.
There is 3 dimensions of call states:

• call
• call hold
• multiparty

This means that hold may fail (call stays active), and createConference may fail (call stays active).
All the rest is handled by disconnect.

[zolkis]

To update this, implementations MAY check on malformed numbers, but generally it depends on the telephony network what it accepts as a number. In case of an error, there is a disconnect reason.

If you mean that we should provide a mechanism that implementations could use for reporting early error findings, then yes, we can investigate that, e.g. a Promise could be returned for dial() method.