| ValidityPeriod param |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through April 11, 2011 ⬆ |
◄ ► |
| Author | Message | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 87 Registered: 01-2008 |
Whether parametre ValidityPeriod in Accounting Callbacks when sending occurs through SMPP is transferred? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2371 Registered: 08-2008 |
Hi Alexandre, This parameter is not passed in the accounting callbacks. -- Des NowSMS Support | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 92 Registered: 01-2008 |
Whether it is possible to make additional function in NowSMS which would do the following: For everyone SMSC in SMSGW.ini registers Validity period on-default. 1. If in transferred (through SMPP or HTTP) the message it is not established Validity period that in is exposed value on-default SMSC 2. If in transferred message Validity period is more than value on-default for given SMSC value on-default SMSC is exposed. Whether probably to make similar changes in NowSMS? | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 93 Registered: 01-2008 |
Also it would be very useful if parametre Validity period would be transferred in callback ` s as sometimes it was impossible to define with what term of a life the message is transferred. Thanks. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2388 Registered: 08-2008 |
There is a capability to set a default validity period if one is not supplied in the message submission. (Under [SMPP - server:port] ValidityPeriod=xxxxxxxx where xxxxxxxx is a validity period in SMPP format.) However, there is no capability to pass or set the validity period via accounting callbacks. -- Des NowSMS Support | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 97 Registered: 01-2008 |
I meant, if you send a message, the user is exposed Validity Period, he attended a callback `s stage SMSSEND. Ie in the callback, we will not need to change it, we need write (ValidityPeriod value) it only to database at the stage SmsSend. And he wanted to clarify in about default validity period under [SMPP - server: port]. 1. If the query parameter is present validity period, then sending it vseravno will be substituted from the settings [SMPP - server: port]? 2. If the validity period, absent a query, default validity period will be substituted in any method of shipment (SMPP,HTTP)? 3. If the query value greater than the default validity period, it will change by default validity period of the shaft? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2391 Registered: 08-2008 |
I can only answer how it works now. The validity period is not passed to any callbacks. 1.) No. If validity period is included in submission, it will be used. 2.) Yes. 3.) No. If validity period is included in submission, it will be used. The INI setting is only used when a validity period is not specified. | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 98 Registered: 01-2008 |
In the near future we can expect this functionality that I wrote above?  | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2394 Registered: 08-2008 |
I'll see what we can do. I notice also that the ServiceType parameter should be included in the accounting callback, and it is not. (I can make a stronger argument that the ServiceType parameter should be there, and while it is being added, also add support for the Validity parameter.) | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 99 Registered: 01-2008 |
Ok. We will wait for update. Thanks | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 101 Registered: 01-2008 |
Sorry for bump no any update yet ? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2410 Registered: 08-2008 |
It's still in the queue. There are a few other changes/additional settings for other customer requirements that are being added at the same time. It will probably be ready by the early part of next week. | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 103 Registered: 01-2008 |
Ok. thanks. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2432 Registered: 08-2008 |
"ServiceType" and "Validity" parameters have been added to the accounting callbacks. Update @ http://www.nowsms.com/download/nowsms20100813.zip. -- Des NowSMS Support | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 112 Registered: 01-2008 |
Big thanks! We will test it | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 133 Registered: 01-2008 |
Hello Des! I wanna ask about: "(Under [SMPP - server:port] ValidityPeriod=xxxxxxxx where xxxxxxxx is a validity period in SMPP format.)" The value after param "ValidityPeriod" must be relative (020610233429000R) ? Or in format like ValidityPeriod=1440M ? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2566 Registered: 08-2008 |
Hi Alexandre, This is an old setting ... introduced before we added a "Validity=" parameter when submitting messages. So it uses the raw SMPP format, such as the relative example that you give above (which I recognise from the example in the SMPP specification). -- Des NowSMS Support | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 134 Registered: 01-2008 |
hmmm...so i can`t set default Validity period for SMSC connect? Such in url like: [SMPP - server: port] Validity=1440M This is necessary, for example, when the login has not set a term of his request (SMPP, HTTP). Because some SMSC is the default setting 72 hours or 168 hours, but I need to show example 24h, if the login does not pass the value itself. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2567 Registered: 08-2008 |
Yes, but you set it in relative format, using the raw SMPP format, just like the example that you cited previously. For 24 hours, 1 day, it would be this: [SMPP - server:port] ValidityPeriod=000001000000000R This value is only used if a validity period value is not passed by the submitting application. -- Des NowSMS Support | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 135 Registered: 01-2008 |
Ok.Thanks Des | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 144 Registered: 01-2008 |
Hi! Whether probably to make similar changes in NowSMS: If in transferred message Validity period is more than value on-default for given SMSC value on-default SMSC is exposed. It`s posible ? | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 146 Registered: 01-2008 |
sorry for bump  no any news ?  | |||
| Alex Kaiser Frequent Contributor Username: Alex_k Post Number: 169 Registered: 07-2006 |
Hi Des, I agree with Alexandre, there should we the way to override Validty period for certain messages. 2 weeks delivery scheme is a legacy for the most of traffic. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2751 Registered: 08-2008 |
Sorry Alexandre, but I have no news. Perhaps in the future we can add a MaxValidityPeriod setting that would accomplish what you want. For now, it is up to the upstream SMSC how they wish to handle a message that exceeds their maximum validity period. Or, as the validity period of the submitted message is included in the HTTP callback (the original issue in this thread), you could choose to reject the message if the validity period is too long. (I would suggest including SMPPErrorCode=0x62 in the accounting response, which is the ESME_RINVEXPIRY error for an invalid validity period/expiry.) Alex K.'s question appears to be different. It is related to validity periods, but not in the same way. If you want to use a different validity period for certain messages, you can specify it when you submit the message. The setting referenced above simply refers to the default setting. -- Des NowSMS Support | |||
| Alex Kaiser Frequent Contributor Username: Alex_k Post Number: 171 Registered: 07-2006 |
Hi Des, Yes, default validty period is ok, user's setting would be replaced but if user's validity period less than default value then it would be a problem for 100%. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2757 Registered: 08-2008 |
Hi Alex, The default validity period is only applied if the user has not specified a validity period. -- Des NowSMS Support | |||
| Alex Kaiser Frequent Contributor Username: Alex_k Post Number: 172 Registered: 07-2006 |
Hi Des, That's correct. But let me explain the scenario: - We've connected to several SMSC with various maximum validity periods. - We limiting validity period to 48 hours, in 99% cases that's enough. Expanding that period will make our statistics very complex and there's no sense to make it in that way. It works fine when validity period isn't set to the message or longer - we make it default and that's it. But when customer sets it to 2 hours (afraid of late messages or time-sensitive information) - we can't override default value and expand the period. That's why I’m asking for the override of validity period. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2766 Registered: 08-2008 |
Hi Alex, But if the customer asks for 2 hours because it is time sensitive information, that's their problem if that is not what they really want. I understand that you'd like more flexibility in this area, I just think that in the bigger picture there are a lot better places for us to be focusing our engineering efforts. -- Des NowSMS Support | |||
| Alex Kaiser Frequent Contributor Username: Alex_k Post Number: 173 Registered: 07-2006 |
Hi Des, Honestly, I disagree about efforts on sensitive information, some automated systems have various scenarios on expired SMS, like sending email or operator's call, extended validity breaks the logic. Marketing issue: "Come today - 30% off" if message arrives on a next day - SMS-provider will achieve the punishment. Regards, Alex K. | |||
| Alex Kaiser Frequent Contributor Username: Alex_k Post Number: 177 Registered: 07-2006 |
Hi Des, Any ideas on that issue? Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2863 Registered: 08-2008 |
Sorry Alex, I don't understand exactly what capability you are asking for. Let me rephrase what I said in the previous reply. If the customer asks for 2 hours because it is time sensitive information, that's their problem if that is not what they really want. To override the 2 hour request and replace it with the default validity period does not seem like a good action to take. Perhaps I am misunderstanding your point? -- Des NowSMS Support | |||
| Alex Kaiser Frequent Contributor Username: Alex_k Post Number: 179 Registered: 07-2006 |
Hi Des, Thanks for the reply. Let me explain our issue again. We need to limit maximum validity period to 48 hours and we can make it by: 1. Setting ValidityPeriod=48H in SMSGW.ini. In that scenario validity period will be overridden, so we will get problems from customers with VP=2H (less than maximum VP). 2. Returning 0x62 error can cause incompatibility with some user's SMPP client and cause more problems than 1st approach. So, we need a solution to keep VP floating but override a value which exceeds maximum VP set by us. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2870 Registered: 08-2008 |
Hi Alex, Ok ... I think I understand. The way that it currently works is that if a validity period has been set for the message when it is submitted, that value is used for submitting the message upstream. The "ValidityPeriod=" default setting is only applied if one has not been explicitly set. So if a customer sets 2H, they are fine. If a customer does not set one, they get 48H. The only problem I see is that if a customer specifies longer than 48H, your upstream provider may reject the message. (In which case the customer needs to understand that they are not allowed to do this.) -- Des NowSMS Support | |||
