Re: non standard message_id breaks DLR

Hi Nisan,

I believe, you have not undestand the issue...
Very long is not a problem for kannel, the problem is, that message_id 
received in submit_sm is not the same as in delivery receipt later. Just look 
this example:
	submit_sm -> submit_sm_resp -> msg_id = 02/00/b9637bb4/11353872920997
but in delivery receipt:
	message_id = 3110304692

This is definit. not allowed! Because message id in delivery receipt is only 
the part of message id from submit_sm_resp. You can't convert it in any form 
generic for all SMSCs.

Am Donnerstag, 26. Juni 2003 17:56 schrieb Nisan Bloch:
> Hi
>
> At 01:12 PM 6/26/03 +0200, Alexander  Malysh wrote:
> >Hi David,
> >
> >strange...
> >
> >I have not never seen such message_id! One think i can say, SMSC is soooo
>
> we have.. (No provider names mentioned) and yes they are real
> flaky..Although this is a valid msg_id albeit very long.
> NULTERMINATED(message_id, 65)..
> I have a patch for this. Please bear with me for a few more days  and I
> will release a whole slew of patches for voting.
>
> Nisan
>
> >buggy! It's not allowed to get one message id in submit_sm_resp and
> > another one or part of them in delivery receipt. I would propose, you
> > contact your operator and give him a hint to look in SMPP spec. ;)
> >
> >You can do only one here, write workaround for this...
> >
> >Am Donnerstag, 26. Juni 2003 13:05 schrieb David Tully:
> > > Hi!
> > >
> > > I'm getting back a strange (non-standard?) message_id in submit_sm_resp
> > >
> > > Alexander - sorry for assuming it was a DLR problem! :)
> > >
> > >
> > > 2003-06-25 12:31:56 [6] DEBUG:   type_name: submit_sm_resp
> > > 2003-06-25 12:31:56 [6] DEBUG:   command_id: 2147483652 = 0x80000004
> > > 2003-06-25 12:31:56 [6] DEBUG:   command_status: 0 = 0x00000000
> > > 2003-06-25 12:31:56 [6] DEBUG:   sequence_number: 2 = 0x00000002
> > > 2003-06-25 12:31:56 [6] DEBUG:   message_id:
> > > 2003-06-25 12:31:56 [6] DEBUG:    Octet string at 0x80d1798:
> > > 2003-06-25 12:31:56 [6] DEBUG:      len:  29
> > > 2003-06-25 12:31:56 [6] DEBUG:      size: 30
> > > 2003-06-25 12:31:56 [6] DEBUG:      immutable: 0
> > > 2003-06-25 12:31:56 [6] DEBUG:      data: 30 32 2f 30 30 2f 62 39
> > > 02/00/b9 2003-06-25 12:31:56 [6] DEBUG:      data: 36 33 37 62 62 34 2f
> > > 31 637bb4/1 2003-06-25 12:31:56 [6] DEBUG:      data: 31 33 35 33 38 37
> > > 32 39 13538729 2003-06-25 12:31:56 [6] DEBUG:      data: 32 30 39 39 37
> > > 20997 2003-06-25 12:31:56 [6] DEBUG:    Octet string dump ends.
> > > 2003-06-25 12:31:56 [6] DEBUG: SMPP PDU dump ends.
> > >
> > >
> > > In the deliver_sm, I get back a decimal message_id..
> > >
> > > 2003-06-25 12:32:01 [6] DEBUG:   short_message:
> > > 2003-06-25 12:32:01 [6] DEBUG:    Octet string at 0x80d1de8:
> > > 2003-06-25 12:32:01 [6] DEBUG:      len:  123
> > > 2003-06-25 12:32:01 [6] DEBUG:      size: 124
> > > 2003-06-25 12:32:01 [6] DEBUG:      immutable: 0
> > > 2003-06-25 12:32:01 [6] DEBUG:      data: 69 64 3a 33 31 31 30 33
> > > id:31103 2003-06-25 12:32:01 [6] DEBUG:      data: 30 34 36 39 32 20 6f
> > > 61 04692
> > >
> > >
> > > The middle bit of the submit_sm_resp is the message_id - 'b9637bb4' out
> > > of '02/00/b9637bb4/11353872920997'
> > > The rest is junk - the last number is the destination number.
> > >
> > > I am not a C programmer - I can hack stuff together and that's about
> > > it.
> > >
> > > I figure I'm going to have to change the submit_sm_resp part of
> > > smsc_smpp.c to strip out the stuff I don't want from the message_id.
> > >
> > > Any comments / suggestions?
> > >
> > > Regards,
> > >
> > > David.
> >
> >--
> >Best regards / Mit besten Grüßen aus Düsseldorf
> >
> >Dipl.-Ing.
> >Alexander Malysh
> >___________________________________________
> >
> >Centrium GmbH
> >Vogelsanger Weg 80
> >40470 Düsseldorf
> >
> >Fon: +49 (0211) 74 84 51 80
> >Fax: +49 (0211) 277 49 109
> >
> >email: a.malysh at centrium.de
> >web: www.centrium.de
> >msn: olek2002 at hotmail.com
> >icq: 98063111
> >___________________________________________
> >
> >Please avoid sending me Word or PowerPoint attachments.
> >See http://www.fsf.org/philosophy/no-word-attachments.html

-- 
Best regards / Mit besten Grüßen aus Düsseldorf

Dipl.-Ing.
Alexander Malysh
___________________________________________

Centrium GmbH
Vogelsanger Weg 80
40470 Düsseldorf

Fon: +49 (0211) 74 84 51 80
Fax: +49 (0211) 277 49 109

email: a.malysh at centrium.de
web: www.centrium.de
msn: olek2002 at hotmail.com
icq: 98063111
___________________________________________

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html