I have been working on a Twilio project and i have set everything up using this guide: Stream TwiML
i have already resolved a common issue with the help of Alan here Answer
I'm unable to send back the processed bytes I'm using.
ws.send(bytes)
ws.receive()
These two methods i assume are required to send and receive back and forth data using the web socket.
But im receving a constant data stream from twilio.
That's:
b'\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xf
Which does not makes any sense. The guide officially says you can get bytes from real time call and then send them. So let's say i receive bytes and process them using my custom logic maybe storing it somewhere. My processing outputs the same PCM/16Bit Mono audio data in bytes. Which i think twilio is also send me raw bytes as it says in the documentation that it gives out raw bytes (which i assume are without any kind of encoding). So all i want here is to receive audio data sent from the caller to twilio to receive and send bytes to an endpoint which i have setup ed earlier in flask to handle and then i can process it a little bit and return PCM bytes to it which can be played back at the caller side.
All i want is to caller send his voice and gets processed and receives back maybe our voices added to it as well. It wont matter how the byte is treated here my concept is to add some audio data to it and send back.
But since verb is new so there's no where i can find how to properly handle the bytes and send them back.
It would be nice if someone can point me what twilio expects in the web socket return as a audio data that it can be played on the caller side. And what i should be expecting from twilio. But since in the documentation it says that payload sends out raw bytes so i assume its a plain PCM data in bytes.
Please let me know so i can receive bytes from twilio and send them back which can be played at the caller side and caller's voice can be heard from here.I have players and clients setup ed as well to play the byte data but since the data is plain or recursive i cannot play it.
Thanks in advance.
Twilio developer evangelist here.
As far as I know right now Media Streams only supports streaming the data to your server one way. You cannot stream media back to Twilio via the websocket connection.
If you were able to save the bytes you want to send back as an audio file, you can play it back to the call by redirecting the call to some TwiML that <Play>s the audio to the call.
Let me know if that helps at all.
Related
Programmable Voice docs indicate that the SHAKEN/STIR status is passed to the webhook for incoming calls, but I don't see it in the POST data. I wouldn't expect it in Lookups since that's not real-time, and I don't see it there either.
My set up is: a Twilio phone number, configured for Voice & Fax to accept incoming voice calls and POST them to a Webhook on my own server.
Added Information:
I think the issue may be threefold:
incoming calls without SHAKEN/STIR data won't have the parameter;
very few calls have SHAKEN/STIR data (based on my call logs)
(not sure why... even legitimate calls from major U.S. carrier numbers don't have it)
SHAKEN/STIR support in forwarded calls is "coming later"
This blog covers the topic.
Building SHAKEN/STIR verification Into Your Voice CAPTCHA IVR
https://www.twilio.com/blog/shaken-stir-verification-voice-captcha-ivr
In the technical note, tn2265 apple describes how to handle errors while attempting to send batch push notifications: (direct quote)
Here's how to check for errors when using the enhanced notification
format. Keep writing until a write fails. If the stream is ready for
writing again, resend the notification and keep going. If the stream
isn't ready for writing, see if the stream is available for reading.
If it is, read everything available from the stream. If you get zero
bytes back, the connection was closed because of an error such as an
invalid command byte or other parsing error. If you get six bytes
back, that's an error response that you can check for the response
code and the ID of the notification that caused the error. You'll need
to send every notification following that one again.
My question relates to the text I have highlighted in bold. For the record, I am using the Enhanced Notification Format, and I am passing in my unique ID for each recipient in the my list, so as the APNS service can return this id in case of errors.
In case we receive 0 bytes back, i.e. Apple has closed the connection without sending an error code back, we cannot know after which attempted device token the error occurred. I.e. we cannot resume sending from that or the next token.
In this case, is it acceptable to attempt re-sending to all the devices again? Is this not going to result in devices being "spammed" by the same notification multiple times?
For example: Assume I have a list of 5000 devices to send to. The 0-byte response problem occurs after I have successfully sent to a random part of my list, and I do not know how many devices AND which ones have actually received my notification. Not having an error code returned with the device id of the last successful device, or the device at which the error occurred, does not allow me to resume sending from the next token, which was the whole purpose behind using the Enhanced Notification Format in the first place.
How have others handled this issue? I would appreciate any thoughts or suggestions.
Thanks in advance for your assistance.
When my Twilio numbers receive an SMS longer than 160 chars, I get a call to my server with each 160 char fragment. Each server call is like a separate SMS. The order in which I receive them is random.
Does anyone have a solution to this other than manually assemble these fragments?
Does anyone know of a replacement to Twilio?. It should support:
sending and receiving SMS world wide.
sending and receiving SMSs that are longer than 160 chars. (i.e. deliver multiple messages in the right order)
easy python/django integration.
Checked out Plivo's API. Did not find a solution there for receiving long SMSs
Apparently nexmo does what I need.
It works all over the globe.
It solves the problem of long inbound SMSs
How do I send and receive network MIDI data in iOS? I am able to resolve the server using bonjour and apply the service to a MIDI connection, but I don't know where to go from there. The documentation seems to be lacking, and there's not much information online.
Essentially, you need to connect to the session via Bonjour as you have done, and within your iOS app:
Create a client using MIDIClientCreate
Create an input port using MIDIInputPortCreate
This takes a pointer to a C function that will be called when MIDI data is received
You need to connect it to the MIDINetworkSession's defaultSession using MIDIPortConnectSource - connect it to the sourceEndpoint
Create an output port using MIDIOutputPortCreate
You can send data to the network session using MIDISend - send the packets to to the MIDINetworkSession defaultSession's destinationEndpoint
I wrote a few blog posts about this a while back, see here for source code etc.
Part 1
Part 2
Part 3
I want to create a voice chat software using FMOD.
Now I can receive data from microphone and play it immediately.
It's also easy to send sound data to another computer on the network.
But I don't know how to play the sent data on the other computer with FMOD.
Can anyone help me?
When you receive the incoming sound data on the destination machine you need to create a streaming buffer to play the audio. The simplest method would be to look at the userccreatedsound example. It shows how to create a custom stream buffer and use the pcmreadcallback to populate the sound with data as needed.