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
