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.
Sorry but I fail to see how my patch makes the code "unnecessary complex". I couldn't quite grasp the meaning of your last sentence, care to provide examples? > > 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
