Hi, you can pack every integer in one octet as long as integer not greater 256. And I saw very much SMSCs that make use of this TLV and they use it as described in SMPP spec and me.
Thanks, Alexander Malysh Am 04.08.2010 um 19:28 schrieb Rene Kluwen: > Sorry, forgot to copy the list. > > -----Original Message----- > From: Rene Kluwen [mailto:[email protected]] > Sent: Wednesday, 04 August, 2010 19:25 > To: '[email protected]' > Subject: RE: SMPP's network_error_code TLV > > I am looking at the foopics link now. > > They have error type as 1 octet and Error code as 2 octets. > > Doesn't that prove Alex is right? > > I mean if it was the other way around, you would get: > > Error type: 0x0300 > Error code: 0xff > > == Rene > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, 04 August, 2010 19:13 > To: Rene Kluwen > Subject: Re: SMPP's network_error_code TLV > > I'm not going to give up on this easily :) > > http://www.foopics.com/showfull/e58a2be383ae3c219822d4f3f9b97763 > > Considering how Wireshark parses this TLV, SMPP spec's definition of > "Integer" - "An unsigned value with the defined number of octets. The > octets will always be transmitted MSB first (Big Endian)" and > considering the fact that passing integer values as printable characters > is such a waste of precious bits that no one would need such a TLV, I > still hold my opinion as valid :) > > On 04.08.2010 19: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 > > > >
