You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 18, 2020. It is now read-only.
First, in the parameters passed to my TWIML endpoint, the Call Direction is specified as "inbound" eventhough Im the party who's initializing the call. This is confusing because when I receive a call to my twilio number, the call direction parameter is also "inbound" which makes it difficult to distinguish between the two cases and produce appropriate TWIML instructions.
Could you explain why in both cases the call direction is inbound and what's the best way to know when a call was initialized by me or when Im the recipient?
The second issue is the fact that the "StatusCallbackEvent" parameter seems to have no impact as my status endpoint is still called only on completed events. I've figured the reason is that the parameters passed to the call function are not the same as the ones outlined in the Make Call Api docs.
But I can't find a different place to pass these parameters as my app never uses the JS library on the server to initialize calls.
Would appreciate if you could shed some light on what I'm not understanding here.
Thanks :)
The text was updated successfully, but these errors were encountered:
Sorry for my delay of responding back to your questions.
Sorry for the confusion, but when making a call from a Twilio client (e.g. the iOS mobile client in your case), you are actually making an "inbound" call request to your TwiML application. To separate the two use cases (Twilio number inbound vs. call initiated by mobile client), my suggestion is to have different endpoints in your application server, and then create a separate TwiML app with the endpoint URL specifically for the mobile "outbound" calls. Put this TwiML App-SID in the access token when making calls from your mobile application.
For status-callbacks, in addition to the parameters in the call:params:delegate: method to indicate what events you want to monitor, you will also need to add them into the statusCallbackEvent field in your TwiML response. I've found two examples from the Twilio TwiML docs: dialing a number & dialing to another client. Search for "statusCallbackEvent" and you should see how the events can be specified in the TwiML.
It's been a while, and looks like this has been answered. I'm going to close this issue. @mahyarr - let us know if you have more questions, and we can reopen. Also please note that we've released more betas since then. Check them out!
Hello there,
Im integrating twilio client into an app Im developing and so far, Ive come across two questions:
1- When making outbound calls from my iOS app, Im passing the following attributes to the VoiceClient.call function:
In my TWIML response, I have something like this:
Now Im facing two issues.
First, in the parameters passed to my TWIML endpoint, the Call Direction is specified as "inbound" eventhough Im the party who's initializing the call. This is confusing because when I receive a call to my twilio number, the call direction parameter is also "inbound" which makes it difficult to distinguish between the two cases and produce appropriate TWIML instructions.
Could you explain why in both cases the call direction is inbound and what's the best way to know when a call was initialized by me or when Im the recipient?
The second issue is the fact that the "StatusCallbackEvent" parameter seems to have no impact as my status endpoint is still called only on completed events. I've figured the reason is that the parameters passed to the call function are not the same as the ones outlined in the Make Call Api docs.
But I can't find a different place to pass these parameters as my app never uses the JS library on the server to initialize calls.
Would appreciate if you could shed some light on what I'm not understanding here.
Thanks :)
The text was updated successfully, but these errors were encountered: