Btw, this is how Wireshark decodes the binary version of network_error_code TLV:
http://www.foopics.com/showfull/e58a2be383ae3c219822d4f3f9b97763 Note that the value of 0x03 and not '3' was detected as the GSM network code. I'm not saying that Wireshark's implementation of SMPP is the one everyone should religiously follow, but it's certainly not a piece of software I'd dismiss. In my opinion the presence of at least two software products (Wireshark and our client's ESME) that treat this TLV as two integers is an argument strong enough to reconsider your position on the matter. 2010/8/4 Alejandro Guerrieri <[email protected]>: > I agree with Alex also. > > Besides, the SMPP spec is far from perfect and has many ambiguities, being > this probably one of them. > > Apart from that, I don't see the point in making the code unnecessarily > complex for no reason. Having the value on dlr_err is way more useful than > this approach imho, and if you ever need to decode its values you can do it > at the application level. > > Regards, > -- > Alejandro Guerrieri > [email protected] > > > > On 04/08/2010, at 17:10, Rene Kluwen wrote: > >> That's clear. So what does Integer mean here? Network byte order? Or the >> other way around. >> In case the field is defined as C-string, then I presume printable ascii >> character. But maybe I am wrong here. >> This because, reading the specs they mean the first "Integer" is one octet >> and the second "Integer" two octets. >> >> But still (also according to your own reasoning) I think Alex is right. >> >> == Rene >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Victor Luchitz >> Sent: Wednesday, 04 August, 2010 17:00 >> To: Kannel Devel >> Subject: Re: Re: SMPP's network_error_code TLV >> >> 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 >> >> >> >> > > -- Best regards, Victor Luchitz
