Re: SMPP's network_error_code TLV

Hi Victor,

I don't know how I should make clearer for you (Type=OctetString Length=3).
This is from the latest SMPP spec v5.0:



Am 04.08.2010 um 21:36 schrieb Victor Luchitz:

> Please be so kind point me to a place in the SPEC that says that says
> that this TLV should be encoded and decoded in the way bearerbox does.
> 
> Seriously, intead of properly parsing a legitimate value of 0x0300ff
> for this tag, bearerbox simply drops it with message
> "SMPP: Optional field network_error_code with invalid length dropped."
> upon encountering the second octet, which is treated as a
> null-termination char. It's also impossible to write a value such as
> 0x0300ff from smppbox for the same reason, the tag is simply dropped.
> 
> I strongly encourage you to drop the "holier than thou" attitude
> regarding your reading of the SMPP spec.
> 
> 2010/8/4 Alexander Malysh <[email protected]>:
>> 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
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
>  Victor Luchitz
>