Stipe Tolj schrieb:
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. If we stay with this idea, (which would be a really cool feature) kannel has to generate his own unique transaction ids and needs the function to assign the smsc message_id to it's own ones. If you want to cancel a sms that isn't delivered to a smsc yet, you simply don't have a message_id. Would be really great, but this is definitly a new major release. Giving kannel an internal unique id is also a nice idea to implement a traceable billing, so a really nice function. But there are really much things to consider (you post a request to kannel and it creates 2 concat message, are this 2 trans-ids? Just one example) Regards Falko 2008/10/31 Ken Bellars <[EMAIL PROTECTED]> > 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 > >
