The term "octet" is used to avoid usage of the vague term "byte", which is architecture/machine dependent. One can define "byte" as 5 oits and that'd be perfectly valid.
What I'm trying to say is that "octet" != "printable ascii character" 2010/8/4 Rene Kluwen <[email protected]>: > Victor, > > I think the "Integer" types that you write below are an error in de SMPP > specification. > Even you wrote yourself (see below): " single-octet network code and > two-octets error code". > > So it should contain (copied from specs): > > The _first octet_ indicates the network type. > The following values are defined: > 1 = ANSI-136 > 2 = IS-95 > 3 = GSM > 4 = Reserved > All other values reserved. > The remaining _two octets_ specify the actual > network error code appropriate to the > network type. > > So I tend to agree with Alex more. > > Now what strikes me is that the value is defines as a C-string. Which leaves > no space anymore for the terminating '\0'! > > =-= Rene > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Victor Luchitz > Sent: Wednesday, 04 August, 2010 15:33 > To: Kannel Devel > Subject: Re: Re: SMPP's network_error_code TLV > > Nope, I think do understand the SMPP spec correctly. > > Description for this field (page 152 of SMPP v3.4 Issue 2 spec) says > the following: > > Sub-field Size Type > Network Type 1 Integer > Error Code 2 Integer > > Note that the spec explicitly defines those subfields as integers, not > octet strings. Besides the "3ff" representation is vague since the > spec doesn't mention the integer values are allowed to be passed in > hex format. And how would you transmit an error code > 0xff if you > still reserved to using octet strings? > > All of the above wouldn't matter if we didn't have at least one client > expecting the network_error_code to contain proper integer values. > > 2010/8/4 Alexander Malysh <[email protected]>: >> Hi Victor, >> >> seems you misunderstand SMPP spec. >> >> network_error_code is Octetstring with a size of 3. >> The first Octet is network type and the rest is error code. >> >> So for you example (GSM and error code 0xff)m it would be: 3ff >> >> Thanks, >> Alexander Malysh >> >> Am 02.08.2010 um 09:37 schrieb Victor Luchitz: >> >>> Hello. >>> >>> SMPP smsc handles the network_error_code TLV as 3-octets C-string, >>> which seems to be in accordance with the spec, at least at the first >>> glance. However, the spec also further refines this tag is a set of >>> two independent integer values: single-octet network code and >>> two-octets error code. >>> For example, a value of 0x0300ff (in hex) is a perfectly valid value >>> for this tag, representing an error with code 0xff in a GSM network. >>> I'm not 100% sure bearerbox wouldn't choke on reading such a value >>> (since the supposed string is prematurely terminated), but what I am >>> sure is that one can't write a value such as 0x0300ff into this tag if >>> it's represented as a C-string. So, to able to fully use this TLV in >>> say, smppbox, this TLV has to be represented as a 3-octets integer >>> value. That renders this tag unusable for the err: field in SMPP >>> delivery receipts but it was never intended to be used as such despite >>> bearing a similar name. >>> >>> So I'm attaching a patch that changes representation of the >>> network_error_code TLV to a 3-octets integer and removes its usage for >>> in handle_dlr. >>> >>> -- >>> Best regards, >>> Victor Luchitz >>> <network_error_code.patch> >> >> > > > > -- > Best regards, > Victor Luchitz > > > > -- > Best regards, > Victor Luchitz > > > > -- Best regards, Victor Luchitz
