making it easier to port applications across operators
Developing and deploying applications across mobile operators can be frustrating: unlike fixed broadband, mobile network operators have traditionally placed a barrier-to-entry that has hindered developers from innovating on the mobile Web. Proprietary operator APIs, so-called 'Walled Gardens', and contractual differences have stifled the creation of cross-operator Web applications (such as buddy finders, where your buddies may all be in different networks). Meanwhile, some of the cool stuff that a network can do (authentication, seamless charging, location assistance, push messaging, connection awareness, etc.) are locked up and hence not utilised. This is a lose-lose for both operators and developers.
Whilst operators evolve their developer strategies to make integrations easier, there is also a place for a lightweight, Web-friendly, cross-operator API that will allow any Web developer to utilise network enablers and create innovative, portable applications, and hence reach out to the maximum number of subscribers: step forward the GSMA One API.
ONE = Open Network Enablers
An open, public Beta, run by the GSMA, as part of the '3rd party Access initiative'. You can join it at http://www.gsmworld.com/accessentry/
The One API includes functions for Messaging, Charging, Location, Data Connection Profile, and (tbc) User Profile. Profiles of existing standards are used, as well as exploring lightweight RESTful implementations.
The 3rd party Access project includes all major European operators, and some major Asian operators. We also have software vendors and aggregators contributing to The APIs will be open source and will evolve according to community contribution
Deliverables include Developer and operator SDKs, and a Reference Implementation to test the APIs and portability of applications across operators.
API draft are publicly available, http://www.gsmworld.com/accessentry/ , and all feedback is welcome!! In order for the APIs to be high quality and relevant, we need developer feedback.
Betavine has implemented the GSMA Messaging API (RESTful binding) at this endpoint: http://www.betavine.net/api/gsma/sms.xml. The method is used to send an SMS to a target MSISDN.
A succesful request results in a request id being returned, however this return id does not mean that the SMS actually already has been sent or arrived at the target terminal - it simply means that the request has been handed to the network for processing.
For now, there is no specific support or polling for the state of the request (e.g. 'message is queued at the message router') , nor active notification on any state change of the request (e.g., 'it was queued but has now been sent'). This should be available in the next release of Betavine.
http://www.betavine.net/api/gsma/sms.xml
For the first draft of the API the key must be your Betavine UAID. To get one, visit Register a mashup and click the box to accept the Terms and Conditions, then click save to create a UAID: you will be redirected to Aepona.com (the platform provider) and the UAID will appear as a querystring. You only need to do this the first time you use the API, then you can reuse the UAID for future requests.
The target MSISDN should include the country code but no prefix to indicate an international call, nor the first 0 of the mobile number. Example: 447990123456 (where 44 indicates a UK number). When Anonymous Customer Reference becomes available it may be used in place of the MSISDN.
The message should be URL-encoded as per RFC 3986, for example any spaces should be changed to %20 (as per example above)
When the SMS is received, it will have been sent from an AePona-registered MSISDN, and not the MSISDN you have personally registered with Betavine.
The response is an XML file containing the following information:
The initial draft XML binding is:
The One API team are working with major operators to allow you to use the messaging (and other) APIs across networks, and we will have a Reference Implementation soon so that you can start using the APIs and feeding back suggestions to us.