Reconfig of MMS and SMS done
Jim Udall
My work that stared on Monday wasn’t entirely successful, but I have completed it as best I could and there have been some configuration changes that do manifest themselves all the way up to the user level.
One of my problems from MUSE II days has been the annoying fact that I had to use two separate long codes for SMS and MMS. So I had a few goals over the past few days and certainly one of them has been my desire to have only a single long code for MMS and SMS.
So as a result of this work, I am now going to retire the shared MUSE long code for SMS (specifically 604-562-4621) . In its place, a single longcode – specifically 778-552-6873 – will be used for both SMS and MMS.
Shared codes ALWAYS use a discriminator (i.e. keyword) to route incoming message to the appropriate applications (thru Service Points). In the case of SMS, the first word of the text message is used as the discriminator. In the case of MMS, the first word of the subject of the MMS is used as the discriminator.
In short, I have gotten the MMS longcode interface to reliably support not only MMS, but also SMS. As such, the single long code for that interface (specifically 778-552-6873) can be used by mobile users to send both SMS and MMS messages – assuming of course they use the appropriate discriminators in the messages. Those mobile originated messages can then be received by application code and processed accordingly.
In addition, I have finally gotten things setup so you can actually phone into this same number (i.e. 778-552-6873) and again using discriminators, can be used to share this phone number and applications can provide VoiceXML code.
If one ignores for the moment the idea of discriminators and the problems with sharing an interface, this new configuration offers the following benefit: A cultural application developer can promote interaction via SMS/MMS and voice services and provide a single phone number by which to engage all three technologies
Now unfortunately this hasn’t removed the problem with sharing the code in the first place. In short, your promotions would have to include instructions to endusers to preface their SMS or MMS messages with an appropriate keyword (discriminator) in order to route to your application.
And now a note about discriminators for Voice XML service points:
Whereas for SMS and MMS, the idea of a keyword discriminator is fairly straightforward, VoiceXML offers a different set of challenges. Rather than a keyword, there is a key phrase. The platform then provides some VoiceXML code up front when a call is received on a shared VoiceXML interface and does voice recognition to map to the appropriate application. As such discriminators must be thought of a little differently for VoiceXML service points than other types. The discriminators should be audibly unique – and not simply syntactically unique.
At the moment, I as the administrator of the platform am creating Service Points which attach to Service Interfaces and it is I who has defined the discriminators.
So a little table here for the 778-552-673 Service Interface that essentially provides SMS/MMS and VoiceXML service thru the same telephone number:
|
MUSE user account |
SMS/MMS Discriminator |
Voice XML Discrminator |
|
Raincity |
Rain |
Rain city |
|
Mblackstock |
Ubc |
N/A |
|
Judall |
Jim |
N/A |
|
Emmanuel |
Vh |
Virtually here |
|
Clay |
Clay |
Be see I tee |
|
|
|
|
The reason that ‘mblackstock’ and ‘judall’ have N/A as their Voice XML discriminator, is because the service points currently defined for them are direct connect to dedicated longcodes – they don’t use a shared interface.
Also a note on programming with these interfaces:
Generally, all of you have a service point named ‘Dialog SMS’ – which connects to the 778-552-4621 long code – and in spite of the name, does support both SMS and MMS (inbound and outbound)
Further, all of you have a service point named ‘VoiceXML’ – which connects to an appropriate longcode – which for everyone except for Jim and Mike, amounts to 778-552-4621. If you want to provide some Voice XML code for yourself, it’s simply a matter of establishing a callback on the Service Point named ‘VoiceXML’ that would point to your voice XML code.
Now of course some people/projects will not want to use a shared interface – and this is fine – sort of.
Mike for example is using his own dedicated longcode and he is doing SMS messaging only with it. I’m not sure how he is achieving VoiceXML service, but in principle this could be configured to use his same dedicated long code to also handle voice calls by routing to his Voice XML Service Point.
So projects and developers can easily request and get a dedicated long code and SMS/VoiceXML can be setup for them quite simply – thereby avoiding this whole issue of discriminators.
Alas, when it comes to MMS, there is a problem – which is why I started this note as only having achieved qualified success on that front.
The other thing I was trying to do this week was support multiple MMS interfaces. And in some sense I was able to do so. However, due to the software stack I’ve been using, I came upon a dead end that didn’t permit me to route messages the way I need them to be routed. As an example, I could send an MMS to the stack, but it would insist on sending it out both modems simultaneously.
So this is a problem – and once again MMS continues to be the thorn in my side.
Given the avoidance projects/developers have had with MMS, multiple dedicated MMS interface doesn’t seem to be a high priority topic. As such, I’m not going to put any more of my own effort into addressing this problem at this time. It seems clear that I have to throw out my current stack and get a new one. However, this is a MAJOR task – and not one I get paid nearly enough to execute J.
However, I would encourage you and your representative projects to think about acquiring a longcode of their own – and hooking into the SMS/VoiceXML framework using a common long code number. We still have video streaming to come on board – which should bring some interesting challenges, and I’d like to implement an e-mail Service Point model as well.
This should give us lots of different ways to engage with mobile users – albeit if MMS is limping a bit.
Jim Udall
Technology Directory Mobile MUSE
102-577 Great Northern Way
Vancouver, BC
V5T 1B1
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.6/1407 - Release Date: 4/30/2008 11:35 AM