| Validity Period |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 14, 2010 ⬆ |
◄ ► |
| Author | Message | |||
| Miguel Fernández Corral New member Username: Mfcorral Post Number: 5 Registered: 08-2010 |
Hi Des & Support Team again, our company adquired a license for NowSMS to start a pre-production tests. I wrote in this board some weeks ago about an issue between us and our operator Movistar in Spain in relation with the Data Coding Schema. We have another issue with the SMPP implementation of our operator. Our operator supports the SMPP validity period feature, but with a little behaviour diference that I explain: when a message expire in the operator's pending message queue (and the validity period is set), he send us a DeliverSm with a Delivery Receipt (DR) to inform us about the message expiration, but the "stat" field of the DR is set to UNDELIV and the "err" field is set to 255 (like a normal undelivered message when the subscriber number doesn't exists). With this behaviour it's imposible to know what happened with the message (the real reason about the message was imposible to deliver). We widely talk about this issue with the operator's I.T. department without any solution (a totally failure). Then we only have one posibility to fix the issue: your help  . We need to request a new feature for NowSMS, this is: the tracking when if a message have a validity period set and is waiting for a DR, when the DR for that message is received and the "stat" field is set to UNDELIV, check if the message is expired and then, if is really true, change the "stat" field of the DR from UNDELIV to EXPIRED. I wait for your comments in the hope of we can solve this issue in the best way. Best regards and thank you very much, Miguel Fernández. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2545 Registered: 08-2008 |
Hi Miguel, Sorry to take so long to respond ... I had to give this some additional thought and discuss it with some colleagues. Unfortunately it is not unusual for providers to take this type of approach. Do you get a "submit date:" and "done date:" in the response? Perhaps the best way to handle this would be for your application to evaluate these values to see if they exceed a validity period threshold? -- Des NowSMS Support | |||
| Miguel Fernández Corral New member Username: Mfcorral Post Number: 6 Registered: 08-2010 |
Hi Des, the Delivery Receipt (DR) from our Operator is: id:4C543A18 sub:001 dlvrd:001 submit date:1010011647 done date:1010011652 stat:UNDELIV err:255 text: The DR was obtaining from a SubmitSm request to a switched off mobile device and the validity period set to 5 minutes. As you can see, instead of an expected EXPIRED state, Movistar is setting it to UNDELIV with error code set to 255. The problem we have is a new client (requesting us to support a very large traffic per month) to send him an EXPIRED message state when this situation happen. We have the following interconexion: SMPP client <-> NowSMS SMPP server interface <-> NowSMS routing to an external SMPP server (Movistar SMSC) Then we don't have the ability to check and change de DRs contents because we can't touch them with that connection schema. Any idea about how to support it transparently for the client? Thanks in advance and best regards, Miguel Fernández. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2548 Registered: 08-2008 |
Hi Miguel, I'm going to need some more time to discuss this with my colleagues. The problem is that it is an issue very specific to your provider, and we are hesitant to modify the core NowSMS logic for this particular scenario. Therefore, we are trying to think of a more generic facility that might allow additional logic to be conditionally applied. Perhaps an override that would allow these delivery receipts to be forwarded to a 2-way command instead of directly to the original submitter. Or perhaps an extension to the SMS accounting logic that allowed the message content to be modified. Unfortunately, I don't have any quick answers. I'm sure it would be easier for us to just include a built-in check to try to determine if the cause of failure was validity period expiration, but in discussing this with my engineering colleagues, they are concerned that this may be too specific to a particular installation. We need to have some more discussions on this, unfortunately our technical director is away this week. Please be patient, and I'll see what we can do. -- Des NowSMS Support | |||
| Miguel Fernández Corral New member Username: Mfcorral Post Number: 7 Registered: 08-2010 |
Hi Des, I understand perfectly all about you told, so I'll stay waiting for a solution. I hope we find out the best way to do it. Please, keep me informed about any change in the issue. Regards, Miguel Fernández. | |||
| Leonardo Figon New member Username: Leonardo Post Number: 1 Registered: 11-2010 |
Any news About this issue? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2615 Registered: 08-2008 |
Does the provider only return err:255 for expired messages? I could see the possibility of remapping UNDELIV to EXPIRED if it could be done for a particular error code. -- Des NowSMS Support | |||
| Miguel Fernández Corral New member Username: Mfcorral Post Number: 9 Registered: 08-2010 |
Hi again Des, the operator really send us a DR with UNDELIV state and 255 error code for undelivered or expired messages, but we need to compare the done date with the validity period applied to the submit date to see if the message in fact was expired. Any posibilities? Regards, Miguel Fernández. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2621 Registered: 08-2008 |
Hi Miguel, I've been over this with our engineering and product managers. And the problem that we have is that we don't see a way to implement this as part of our standard product roadmap. That's not to say that we couldn't or wouldn't do it, it's just that there would likely have to be an additional charge associated with it. The logic is relatively simple, but the biggest technical hurdle is that we do not currently save the input validity period. So we do not have that information when processing the delivery receipt. I'd suggest that the best way to move forward would be for you to have a discussion with Keith Norris, who is the product manager. He can interface on what, if any, costs would be involved. You can contact him as keith@nowsms.com, or call our office at +44.1883.621100. -- Des NowSMS Support | |||
