On Fri, Oct 31, 2008 at 2:01 AM, Jovan Kostovski <[EMAIL PROTECTED]> wrote: > npi (national prefix indicator)
correction: npi stands for numbering plan indicator i guess i was to tired list night :) On Fri, Oct 31, 2008 at 10:08 AM, Falko Ziemann <[EMAIL PROTECTED]> wrote: > 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. That's the way it should be done. Kannel will have internal lookup table for the messages. Having the message_id if it's available, might be useful in some cases as well. > 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. You can do this now, by parsing the access.log and searching for sent messages and their delivery reports and comparing them, but querying Kannel for message status would be great. 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) The multipart messages are sent as separate SMS messages but are connected to each other by special UDH values. I'm sure that the sm_submit must have different sequence_number for each message, but i'm not sure if the SMSC will return different message_id for each part or it will be the same one. The only parameter that shows to the device that it has to concatenate all the messages is the UDH field. It would be nice If anyone who has access to a SMSC makes a trace what will be returned by the SMSC in the submit_sm.message_id field for multipart message. BR, Jovan
