Re: SMPP 3.4 C-Octet String Termination
Alex, Have experienced SMSC that did this. In our case it was configurable on SMSC - eventually it was turned off. It may be worth seeing if you can do the same (given the SMSC's adding it). Cheers, Alan On Thu, 2003-02-27 at 03:52, Alex Judd wrote: > We're working with a SMPP 3.4 server that validly (according to the 3.4 > specs) terminates the C-Octet Strings it sends us with a NULL character. > This currently isn't handled directly by Kannel and ends up as an extra > character on the message content. > > For example a message of AAA, length 3, now arrives at Kannel as AAA@, > length 4 [which is obviously wrong] > > I've made a short term workaround to remove the character by using the > octstr_strip_nonalphanums on the msg-sms.msgdata however I'm interested in > whether everyone thinks Kannel should strip off this null character (like I > do) or whether this should occur at application level? > > If it's Kannel I'll submit a proper patch > > Alex > Skywire > http://www.skywire.co.uk/ -- Alan McNatty <[EMAIL PROTECTED]>
Re: SMPP 3.4 C-Octet String Termination
Hi Alex, Am Mittwoch, 26. Februar 2003 16:30 schrieb Alex Judd: > Alexander > > Not sure if that's true. > > According to the SMPP3.4 specs "C-Octet String A series of ASCII characters > terminated with the NULL character. Notes: (i) Reference made to NULL > settings of Octet-String fields implies that the field consists of a single ^^ Single is single;) That means only NULL without message body ! But you received 0x410x6c0x650x780x00 ??? This is totally wrong ... > NULL character, i.e., an octet encoded with value 0x00 (zero)." > > Which would mean it's valid to send a message content of > > 2003-02-26 12:24:42 [6] DEBUG: SMPP[Vittel]: Got PDU: > .. > 2003-02-26 12:24:42 [6] DEBUG: short_message: > 2003-02-26 12:24:42 [6] DEBUG:Octet string at f4ef8: > 2003-02-26 12:24:42 [6] DEBUG: len: 5 > 2003-02-26 12:24:42 [6] DEBUG: size: 6 > 2003-02-26 12:24:42 [6] DEBUG: immutable: 0 > 2003-02-26 12:24:42 [6] DEBUG: data: 41 6c 65 78 00Alex. > ..^^^ > > which then is translated by Kannel as > > 2003-02-26 12:24:42 [6] INFO: Starting to service from > <447740305115> to <80118> > > which is defintiely wrong. > > Yes, no? > > Alex > > - Original Message - > From: "Alexander Malysh" <[EMAIL PROTECTED]> > To: "Stipe Tolj" <[EMAIL PROTECTED]> > Cc: "Alex Judd" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, February 26, 2003 3:16 PM > Subject: Re: SMPP 3.4 C-Octet String Termination > > > it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is > > 0x00 ;) > > > Am Mittwoch, 26. Februar 2003 16:10 schrieb Stipe Tolj: > > > Alexander Malysh wrote: > > > > this is not the kannel problem! Your smsc sned wrong pdu: > > > > please look smpp v.3.4 issue 1.2 site 61... > > > > short_message field is Octet-String and not C-Octet-String. > > > > Your smsc is just buggy ;) > > > > > > if that's the case, Alex, could you ask which explicit SMSC it is? So > > > we can put the vendor and the model on a "not spec conform black-list" > > > > > > :) > > > > > > Stipe > > > > > > [EMAIL PROTECTED] > > > --- > > > Wapme Systems AG > > > > > > Vogelsanger Weg 80 > > > 40470 Düsseldorf > > > > > > Tel: +49-211-74845-0 > > > Fax: +49-211-74845-299 > > > > > > E-Mail: [EMAIL PROTECTED] > > > Internet: http://www.wapme-systems.de > > > --- > > > wapme.net - wherever you are > > > > -- > > Best regards / Mit besten Grüßen aus Köln > > > > Dipl.-Ing. > > Alexander Malysh > > ___ > > > > Centrium GmbH > > Ehrenstraße 2 > > 50672 Köln > > > > Fon: +49 (0221) 277 49 240 > > Fax: +49 (0221) 277 49 109 > > > > email: [EMAIL PROTECTED] > > web: www.centrium.de > > msn: [EMAIL PROTECTED] > > icq: 98063111 -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED] icq: 98063111
Re: SMPP 3.4 C-Octet String Termination
Ahh.. I think Alexander is right DELIVER_SM specifies that short_message is a Var 0 - 254 size octets Then specified earleir in the spec. is that Var 0 - 254 is an Octet String, not a C-Octet String Octet Strings are not Null terminated. Looks like Mobay's gateway is buggy. I'll try and get them to fix it. Alex
Re: SMPP 3.4 C-Octet String Termination
Alexander Not sure if that's true. According to the SMPP3.4 specs "C-Octet String A series of ASCII characters terminated with the NULL character. Notes: (i) Reference made to NULL settings of Octet-String fields implies that the field consists of a single NULL character, i.e., an octet encoded with value 0x00 (zero)." Which would mean it's valid to send a message content of 2003-02-26 12:24:42 [6] DEBUG: SMPP[Vittel]: Got PDU: .. 2003-02-26 12:24:42 [6] DEBUG: short_message: 2003-02-26 12:24:42 [6] DEBUG:Octet string at f4ef8: 2003-02-26 12:24:42 [6] DEBUG: len: 5 2003-02-26 12:24:42 [6] DEBUG: size: 6 2003-02-26 12:24:42 [6] DEBUG: immutable: 0 2003-02-26 12:24:42 [6] DEBUG: data: 41 6c 65 78 00Alex. ..^^^ which then is translated by Kannel as 2003-02-26 12:24:42 [6] INFO: Starting to service from <447740305115> to <80118> which is defintiely wrong. Yes, no? Alex - Original Message - From: "Alexander Malysh" <[EMAIL PROTECTED]> To: "Stipe Tolj" <[EMAIL PROTECTED]> Cc: "Alex Judd" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, February 26, 2003 3:16 PM Subject: Re: SMPP 3.4 C-Octet String Termination > it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is 0x00 ;) > > Am Mittwoch, 26. Februar 2003 16:10 schrieb Stipe Tolj: > > Alexander Malysh wrote: > > > this is not the kannel problem! Your smsc sned wrong pdu: > > > please look smpp v.3.4 issue 1.2 site 61... > > > short_message field is Octet-String and not C-Octet-String. > > > Your smsc is just buggy ;) > > > > if that's the case, Alex, could you ask which explicit SMSC it is? So > > we can put the vendor and the model on a "not spec conform black-list" > > > > :) > > > > Stipe > > > > [EMAIL PROTECTED] > > --- > > Wapme Systems AG > > > > Vogelsanger Weg 80 > > 40470 Düsseldorf > > > > Tel: +49-211-74845-0 > > Fax: +49-211-74845-299 > > > > E-Mail: [EMAIL PROTECTED] > > Internet: http://www.wapme-systems.de > > --- > > wapme.net - wherever you are > > -- > Best regards / Mit besten Grüßen aus Köln > > Dipl.-Ing. > Alexander Malysh > ___ > > Centrium GmbH > Ehrenstraße 2 > 50672 Köln > > Fon: +49 (0221) 277 49 240 > Fax: +49 (0221) 277 49 109 > > email: [EMAIL PROTECTED] > web: www.centrium.de > msn: [EMAIL PROTECTED] > icq: 98063111 > >
Re: SMPP 3.4 C-Octet String Termination
Alexander Malysh wrote: > > it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is 0x00 ;) so it's a pat situation?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: SMPP 3.4 C-Octet String Termination
it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is 0x00 ;) Am Mittwoch, 26. Februar 2003 16:10 schrieb Stipe Tolj: > Alexander Malysh wrote: > > this is not the kannel problem! Your smsc sned wrong pdu: > > please look smpp v.3.4 issue 1.2 site 61... > > short_message field is Octet-String and not C-Octet-String. > > Your smsc is just buggy ;) > > if that's the case, Alex, could you ask which explicit SMSC it is? So > we can put the vendor and the model on a "not spec conform black-list" > > :) > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED] icq: 98063111
Re: SMPP 3.4 C-Octet String Termination
Alexander Malysh wrote: > > this is not the kannel problem! Your smsc sned wrong pdu: > please look smpp v.3.4 issue 1.2 site 61... > short_message field is Octet-String and not C-Octet-String. > Your smsc is just buggy ;) if that's the case, Alex, could you ask which explicit SMSC it is? So we can put the vendor and the model on a "not spec conform black-list" :) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: SMPP 3.4 C-Octet String Termination
Hi, this is not the kannel problem! Your smsc sned wrong pdu: please look smpp v.3.4 issue 1.2 site 61... short_message field is Octet-String and not C-Octet-String. Your smsc is just buggy ;) Am Mittwoch, 26. Februar 2003 16:00 schrieb Stipe Tolj: > Alex Judd wrote: > > We're working with a SMPP 3.4 server that validly (according to the 3.4 > > specs) terminates the C-Octet Strings it sends us with a NULL character. > > This currently isn't handled directly by Kannel and ends up as an extra > > character on the message content. > > > > For example a message of AAA, length 3, now arrives at Kannel as AAA@, > > length 4 [which is obviously wrong] > > > > I've made a short term workaround to remove the character by using the > > octstr_strip_nonalphanums on the msg-sms.msgdata however I'm interested > > in whether everyone thinks Kannel should strip off this null character > > (like I do) or whether this should occur at application level? > > > > If it's Kannel I'll submit a proper patch > > hmm, so someone is not acting spec conform, either Kannel or they?! > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED] icq: 98063111
Re: SMPP 3.4 C-Octet String Termination
> I think kannel should respect the length. > So a single octstr_trim(packet,len) should do the trick I guess. if you guys consider it a bug in Kannel, then pass the information you have to the bug tracking system. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: SMPP 3.4 C-Octet String Termination
Alex Judd wrote: > > We're working with a SMPP 3.4 server that validly (according to the 3.4 > specs) terminates the C-Octet Strings it sends us with a NULL character. > This currently isn't handled directly by Kannel and ends up as an extra > character on the message content. > > For example a message of AAA, length 3, now arrives at Kannel as AAA@, > length 4 [which is obviously wrong] > > I've made a short term workaround to remove the character by using the > octstr_strip_nonalphanums on the msg-sms.msgdata however I'm interested in > whether everyone thinks Kannel should strip off this null character (like I > do) or whether this should occur at application level? > > If it's Kannel I'll submit a proper patch hmm, so someone is not acting spec conform, either Kannel or they?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: SMPP 3.4 C-Octet String Termination
On Mittwoch, Februar 26, 2003, at 03:52 Uhr, Alex Judd wrote: We're working with a SMPP 3.4 server that validly (according to the 3.4 specs) terminates the C-Octet Strings it sends us with a NULL character. This currently isn't handled directly by Kannel and ends up as an extra character on the message content. For example a message of AAA, length 3, now arrives at Kannel as AAA@, length 4 [which is obviously wrong] I've made a short term workaround to remove the character by using the octstr_strip_nonalphanums on the msg-sms.msgdata however I'm interested in whether everyone thinks Kannel should strip off this null character (like I do) or whether this should occur at application level? I think kannel should respect the length. So a single octstr_trim(packet,len) should do the trick I guess. Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
SMPP 3.4 C-Octet String Termination
We're working with a SMPP 3.4 server that validly (according to the 3.4 specs) terminates the C-Octet Strings it sends us with a NULL character. This currently isn't handled directly by Kannel and ends up as an extra character on the message content. For example a message of AAA, length 3, now arrives at Kannel as AAA@, length 4 [which is obviously wrong] I've made a short term workaround to remove the character by using the octstr_strip_nonalphanums on the msg-sms.msgdata however I'm interested in whether everyone thinks Kannel should strip off this null character (like I do) or whether this should occur at application level? If it's Kannel I'll submit a proper patch Alex Skywire http://www.skywire.co.uk/
