| Prepaid Charging |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through April 21, 2010 ⬆ |
◄ ► |
| Author | Message | ||||
| Joseph Smith New member Username: Falangjoe Post Number: 3 Registered: 08-2006 |
Union Wireless v2008.06.03 I am integrating the now MMSC with a prepaid interface. 1. Charging for Sending If a prepaid customer sends an MMS via MM1, I am charging them during the PreAuth event. If charging fails, I block the message. 2. Charging for Receiving If a prepaid customer is sent an MMS, things are more difficult. The message may have been sent to several recipients. We can't charge during the PreAuth event, because blocking at this point would block all the recipients. This is the soluting that I came up with. Setting DisableMMSDirectDelivery=Yes will generate a routing event for every recipient. During the routing event the recipeint can be charged. If charging fails we can't return block, because that would block all other recipients. Instead, we return a non existant VASP. This seems to stop the message from being delivered to just that one recipient. My question is the following. Will returning a non existant VASP cause any problem, and will this behavoir stay the same in future versions. Thanks, Joseph | ||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 895 Registered: 08-2008 |
Hi Joseph, That is a difficult scenario. In most of the world, the sender pays, and receiving is free. But in the US and a few other countries, there are typically both sender and receiver charges. We have had to face somewhat similar scenarios though. For example, a system might not allow international recipients. However, in those cases, if any single recipient is unacceptable, the message is rejected by the MMSC. I wish there were a better solution, but the alternative is to accept the message and have the sender think that all recipients will receive it. One thing that is possible, which you might not be aware of, is that it is possible for the PreAuth to return a text field in the error response, which many phones will display. So you could return an error response that said something like: xxxxxxxx is not able to receive messages at this time This is done by including RejectMessage=some error text in the PreAuth response. (Put a carriage return/line feed after "some error text" to indicate the end of the RejectMessage.) Routing the message to a non-existant VASP is an interesting approach. It might cause problems in the future if it truly points to a non-existant route. If the "MMSC Routing" definition exists, but is simply not valid, that would be less troublesome. However, there needs to be some mechanism to get these invalid messages rejected or removed, or they will build up and could lead to performance problems. I think I've got a good idea for a way to handle this ... Define an "MMSC Routing" for these rejects with an MM4 type. The "Server Address" should be a valid SMTP e-mail server host name ... preferably a mail server somewhere on your network where the administrator knows that you are going to be purposefully sending it invalid messages. "E-Mail Domain" should be an obviously invalid domain name such as "reject.mmsc" (use whatever clever name makes sense to you). The other configuration options don't really matter. I would use the "MM4" format and not request an Ack, but I don't think these settings will have an impact one way or the other. When NowSMS has a message for one of these recipients, it is going to connect to the mail server and try to send a message to "phonenumber@reject.mms". Assuming that the mail server rejects this at the SMTP protocol layer, the MMSC will see the recipient as being actively rejected ... remove the message from the queue ... and generate a non-delivery message to the sender (this error message is not configurable, it will just indicate that the recipient was rejected). -- Des NowSMS Support | ||||
| Joseph Smith New member Username: Falangjoe Post Number: 4 Registered: 08-2006 |
Des, I set up the MM4 rejection route and it worked great. I had previously introduced dynamic routing and was returning route=Deny instead of the correct route=BlockMessage. From your response, I realized that these were building up in the VASPQ directory. I deleted all of these and the peak processing went from 100% to 20% percent. Thanks, Joseph | ||||
| Joseph Smith New member Username: Falangjoe Post Number: 13 Registered: 08-2006 |
I am trying to get RejectMessage to work when denying an MMS message. Could you tell me the exact format of the response. Right now I have "PreAuth=DenyRejectMessage=ErroText\r\n". This and other variations of it do not seem to work. Thanks, Joseph | ||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1229 Registered: 08-2008 |
Hi Joseph I don't see any reason why that wouldn't work. Technically we are just scanning through the text of the response looking for: PreAuth=Deny We then also scan for RejectMessage= ... and use all of the text after it up to a line break as the error to be sent back. It's all very similar to the Route= response that you seem to already be using. Is it possible to enable the MMSCDEBUG.LOG to see what it reports about the callback? (If you can, then try again and e-mail the log to nowsms@nowsms.com with "Attention: Des" in the subject line.) -- Des NowSMS Support | ||||
| Joseph Smith New member Username: Falangjoe Post Number: 14 Registered: 08-2006 |
Des, This includes the request. I was sending using 13077414444. I tried sending with two nokia phones and a sony phone. Non of them displayed the message. Is this very widely supported? Thanks, Joseph
| ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7848 Registered: 10-2002 |
Hi Joseph, I can tell that we're definitely seeing your "RejectMessage=" response. I edited your log file attachment so that it only includes the response that is being sent back to the sending client. Your "Insufficient Funds" text is being returned in the X-Mms-Response-Text field. The client should display this to the user. Well, actually the MMS specifications weren't clear initially about this. Initially in MMS 1.0 and 1.1, the field was simply defined as optional with this text: "Description which qualifies the Response-status-value." Logic would suggest that a client should display this information to the user if it is available. Starting with the MMS 1.2 spec, a section was added to the spec to clarify status issues:
Now ... we don't currently let you set the status code value. We only use a generic status code value, because until recently the status codes were not very comprehensive. For example, a status code that addresses insufficient funds for prepaid was only added beginning with MMS 1.3. The device in question is using MMS 1.2, so by the spec they should be displaying this text. Sadly, for most device manufacturers there is not a compelling reason to upgrade to MMS 1.3. The primary new feature in MMS 1.3 is application addressed MMS messages. However the Java Community Process already defined a mechanism for application addressed MMS messages in JSR-205. The JSR-205 implementation is compatible with all versions of MMS, including MMS 1.0. JSR-205 was completed in 2004. MMS 1.2 was completed in 2005. Why the OMA MMS group was unaware of JSR-205 when defining a completely different implementation for application addressed messages remains a mystery. The bottom line is that MMS 1.3 is not compelling. Back to the issue ... When a message is rejected, NowSMS returns a status code Error-service-denied. As I re-read MMS 1.2, we should be returning a new status code Error-permanent-service-denied. The spec tells clients that they should interpret Error-service-denied as Error-permanent-failure. What the difference is ... I don't know ... those codes are pretty much the only codes applicable in MMS 1.2, and they are both indescriptive. The other status codes we could use are more system failure oriented. The status code Error-permanent-lack-of-prepaid was not added until MMS 1.3, so it couldn't be returned to an earlier client. More info than you wanted or needed, I know ... I guess the bottom line is that the client should be displaying the text. We are encoding it correctly. What you might want to do is use this accounting event as a trigger to send an SMS back to the customer to let them know that they need a recharge. -bn | ||||
3077414444 PreAuthRequest
