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 > > > >
