Skip to content
This repository has been archived by the owner on Oct 2, 2019. It is now read-only.

Making outbound calls needs to be better defined #192

Open
marcoscaceres opened this issue Jun 27, 2013 · 3 comments
Open

Making outbound calls needs to be better defined #192

marcoscaceres opened this issue Jun 27, 2013 · 3 comments
Milestone

Comments

@marcoscaceres
Copy link
Contributor

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 intention here is not to replicate what is in actual telephony specs, but rather to provide the bridge between the two systems.

@marcoscaceres
Copy link
Contributor Author

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
Copy link
Contributor

zolkis commented Jun 27, 2013

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
Copy link
Contributor

zolkis commented Oct 30, 2013

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants