| Delivery report / MM7 cancel and replace |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
I have registered as a VASP and submitted messages via MM7. 1. How do I configure NowSms to forward delivery reports to a specific IP / port? 2. Is it currently possible to cancel and replace messages using MM7? | |||
| Bryce Norwood - NowSMS Support |
Hi, It looks like part of this question was also posted in another thread on the MMS Technical Discussion forum. Since it is more appropriate for this forum, I'll repost here. We do not support cancel and replace via MM7 in this release. (We are going to look at adding replace support after the initial v5.0 release. Cancel is more complicated, because you cannot always cancel the SMS notification that has been generated.) On how to get the delivery reports, here is the response that I posted in the other forum: ===== Actually, I'm glad you asked that question. Without the documentation being finished, this is difficult to figure out. We had a lot of design debates on how to handle this. Logically, it would make sense, if when configuring the VASP account, you also configured how to route messages (such as delivery reports) back out to the VASP. But with all of the different protocols, and some of the different routing combinations that are possible. For example, you could talk to us via MM7, and have the gateway use a GPRS modem to talk MM1 ... and you also have to consider how to get delivery reports that come back in the MM1 connection over GPRS back to the MM7 connection. Or NowSMS might be using MM7 to talk to another MMSC. It all gets very confusing. Most of the design choices that we considered seem to rule out different potential combinations that we could think of. So what we decided to do, was to separate inbound message routing from outbound message routing. (By inbound, I am referring to a VASP submitting messages in to the gateway. By outbound, I am referring to the gateway routing messages outbound for delivery.) On the "MMSC VASP" configuration dialog, you define the accounts that can submit messages inbound to NowSMS. On the "MMSC Routing" configuration dialog, you define the routing of messages out from NowSMS for delivery. If you're submitting in a message using MM7, then you've defined an account on the "MMSC VASP" page. That account definition only allows you to submit messages in. You can't receive any replies or delivery reports. If a delivery report is requested, the system will generate a delivery report back to the SenderAddress specified in the MM7 message submission. However, you need to have a path defined to route that address back to your MM7 application. (Or you could make the SenderAddress an e-mail address, in which case the delivery reports would be routed back to you via e-mail.) So if you define an entry on the "MMSC Routing" dialog that points to your MM7 receiver, and give it the SenderAddress that needs to be routed back to your application, then you'll receive the delivery reports. A neat trick that I tried during testing was using MM7 to connect to a NowSMS gateway that was sending all outbound MMS messages via an MM1 connection over GPRS to an operator MMSC. Getting delivery reports proved a little trickier in that environment. When you are receiving messages over a GSM/GPRS modem, there are options for how the received messages should be routed. One of those options is to route the messages via MM7, where you specify a named "MMSC Routing" definition. It was actually a pretty interesting test. I submitted the message via MM7 to the gateway. The gateway initiated the GPRS connection, sent the message over MM1. The MMS delivery notification message came in via SMS, and NowSMS decoded it as an MMS delivery notification, and routed it to my MM7 app. We'll probably need to tweak the way these routings are defined. I do think it is a little difficult to setup, but the flexibility is fantastic. The difficulty will hopefully go away soon as we complete the documentation. We plan to cover different "usage scenarios" to explain how you would configure the settings for different common scenarios as a starting point. I rambled a bit, but hopefully the explanation makes sense. I'll be curious to hear how you get on with this configuration. -bn | |||
| barbara |
I followed your instructions and am now receiving delivery reports. thanks for your help. | |||
| Anonymous |
Hi! Well, i will append my questions here then  1. Can you tell me the real difference between "Send MMS Message" and "Send WAP Multimedia Message"? Stupid question maybe, but if GPRS is not working, which one should I try? "Send WAP Push Message" and "Send WAP Multimedia Message" work fine, but "Send MMS Message" does not.. GPRS only? Or bad MMS settings in phone? 2. I still haven't found a working MM7 post (like the one is in the ETSI TS 123 140 V5.7.0 (2003-06), but that one does not work either). Point is, I would like to have very simple MM7 post with all headers, as it should be in order to work with NowSMS. I know, there must be POST header (post, host, content-length), soap envelope and as attachments all the contents of MMS, but I seem not to be able to compile any kind of working MMS POST message that would successfully go through NowSMS into my phone ;( Thakns for Your patience... Antti | |||
| Bryce Norwood - NowSMS Support |
Hi Antti, 1.) No, not a stupid question. Until we finish a major update of the docs, I expect a lot of people to ask similar questions. "Send WAP Multimedia Message" builds a dynamic URL on the MMSC, and publishes it as a WAP WML page with links to embedded objects. A WAP push message is sent to the phone with a pointer to this URL. "Send MMS Message" builds a dynamic URL on the MMSC with the objects embedded in a binary MMS message file. An MMS notification message (encapsulated in a WAP push) is sent to the phone with a pointer to this URL for the phone to retrieve the MMS message content. If "Send WAP Multimedia Message" works fine, but "Send MMS Message" does not ... then this tells us that the gateway itself is properly configured. It's building its dynamically generated URL properly, and a phone is able to connect back over the internet to the MMSC to open the content of the WAP push message. As a similar URL is published for the content of the MMS message ... but the MMS is not working ... this tells us that the most likely scenario is that configuration settings on the MMS client on the phone do not allow the phone to make a connection to an external MMSC. Typically an MMS client on the mobile phone gets configured with a GPRS APN and WAP gateway IP address setting, just like the WAP browser. Many mobile operators have established separate APN/gateway combinations for MMS traffic, where the APN/gateway only allows connections to the operator MMSC, effectively blocking the ability to receive messages from external MMSCs. In those "blocked" scenarios, the only solutions are: a.) Change the MMSC settings in the phone to use a less restrictive GPRS APN/WAP Gateway. (This might prevent the user from being able to send messages through the operator MMSC.) b.) Use multimedia WAP push as an alternative (only suitable for some applications). c.) Submit messages through the operator MMSC. For lower volumes, this can be done with NowSMS and a GSM/GPRS modem, where you define an "MMS Routing" definition using MM1 to connect to an operator MMSC over GPRS. For higher volumes, you would need an account with an MMSC that supports an alternate protocol such as MM7 or EAIF. 2.) Is the POST being rejected? Or is it being submitted into NowSMS for processing, but failing to be delivered because of the problems in #1? If the POST is being rejected, what do you see as the response coming back? Are you using HTTP Basic Authentication (Authorization: header) to specify the username and password of the "MMSC VASP" account that is submitting the message? Basically, to connect to NowSMS via MM7, you need to do this: a.) Define one or more accounts under the "MMSC VASP" definition. Enable the account to connect using "MM7". b.) The "MMSC VASP" account can either be defined with an "account name" and "password", where the MM7 client uses HTTP Basic Authentication (Authorization: header) to login when it posts via MM7 ... or the "account name" should specify an IP address, and any MM7 connection will be accepted from that specified IP address without authentication. c.) The MM7 client needs to post to a URL of http://ip.address.of.nowsms:port/mm7. "Port" is the HTTP port number configured for the MMSC on the "MMSC" configuration page of the dialog. If your post is failing, can you post the content of a simple HTTP POST that you are generating here? You also might want to enable the debug log for the MMSC (manually edit MMSC.INI, and add Debug=Yes under the [MMSC] section header, then restart the MMSC service). The MMSCDEBUG.LOG will log any posts that are submitted to the gateway, and we could get an idea of what your client application is actually submitting to the gateway by looking at this log file. -bn | |||
| Bryce Norwood - NowSMS Support |
Just a side note while I'm thinking of it. When you submit a message to NowSMS via MM7, it is actually possible to tell NowSMS to deliver the message as a multimedia WAP push instead of MMS format. To do this specify the recipient address using a type of "WAPP". For example: +447778001210/TYPE=WAPP Normally, you'd specify "/TYPE=PLMN" ... "/TYPE=WAPP" is a proprietary extension in NowSMS. -bn | |||
