Hi, Imagine this: Kent has a Kannel server providing sms service to 10 users. User1 sends a message and decided he needs to cancel it. Without the intervention of Kent, the 'provider', how will user1 knows the message_id to pass to the Kannel HTTP url with the proposed cancel command?
By default, does Kannel currently return message_id as an HTTP response to a Sendsms HTTP request? What if a user has included say about 1,000 MSISDN on the Sendsms HTTP request, will Kannel also return 1,000 message_id in the HTTP response (with a delimiter)? The above is especially necessary for message and message_id cross-referencing, so that at the application level, cancelation can be implimented programatically. On 10/31/08, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote: > 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 >> >> > -- Regards, Kenny "Whosoever desires constant success must change his conduct with the times."-Niccolo Machiavelli
