Using MMS2R for mobile integration with Rails

Posted by Luke
on Thursday, May 24

At Slantwise, we’ve been doing some projects that involve taking user-submitted content from cell phones. Using an MMS-to-email gateway, it’s straightforward to ingest photos and videos into a Rails application with ActionMailer. Every phone we’ve tested has the ability to send an MMS message to an email address, so this is a cheap and easy way to get started. We’d like to use a shortcode like Twitter’s 40404 some day, but they are hellaciously expensive.

While receiving the email is straightforward, you still have to deal with the advertising and general crap that is added to the messages by the phone carriers.

Here’s an example from Sprint, by far the worst carrier we’ve come across:

Sprint adds advertising and other garbage to your MMS message

Not only is this message stacked with ads and other nonsense, the worst part is that the photo isn’t actually included as an attachment! You have to download it from Sprint’s server.

Thankfully, we found the MMS2R library, created by Mike Mondragon. MMS2R greatly simplifies processing MMS messages. MMS2R removes advertising, eliminates default subjects, and makes fetching media from the message much easier. It even has a special case to download the real media for Sprint messages. MMS2R decodes and extracts files from multipart MIME email so you don’t have to!

Imagine you have a MediaItem model that has a title and a file associated with it (we used AttachmentFu to store the files). Here’s an ActionMailer you that will process an incoming MMS message and store it as a new MediaItem.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

require 'mms2r'
require 'mms2r/media'

class IncomingMmsHandler < ActionMailer::Base

  def receive(email)
    # create a new Media Item
    item = MediaItem.new
    
    begin
      # Parse the MMS attachments with MMS2R
      mms = MMS2R::Media.create(email)
      mms.process

      # Gets the subject, stripping out known carrier defaults
      item.title = mms.get_subject
    
      # Get the most likely media for the message
      # MMS2R mocks up a CGI.rb temp file object, 
      # so get_media can be used with AttachmentFu!
      item.uploaded_data = mms.get_media
    
      # persist the item
      item.save!
    ensure
      # clean up the temp files      
      mms.purge
    end
  end
end

The error handling in this example is rudimentary for simplicity’s sake.

This all works on a per-carrier basis. The currently supported carriers are:

  • AT&T/Cingular
  • Dobson/Cellular One
  • Nextel
  • Sprint
  • T-Mobile
  • Verizon

New rules have to be added to strip advertisements from unknown carriers (you’ll still be able to access the media). New carriers are easy to add, so don’t be shy about submitting a patch.

MMS2R is being used in production at several web sites including mymojobaby, Vedio.tv and our own project, which is still in private beta.

(This is a preview of some of what I’ll be speaking about at Ostrava on Rails. The speakers have just been posted and it looks like a great line up. Don’t miss it if you’re in Europe.)

Comments

Leave a response

  1. Adam Block – May 24, 2007 @ 10:23 PM

    Luke, not only are short codes expensive, but currently SMS aggregators - the guys who route your short code messages to the carriers - can’t handle MMS. US carriers won’t allow the access to their networks that MMS handling requires.

    So no matter how rich you are (well, I’m sure Google could pull it off), mobile-originated MMS currently has to go to an email address. Supposedly short code routing will come in 2008.

  2. Luke Francl – May 24, 2007 @ 10:30 PM

    Adam: Good to know!

    Is there a good source of information on all this mobile stuff? I’m piecing it together however I can: Google searches, Wikipedia, trial and error…

  3. Adam Block – May 25, 2007 @ 12:50 AM

    Luke, not that I have found. I just registered a US short code for my app and am working with an aggregator so am in “rapid learning” mode.

    Your best bet is probably to talk to one of them (M-Qube, OpenMarket, Verisign in the US); they want your business so are incentivized to help you understand the incredibly complex process of getting carrier approval for short code apps. (Though some aggregators are much more interested in new business than others, I’ve found.)

    There are also mobile application consultants like Textopoly who are in business just for this purpose. I think publicly available information is sketchy because folks who’ve climbed this learning curve currently see their experience as a competitive advantage.

  4. Jake Good – May 25, 2007 @ 10:17 AM

    Another good site for information:

    http://www.usshortcodes.com/

  5. Ari Lerner – May 25, 2007 @ 10:45 AM

    We have been working with Mike lately and are just about to open source a plugin we’ve developed and used on several sites.

    Stay tuned. ;)

  6. Luke Francl – May 25, 2007 @ 02:23 PM

    I think publicly available information is sketchy because folks who’ve climbed this learning curve currently see their experience as a competitive advantage.

    I think we should try to change that.

  7. Shane Vitarana – June 20, 2007 @ 05:11 PM

    Short codes are hella expensive. But if you known someone that already has a short code, you can share it by prefixing everything with a keyword. I believe Twitter did this for a while.