I've submitted a patch to make that parameter available as "%w" last week. It's being reviewed right now, so that part of the solution is already on it's way to completion.
I think the ability to cancel a message would be a nice feature to have. I don't know if other SMSC's apart from SMPP offer a similar interface, but in that case it should be implemented as well. Definitely should be also available on the generic HTTP interface somehow (many aggregators allow to cancel messages by some means of an HTTP request). Regards, Alejandro On Thu, Oct 30, 2008 at 11:01 PM, Jovan Kostovski <[EMAIL PROTECTED]>wrote: > On Fri, Oct 31, 2008 at 12:02 AM, Kent Walker > <[EMAIL PROTECTED]> wrote: > > Hello Stipe, > > > > Yes, I am using SMPP. I think the difficulty here is that you would have > to return some sort of unique message ID in the sendsms > > response (correct me if you are already doing this and I have not seen > it). Without this unique message ID, I cannot specify which > > message to cancel. > > The submit_sm_resp contains field message_id which is set by the SMSC > which can be used to check the status, cancel or replace > the message. > > Than when sending the cancel_sm you just have to pass the message_id > of the message which should be canceled, > or if you pass null for message_id you can cancel messages by > source/destination address (msisdn of the sender/receiver), > ton (type of number) of npi (national prefix indicator) > > The SMSC works as store and forward mechanism, which means that it > first stores the arrived messages in a database and then > tries to send them, but the SMSC can be configured to send the > messages as they arrive, so you can not cancel any messages > other than the once that are pending. > > > > -----Original Message----- > > From: Stipe Tolj [mailto:[EMAIL PROTECTED] > > > At least SMPP allows "cancellation" of pending MTs via it's cancel_sm > PDU. Not > > sure how our other protocols see it. At least AT (GSM modem) is out of > scope by > > it's nature. > > I don't think that there is other way different than SMPP to do this > since direct > interaction with the SMSC is needed. > > > The "benefit" from the cancelsms URI at smsbox is that we would pass a > > corresponding msg to bearerbox of new type, i.e. mt_cancel. And we then > can > > lookup first our internal queues if the messages is yet not passed to the > SMSC, > > and if it has then escalate to the SMSC. > > That would be the right way to do this. > > > Opinions please?! > > I don't know how would I get the message_id from the submit_sm_resp. > Is there an interface/command to do this? > > I also think that adding message_id in the DLR report table if db > storage is used would be nice. This way we can check if there > are pending messages, read their ids and do something with them. > > BR, Jovan > >
