| GSMA OneAPI support. |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through June 09, 2011 ⬆ |
◄ ► |
| Author | Message | |||
| Mikkel Løkke New member Username: Mikkel_løkke Post Number: 1 Registered: 03-2010 |
Our SMSC provider is switching from EMI to OneAPI as the SMSC interface. From what I can tell, NowSMS does not support OneAPI out-of-the-box. EMI services will be terminated ultimo 2010, at which point OneAPI (or GSM modem) would be the only remaining option if we don't want to migrate to another product as far as I can tell. Using a GSM modem is not a long term, cost effective solution and besides which, quickly becomes a single point of failure. Does NowSMS have any immediate plans for adding GSMA OneAPI as a transport protocol? Is there any 1st or 3rd party products which could bridge EMI (or some other NowSMS supported transport) with OneAPI? Kind regards, Mikkel Løkke | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7889 Registered: 10-2002 |
Hi Mikkel, We do plan on supporting adding support for OneAPI this year. However, exact timing is dependent on the OneAPI v1.0 specifications being released. If more market forces decide not to wait for v1.0, and to standardise around v0.91, we will implement it without waiting for v1.0. From what I understand, a candidate enabler v1.0 specification release is scheduled to be made available 2Q 2010. The current v0.91 specifications only define a RESTful HTTP POST interface with URL encoded parameters. v1.0 is supposed to define the XML format. I'm reasonably confident that we will support both of these formats in NowSMS, but we believe that the market will wait for the XML based format, which is why we want to see the candidate enabler specification for v1.0 before releasing product that implements OneAPI. In addition to the XML format not yet being defined, there are other things missing in the current OneAPI specification as it relates to SMS. Specifically, it supports text messages only, with no support for binary messages or message class attributes. Current OneAPI releases also only define how to send messages, there is no support for being able to receive messages. Based upon these serious shortcomings, it is hard to expect OneAPI to replace other SMS protocols, but rather to supplement them. In fact, we expect that more of our initial focus on OneAPI will be to implement server side support for it, providing back-end conversions to other SMS and MMS protocols. Client side support, like you are asking for, is also part of our plans, and will not be difficult for us to implement, subject to limitations of that specification. I would suggest that you ask your SMS provider for more details about their OneAPI plans. 1.) Are they implementing it based upon v0.91, or are they waiting for the v1.0 specification to be released. 2.) If binary messages or specialised message attributes are important to you, be sure to ask your provider how they will handle this requirement since it is not addressed in OneAPI v0.91. 3.) If you have the requirement to receive mobile originated SMS messages, ask your provider how they will handle this requirement since it is not addressed in OneAPI v0.91. 4.) How will long SMS messages be supported? Will OneAPI accept SMS text messages longer than 160 characters and perform the necessary segmentation, since the current protocol specification does not allow the client to split the message. -bn | |||
| Mikkel Løkke New member Username: Mikkel_løkke Post Number: 2 Registered: 03-2010 |
Hi Bryce, Thanks for your quick and comprehensive answer. From what I understand they are using a solution based on the aepona reference implementation, but beyond that I have very little knowledge about the particulars (one of the downsides of being a service provider I suppose). What I do know is they're using SOAP for message exchange, which based on your reply, doesn't seem like it's at all OneAPI compliant. In either case I will forward your questions to the relevant persons, and hope to have an answer for you soon. Kind regards, Mikkel Løkke | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7890 Registered: 10-2002 |
Hi Mikkel, I'd be curious what you find out. We are interested in being early with OneAPI support, but the SOAP/XML part seems to be a moving target at present. Also, I should note that it appears that I was wrong about the inability to receive mobile originated messages ... this is addressed in OneAPI v0.91. The crazy thing is that receiving SMS uses an XML format, but sending SMS currently does not. My understanding is that the industry group that is working on this specification has a current target date for public candidate release of April 30. This date has slipped multiple times, but GSMA pressure to finalise the API will likely mean that a public specification will be released by April 30 ... even if the end result is an imperfect and incomplete specification. The industry group is a meeting the week of April 12, to hammer out a review of a draft specification due to be completed by the prior Friday. I've spent a little time reviewing work in progress XSD and WSDL files, and it looks like there is some attempt to support EMS and "SmartMessaging", the latter of which I would assume would include port addressed messages (necessary for sending messages to Java apps or WAP Push) in addition to legacy Nokia Smart Messaging. However, there seems to be a struggle to maintain direct one-to-one API compatibility with Parlay X (upon which v0.91 is based), at the expense of leaving out necessary functionality. We'll have to see what that group decides, but I see a strong possibility that EMS and SmartMessaging support may be left out of v1, which is unfortunate. It appears that WAP Push support is planned for v2 of the specification. Thanks for any input that you can provide. -bn | |||
| Michael Andersen New member Username: Michael_andersen Post Number: 1 Registered: 06-2010 |
Hi, I'm currently in the same situation as Mikkel (I suspect we have the same provider). Can you update this thread with a status for OneAPI support? I received some information from our service provider about their solution: ----------------- "Originally they had a look at a Parlay/X compliant platform. Parlay/X standard defines web service interfaces including sending and receiving SMS and MMS, sending wap push and payment. Meanwhile Parlay/X then incorporated into OneAPI, and we ended up choosing a solution from Aepona. Aepona actively participates in OneAPI project and run the reference implementation (see oneapi.aepona.com). The solution is based on the Parlay / X standards, which are included in version 0.91 of the web service definition to OneAPI. (Service provider) has been made simple extensions compared to standard, so the platform instance supports sending binary SMS messages (standard defines currently no functionality for sending binary messages)." ----------------- What worries me, is the part about "simple extensions" which are not covered by any standards I guess. I reckon that this makes it very difficult for NowSMS to include proper support for this service provider. We need the ability to send OMA DM and Wap Push messages, for managing our mobile phones. Currently I see three possible solutions. * Stay with NowSMS and use SMS modems, which is not a good solution in the long term. * Change to other software solutions that DO support this new platform. Although I hate using platforms not based on standards, it's still a possible, but not very flexible solution. * Change to a Service Provider, that provides services compatible with NowSMS. I would love to hear input from anyone about this situation. I'm not an expert in this field, so excuse my ignorance, if any, in the above text. Mikkel I'm also interested in hearing about your current situation, and how you plan to deal with it, in regard to this issue.  Best regards, Michael Andersen | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7917 Registered: 10-2002 |
Hi Michael, Yes, it is these "simple extensions" that are problematic. We are skeptical that OneAPI is going to see widespread support until the standard is more complete and basic functionality is handled without "simple extensions" that are vendor specific and outside of the standard. It puzzles me that an SMS service provider would tell their customers that they have to switch to OneAPI. It would make more sense to implement OneAPI as an additional access point and migrate customers to it as it gains traction. (It is likely that their OneAPI solution is talking SMPP on its back-end to interface with operators and other providers.) I guess the question here is ... what are the "simple extensions" that your provider has implemented? How does it support binary messages? Does it handle long text messages? (We are guessing that long text messages should be handled as a function of OneAPI, and that the OneAPI server will perform the segmentation.) What about receiving of mobile originated SMS messages, does OneAPI reassemble the concatenated message before delivering it? Are these simple extensions supported fully from the SOAP interface, or do they use the RESTful interface only? If providers are actually implementing OneAPI (outside of the Canadian pilot), we see opportunity in adding OneAPI support to NowSMS. We are just hesitant to support a protocol that appears to be incomplete in addressing customer SMS needs. If you can get information about these "simple extensions", we'd like to take a closer look at them. -bn | |||
| Mikkel Løkke New member Username: Mikkel_løkke Post Number: 3 Registered: 03-2010 |
Hi Michael, I suspect you're right about us having the same provider. Our situation is that we've been running two separate configurations. Our own legacy EMI integration for sending (business critical) messages and NowSMS (via modem) for sending OTA configurations and diagnostics messages. Our current solution involves porting our legacy integration to OneAPI, and are currently debating whether to continue using NowSMS with a modem, or switching to an all-in-one provider for sending OTA/OMA messages. Kind regards, Mikkel Løkke | |||
