This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
I could use this also. Twilio has very specific requirements on how to POST the data, and there is very little documentation on how to make ISE match what they are expecting.
This post was perfect for clickatell, if I could get something like this for Twilio that would be great.
Using the guide you referenced for Clickatell, you should be able to recreate that for Twilio as well. They have a document on how to use their HTTP-Post parameters in their REST API. The URL I was able to find for this is below:
Clickatell uses an HTTP get, while Twillio wants a POST, so the formatting is different. And I'm not an HTML coder, so I'd really need to see the whole string cut/paste style to recreate it in ISE.
ISE 2.0 supports HTTP POST. You'll see it after selecting "SMS HTTP API" when adding a new SMS Gateway Provider. I don't think you need to be an HTTP coder to do it, you just need to format the HTTP POST URL using Twilio's API variables.
Running ISE 1.4, and see TAC case: 637964857. Nobody seems to know the right format.
Data (Url encoded portion):
Is this right? Doesn't work. Should it be To=$mobilenumber$ (without the one), is that right? Doesn't seem to be. Is it missing the markers for the Username password? Seems like it, what should those look like in ISE?
Our HTML guys says:
The ISE is not supplying the values from the "HTTPS Username" and "HTTPS password" fields in the HTTP POST request (as can be seen in the tcpdump). These should be passed in a standard HTTP "Authorization" header (HTTP BASIC auth).
The contents of the "Data (Url encoded portion)" field are, in fact, not being URL-encoded at all. The tcpdump shows the raw '+' character and raw spaces being passed.
So you tell me, you don't think an HTML person is required for this task?
Cut and past what the URL encoded portion should be, exactly, and I'll try it.
if you're already working with tac I would recommend asking they escalate to see if they can get it to work with developers, it might be a request for enhancement if it doesn't work and this way they can capture the required info to make it work
Already done. Was using the forum as another route to see if somebody in the community figured this syntax out already. Some of the other services (like Clickatell) are better documented...
This vendor flow using http posts is not currently supported and will require customer to open enhancement to track, disregard prior defect that was listed
Running into these challenges with Twilio as well. What's the best way to show that this is a highly requested feature from customers. Twilio support is baked into Meraki already and customers like it.
Has anything come of this? I am looking for a solution as well. I actually opened a TAC about 2 years ago on this and they said that it would be fixed in 2.0, which it wasn't then they said 2.2. I even requested a feature enhancement. Anybody have any success with this? Clickatell is easy to configure but doesn't offer global solutions...
We are using Click-a-tell globally, not sure of the problem? We have some customers using twilio with ISE 2.0 patch 3
Apparently the trick with Twilio was, you had to include the FROM phone number in BOTH the URL and the encoded portion.
I just tried this Jason and this does not work.My Post DATA is:
and URL is:
I have all the other auth parameters correct. I can get this to work with Postman without the From field in the URL and the same POST data.
I see the screenshot you added has no To and Body paramters, which is not what Twilio documentation says. Can you paste a working Post data field?