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
