Open pat247 opened 5 years ago
@michaelkourlas did VoIP.ms get back to you about group messaging?
Yeah, they have no near-term plans to implement it.
On Thu, Jul 23, 2020 at 5:49 PM oathzed notifications@github.com wrote:
@michaelkourlas https://github.com/michaelkourlas did VoIP.ms get back to you about group messaging?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/michaelkourlas/voipms-sms-client/issues/190#issuecomment-663249373, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMYJRBEPBIVZOGRJMMA263R5CV6DANCNFSM4H7SQ5GQ .
Yeah, they have no near-term plans to implement it. … On Thu, Jul 23, 2020 at 5:49 PM oathzed @.***> wrote: @michaelkourlas https://github.com/michaelkourlas did VoIP.ms get back to you about group messaging? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#190 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMYJRBEPBIVZOGRJMMA263R5CV6DANCNFSM4H7SQ5GQ .
Well, that's unfortunate. Thanks for looking into that for me.
I've discovered a few other issues:
Also, the Content-Type of API responses is text/html instead of application/json, which is irritating.
@mathieucarbou -- On the bright side, it looks like they've fixed that bug where if you use sendMMS to send a message with text, the text does not appear in the getMMS API response.
@michaelkourlas : thanks a lot! They clearly seem to have a real competence issue within their dev team around API development... Just looking at their API doc also tels how bad they are at designing apis so no wonder there are so many issues like that, most of them really being basics ones... I don't know what is your intuition on that but looking at this list of issues plus the ones that were discovered before it seems that if they do not ramp up their development capacity and or competence we won't have a useful stable API soon lol ;-)
Right now it seems much more a hacked API than something really usable and reliable. But perhaps that is ok too: their competence is probably mostly around VoIP, not software development.
I've discovered a few other issues:
- The service is unreliable. At the beginning of my testing, I sent a single image with no text to my Android phone (Pixel 2 XL running Android 10, using Google's Messages app) using the SMS/MMS Message Centre and did not receive it on my phone, though it appeared in the getMMS API response as a sent message. I sent the same image again a few minutes later, again using the SMS/MMS Message Centre, and this time it worked.
- When my Android phone sends one or more messages to a DID, VoIP.ms will pass raw SMIL through in the "message" field. Not sure if that's correct behaviour, but in any event it's impossible to parse because the original filenames have been lost. All we have are the three "col_mediaN" fields.
- When an Android phone sends a message with text and two or more images, VoIP.ms can't process it correctly. In some cases nothing will appear in the API response, while in other cases the message field will be malformed garbage. I'd guess this is a SMIL parsing issue.
- When an Android phone sends more than three images to a DID, those excess images are lost when received by VoIP.ms, again because all we have are the three "col_mediaN" fields.
Also, the Content-Type of API responses is text/html instead of application/json, which is irritating.
@mathieucarbou -- On the bright side, it looks like they've fixed that bug where if you use sendMMS to send a message with text, the text does not appear in the getMMS API response.
Did you mention this to them, what did they have to say? :p
Has development halted on this then?
I think we're basically in a holding patern until VOIP.ms sorts out issues on their end. There's not really any progress to be had until the service is stable and reliable.
Yeah that's too bad. I'm not sure why they don't have proper apis for mms and group chats yet, kinda lame how slow they are lol
There's some work I can still do on my end, and I am working on it when I have the time. Unfortunately, I've been very busy with my real job recently 😛
Yes, I did mention the issues to them -- they'll update me when they're fixed.
There's some work I can still do on my end, and I am working on it when I have the time. Unfortunately, I've been very busy with my real job recently 😛
Okay I understand :).
Hopefully they fix them soon. You mentioned group texting aswell?
There's some work I can still do on my end, and I am working on it when I have the time. Unfortunately, I've been very busy with my real job recently 😛
Stupid real life interfering with hobbies! Seriously though, thanks for all the work you do.
Yes, I did mention the issues to them -- they'll update me when they're fixed.
I suspect their dev team is quite small and very busy.
I did mention group texting, though they said they have no plans in that regard.
I did mention group texting, though they said they have no plans in that regard.
That's weird.
Seems pretty important to me lol.
I've discovered a few other issues:
- The service is unreliable. At the beginning of my testing, I sent a single image with no text to my Android phone (Pixel 2 XL running Android 10, using Google's Messages app) using the SMS/MMS Message Centre and did not receive it on my phone, though it appeared in the getMMS API response as a sent message. I sent the same image again a few minutes later, again using the SMS/MMS Message Centre, and this time it worked.
- When my Android phone sends one or more messages to a DID, VoIP.ms will pass raw SMIL through in the "message" field. Not sure if that's correct behaviour, but in any event it's impossible to parse because the original filenames have been lost. All we have are the three "col_mediaN" fields.
- When an Android phone sends a message with text and two or more images, VoIP.ms can't process it correctly. In some cases nothing will appear in the API response, while in other cases the message field will be malformed garbage. I'd guess this is a SMIL parsing issue.
- When an Android phone sends more than three images to a DID, those excess images are lost when received by VoIP.ms, again because all we have are the three "col_mediaN" fields.
Also, the Content-Type of API responses is text/html instead of application/json, which is irritating.
For at least two of these issues, a temporary fix could be to limit MMS to a single image/MMS, at least until it's fixed on their end. It's not much of a restriction, you just send two messages if you need to send more than one image. Hell, I don't think I've ever sent more than one image in a single MMS.
Thanks for figuring out that there's no group MMS support, that rules voip.ms out for me.. Sad.
Thanks for figuring out that there's no group MMS support, that rules voip.ms out for me.. Sad.
Try out jmp.chat it's the closest thing to a traditional carrier. It has group mms but it's not fully implemented yet, will be by the end of the year
It would be extremely helpful to receive MMS messages, even if I can't send them reliably yet.
I just realized that we don't even receive text-only messages that are over 140-160 characters (that were formerly received as multi-part SMS). Now, they just become MM-fuckin-S, and we don't receive them at all.
Great job, VOIP.ms, you just turned your already pretty crap SMS offering into something frankly unusable.
I just realized that we don't even receive text-only messages that are over 140-160 characters (that were formerly received as multi-part SMS). Now, they just become MM-fuckin-S, and we don't receive them at all.
This is not true in my experience. I'm not thrilled with the deployment of MMS so far either, but text-only SMS is still received as as multi-part SMS. My standard Android messaging app will automatically convert to MMS after it exceeds 6 parts (160 characters each).
Perhaps whatever app or carrier is sending the long text message to you is deciding to convert it to MMS earlier than that, but it does not appear that VoIP.ms is doing it. If it was, you should open a ticket with them, it's not something this app can fix.
Until this app has full support for MMS, I recommend setting up an SMS to email. MMS will come from the sender mms@voip.ms instead of sms@voip.ms, so you can filter to different folders and have a way to ensure you don't miss any.
Alternatively, the SMS Callback service works pretty well, but you have to do some programming and some people are already using this for push notifications instead.
My standard Android messaging app will automatically convert to MMS after it exceeds 6 parts (160 characters each).
Your reply just provided the missing data to explain what I am experiencing. My native language contains a few characters that are outside the 7-bit encoding system. Therefore, when these are included in a message, Unicode is being used. Turns out, it's really easy to exceed 6 parts for a text message when the character limit is 60 for a single message..! It's only a bit more than the length of two 7-bit encoded text messages. That's what's happening here.
I just realized that we don't even receive text-only messages that are over 140-160 characters (that were formerly received as multi-part SMS). Now, they just become MM-fuckin-S, and we don't receive them at all.
Great job, VOIP.ms, you just turned your already pretty crap SMS offering into something frankly unusable.
Do yourself a favor and switch to jmp.chat
It would be extremely helpful to receive MMS messages, even if I can't send them reliably yet.
I don't think it's going to take significantly less effort to support just receiving messages vs. sending + receiving.
If Voip.ms can reliability deliver the MMS messages via email, why would using the API be any less reliable? I would think that it would use the same data source and protocol for forwarding them no? Or could they possibly be being converted to email before being dropped into whatever database? Doesn't sound like it would make much sense except if they are just using existing email to sms vice versa software that most carriers already have to do it and Then it drops it to a DB for this API?
Raising this back. Somehow one of the services that sends me messages, sent me an MMS instead of an SMS, and I "now" understand why it doesn't show up in the app.
Any progress on this?
Here's an Idea, because I keep running into this SMS MMS issue myself. Occasionally someone will send me and MMS and expect me to reply. I know that I should receive an email notification for MMS sent as well, but would it be possible to at least put an MMS notification in the app to let people know that an MMS was sent and Voip.ms won't handle those? Or possibly offer a generated link to the MMS message instead? A little patch to help wait until Voip.ms gets their service and api working better. I can't believe they took it out of beta and started charging for it before it was reliable.
It is in https://www.voip.ms/m/apidocs.php now. Shouldn't it be ez?
Please actually read through the thread before comments like that. It's been documented in the API for a year now. The problem is in the MMS service itself, not the app.
To clarify -- although there were bugs in the API when I last checked last year, they may have been fixed by now, and in any event they're not blocking. It's just that I haven't had time to work on this.
Looking forward to MMS support too. Thanks
So, smnc, shut it
To anyone out there awaiting for MMS support, please consider donating to Michael as this is not compensated work. https://www.paypal.com/paypalme/kourlas
Good job Michael and thanks for the support.
I'd rather pay someone 5$ to completely redo it on freelancer as easy as it is.
I'd have it done as normal system messaging app too.
So, smnc, shut it
Whoa. There is NO need for hostility. I posted a polite response to a user. Let's try to all be civil. Please.
I'd rather pay someone 5$ to completely redo it on freelancer as easy as it is.
Feel free to leave this thread and go do that then. Have a great day. Also, blocked and reported. I don't feed trolls.
I'd rather pay someone 5$ to completely redo it on freelancer as easy as it is.
Do it, open source. Everybody benefits. Keep us posted.
Just checking, whether there is any plans to do this. Appreciate it!
Yes, I still plan to do this, but I also have a day job :P
My daughter is at the age she is just getting in to text messaging with friends. I got her a voip.ms number, and she can do sms via email/web, but she asked for an app. If MMS worked reliably in an app on her tablet it would possibly keep her from needing an actual cellphone, which would be a great solution for this aged kid.
Great work on this app! I also have a day job... but right now I'm motivated by my kid, and I'm thinking about spending some time setting up and building this app to see if I can't contribute some coding time. I'll let you know if I actually get it built and then I might ask for some tips/pointers.
What am I missing about the availability of the source code? Because according to the instructions, it's right there next to the compiled releases. He has an open source and a cosed source copy, but the open source is complete enough to build the app I think? Not sure how much more work adding push notifications would be.
"The standard version of the app uses closed-source Firebase libraries to support push notifications and facilitate crash reporting and analytics, among other purposes. A version of the application that is completely open source is available from F-Droid.
Both versions are available from the Releases section of the GitHub repository."
When did I say there was any trouble with source code availability? I just have to clone and build in theory. It's a matter of making time to go through the steps.
When I have time to look at this again, I will probably do this in two phases: support for receiving MMS first, then support for sending MMS in a subsequent release.
I have successfully built the app. I am starting to familiarize myself with the code. I've looked at all the places referencing www.voip.ms/api/ to see how sms messages are handled. I added in a very basic mms support, and it can at least retrieve the text portion of the mms messages. That's a start. I'll try to tackle decoding/displaying the images next. I'll post my work in a fork on github soon, I suppose. I'm open to suggestions on how to proceed if anyone has any additional advice.
I have pust my very basic mms support modification up to a fork: https://github.com/poleguy/voipms-sms-client
Again, I'm open to comments/suggestions/redirections/etc. as I'm really just hacking at it.
I have pust my very basic mms support modification up to a fork: https://github.com/poleguy/voipms-sms-client
Again, I'm open to comments/suggestions/redirections/etc. as I'm really just hacking at it.
Hell yea, right on man! I'll take any progress at this point. I really was willing to take just getting notifications that an mms had been sent cuz right now they just arrive at voip.ms and maybe I'll get a email, but I'm not that big on that. Having it show up in my sms inbox is wayyyyy better. Thanks you! I'll be checking it out now. Did compile a release build or do I need compile it?
I didn't post an apk, as I just started at this. I'll try to get one up for testing as time allows this week.
I have added some initial work in the mms
branch.
Hey everyone, like @poleguy my daughter is just getting into texting. I have been following this thread with interest. I use voip.ms for her cell phone and sms, with a data only sim. However, it would be great to have MMS capability from the API in the voip.ms sms app. It would totally meet all her current messaging needs. I have no experience in software/app development, but I am offering my time for testing or if someone is willing to teach me enough that I can be useful or dangerous, let me know. Cheers
MMS on VoIP.ms to roll out for beta testing soon. https://www.dslreports.com/forum/r32442917- July 9
A major enhancement for the todo list.