Jump to content

See amount of SMS or SMS history for billing

Recommended Posts

  • 6 months later...

I am using Twilio for SMS, would it be possible to add some sort of a tag to the message API that could be shown in the Twilio dashboard to identify which account/domain sent the SMS?

We are going to have to turn off the SMS feature until we have some way of identifying the sender (in Multi Tenant) so that we can bill the customer correctly.


Link to comment
Share on other sites

I have just had a look through the Twilio SMS API and it doesn't look like you can :(

I notice on the Domain DID screen there is a 'SMS DID' in Vodia, is it possible to use that?  For example, we could register a separate mobile DID in Twilio for each domain, then when the message is sent, are you able to change the API so it sends the SMS API in the 'from' field of the Twilio API?  Then, in Twilio, I would be able to see SMS's, and filter by the from number.

If this can't be done, what is the 'SMS DID' in domain settings used for?

Message Resource Reference for the Twilio Messaging REST API - Twilio

Required if messagingServiceSid is not passed


A Twilio phone number in E.164 format, an alphanumeric sender ID, or a Channel Endpoint address that is enabled for the type of message you want to send. Phone numbers or short codes purchased from Twilio also work here. You cannot, for example, spoof messages from a private cell phone number. If you are using messaging_service_sid, this parameter must be empty.

Link to comment
Share on other sites

That's great, thanks!

Also, I have tested alpha-numeric SMS ANI's which works great, except for the fact that the sender-id is being received by Twilio in all lower case, for example I have the SMS ANI of 'MyAccount' however Twilio is receiving it from Vodia as 'myaccount' - with no capitals.

Any where I can change this quickly locally - it is supported by Twilio as I tried it using a generic API


Link to comment
Share on other sites

The Twilio API accepts whatever Vodia is sending in the From part of the message:

["from" => "noreply", "body" => "And again"]

However, when I am saving the SMS ANI, I am entering it as NoReply not noreply - so Vodia is either saving it in the database as all lowercase, or it is being converted to lowercase in the Vodia platform somewhere as Twilio is receiving it in lowercase.

Is it possible for me to have a look at the code on the PBX for the SMS functionality and see if I can debug it myself? I had a look at the file structure but couldn't find where the Twilio integration is on my server.


Link to comment
Share on other sites

The PBX considers this a user (or admin) phone number input field and applies the reformatting magic to it. This means that 617-399-8147 becomes (if the country code is 1) +16173998147. For alphanumeric input, the PBX does process it like a email/SIP user name, which is case insensitive and because of that gets transformed into the canonical lower-case format. I believe that generally makes sense because SMS sender addresses are phone numbers. 

Does the receiver of the SMS even see the number anywhere? If not and this is just for accounting purposes, a pragmatic approach could be just to keep it lowercase or even give it virtual phone numbers. 

Link to comment
Share on other sites

Thanks for your response.

No the receiver does not see the phone number of the sender.  Alpha-numeric sender IDs are quite common in most countries What is an Alphanumeric Sender ID? - Twilio

Due to note being able to provide any accounting to the number of SMS's sent through Vodia, if a customer of ours wants two-way SMS, then they pay us for a dedicated Twilio SMS DID, that's how we know the billing for IN/OUT SMS's, by using their unique number.

If they don't want two-way and OUT only, then we want to use Alpha-numeric, so the receiver can't respond to the message, and we can also see the alpha-numeric caller ID in Twilio so we can bill for it.


Link to comment
Share on other sites

  • 1 month later...

Not really. The workaround for now is to create a SMS account for each domain and then have the billing from the SMS provider. We are a little hesitant with changes in this area because there are more topics coming up which essentially need the same kind of flexibility like for regular DID and we first need a clear understanding on how to properly address this in a bigger picture.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...