🚀 Feature: Support One-way Voice Channel

Cliftonz commented 9 months ago

🔖 Feature description

Novu is a great system for centralized notification and messaging all in one place.

We are interested in extending our platform to support more types of channels.

Some of the Voice providers would include

🎤 Why is this feature needed ?

We would like to have this feature to support more one way messaging channels in Novu

✌️ How do you aim to achieve this?

Community Contributions

🔄️ Additional Information

No response

👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Contributing Guidelines

Are you willing to submit PR?

None

PaperBoardOfficial commented 9 months ago

@Cliftonz This seems a great step for a11y, could you assign me this one 😇

jainpawan21 commented 9 months ago

@Cliftonz I see this issue is for adding a new channel requiring some brainstorming.

@learner-mohit would you like to share your ideas on how you want to tackle this issue

PaperBoardOfficial commented 9 months ago

@jainpawan21 Right now, I am adding a new channel type called VOICE which will have Twilio and Telesign as two options.

Currently, I am working on Twilio's Voice API, it is very similar to Twilio's SMS API. It takes three fields: twiML url: this is the url where TwiML(twilio markup language) is hosted. it will have an xml file telling what to do like here, the xml file reads a line "Thanks for trying our documentation. Enjoy!" and then plays the classic.mp3 file after calling the recipient. Developers can create new TwiML files using Twilio's TwiML bin feature provided on their console. to: it will be receiver's mobile number from: it will be twilio's rented mobile number

I haven't checked Telesign yet. If you have any suggestion, we can discuss and get to a better solution.

PaperBoardOfficial commented 8 months ago

@jainpawan21 @Cliftonz this will take a lot of refactoring if we introduce new IVoiceProvider. for eg, if we just find "IEmailProvider | ISmsProvider | IChatProvider | IPushProvider" in code, then it is present in lots of places. Is there any other way to go round this. Is there a better way to onboard a new channel?

mahendraHegde commented 8 months ago

@Cliftonz i will add a new voice channel, can you assign this to me please?

mahendraHegde commented 8 months ago

@Cliftonz i'm thinking to add only twillio voice as part of this PR, would like to do telesign as separate PR/issue, because I was checking telesign api, and its not a straightforward flow(verify(with voice) api is, but not the voice api), it requires us to setup a webhook to handle the call accepted action to play messages, so i feel its better to separate out that implementation. lmk what do you think?

Cliftonz commented 8 months ago

@Cliftonz i'm thinking to add only twillio voice as part of this PR, would like to do telesign as separate PR/issue, because I was checking telesign api, and its not a straightforward flow(verify(with voice) api is, but not the voice api), it requires us to setup a webhook to handle the call accepted action to play messages, so i feel its better to separate out that implementation. lmk what do you think?

I agree, I think twillio voice would be enough for the initial version.

Just to quickly list, here is the general steps to do.

Add a new type in the channel enum
Add a integration section for that type in the fronted
Add a workflow node for that channel type.
Create a editor page for that channel type.
Create a send message usecase in the backend for that channel type.

In addition, I also want to add that each voice system has its own data format (xml, json, etc) and when building the data representation for the phone call. However, this is something we can look at in the future.

As for the moment, this would be the minimum that needs to be passed to the provider.

interface outgoingCall { callerId: string, // this possibly may need to be called from the provider itself destinationNumber: string, // this would be defined in the subscriber language: string, // this would be pulled from the new translation feature we are building but string will work good at the moment. recordCall: boolean, voice: string, // select the deferent type of voice for each provider. message: 'Hello, this is a test call.' // This is the part that will have to expand with how the different providers due "multiple messages" }

Let us know if you need any assistance.

novuhq / novu