Add String digits support for GenericDigits

[gfigiel]

Implement TODOs: https://github.com/RestComm/jss7/blob/c6891a3ffd750ac55a11a0c71d4d3c862403a940/isup/isup-impl/src/main/java/org/mobicents/protocols/ss7/isup/impl/message/parameter/GenericDigitsImpl.java#L68-L70 and https://github.com/RestComm/jss7/blob/c6891a3ffd750ac55a11a0c71d4d3c862403a940/isup/isup-api/src/main/java/org/mobicents/protocols/ss7/isup/message/parameter/GenericDigits.java#L86-L87

[gfigiel]

Pull request created: https://github.com/RestComm/jss7/pull/59. The change has been tested only using prepared unit tests.

[vetss]

Hello gfigiel,

I have checked your update, thanks for it. RestComm Jss7 stack has already implemented code for BCD. See https://github.com/RestComm/jss7/blob/master/isup/isup-impl/src/main/java/org/mobicents/protocols/ss7/isup/impl/message/parameter/AbstractNumber.java methods: public int decodeDigits(ByteArrayInputStream bis, int octetsCount) public int encodeDigits(ByteArrayOutputStream bos)

(Althow the method notations is different - AbstractNumber keeps data in String form, GenericDigits keeps data in the byte[] form). Also GenericDigits is marked as for a national use, may be that is why we keep data in a byte array form.

Which digits do you carry in your sidei GenericDigits ? Are they only '0' - '9' digits or it may be *, @, a, b, c, something other characters ?

AbstractNumber current implementation uses encoding as a hexadecimal digits (0-9, a-f) As for https://en.wikipedia.org/wiki/Binary-coded_decimal BCD uses 0-9 digits only. TBCD uses 0-9,,#,a,b,c (but ISUP spec insists in BCD and says that values 10-15 are "spare", say are not used) In your update you use 0-9, (as 11) and # (as 12).

I am thinking, does ISUP use 10-15 codes at all (may be we need to code only 0-9 digits) ?

[vetss]

ok, I have found your comment for CAP primitives.

Here is an extract from CAP spec: -- - CorrelationID in EstablishTemporaryConnection -- - number in VariablePart -- - digitsResponse in ReceivedInformationArg -- - midCallEvents in oMidCallSpecificInfo and tMidCallSpecificInfo -- -- In the digitsResponse and midCallevents, the digits may also include the '', '#', -- a, b, c and d digits by using the IA5 character encoding scheme. If the BCD even or -- BCD odd encoding scheme is used, then the following encoding shall be applied for the -- non-decimal characters: 1011 (), 1100 (#). -- -- AssistingSSPIPRoutingAddress in EstablishTemporaryConnection and CorrelationID in -- AssistRequestInstructions may contain a Hex B digit as address signal. Refer to -- Annex A.6 for the usage of the Hex B digit. -- -- Note that when CorrelationID is transported in Generic Digits, then the digits shall -- always be BCD encoded.

Please confirm that you need this functionality only for usage for CAP stack. If I am right - then it is better to implement encoder / decoder at CAP stack level. GenericDigits from ISUP point of view is something that is "national encoded". And CAP provides some exact algo for implementing of it (including IA5 encoding - this is first 128 characters of ASCII).

CAP: org.mobicents.protocols.ss7.isup.impl.message.parameter.Digits : String Digits.getGenericDigitsDecoded(); int Digits.getGenericDigitsTypeOfDigits(); String Digits.setGenericDigitsDecoded(int encodingScheme, int typeOfDigits, String digits);

Is it what you need ?

[gfigiel]

You guess right Sergey :-) I need this encoding to handle AssistingSSPIPRoutingAddress in EstablishTemporaryConnection and CorrelationID in AssistRequestInstructions as in the specs you mentioned.

My intension was to make the implementation more generic and handle all Hex digits including special telco signes #, *, F depending on encoding scheme.

Any way I had some doubths if TBCD shall be used or plain BCD with neeble reverse order. Additionally I extended GenericDigits class according to: "Note that when CorrelationID is transported in Generic Digits, then the digits shall always be BCD encoded." and current CAP ETC operation API.

The only think I am confused about is special digits representation as there are differencies with coding special chars in (http://www.etsi.org/deliver/etsi_etr/001_099/060/02_60/etr_060e02p.pdf page 15):

TBCD-STRING ::= OCTET STRING (CONSTRAINED BY { -- two digits per octet, each digit encoded 0000 to 1001 (0 to 9), -- 1010 (), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used -- as filler when there is an odd number of digits. -- bits 8765 of octet n encoding digit 2n -- bits 4321 of octet n encoding digit 2(n-1) +1 -- } ) -- This type (Telephony Binary Coded Decimal String) is used to -- represent several digits from 0 through 9, , #, a, b , c, ..

and comment form specification you mentioned:

If the BCD even or -- BCD odd encoding scheme is used, then the following encoding shall be applied for the -- non-decimal characters: 1011 (*), 1100 (#).

Additionally the spcs does not mention TBCD encoding but just BCD - I just added nibbles reverse order based on examplary traces I had.

What do you think will be the best final implementation? Shall I extend ISUP related GenericDigits as CAPGenericDigits impl in CAP stack (changing also CAPParameterFactory API)? Then what encoding shall be used - I opt for TBCD but CAP spec compliant abcd#*f? I do not need AI5 ES so I will leave it unimplemented as for now.

Indeed I need the follwoing API: String Digits.getGenericDigitsDecoded(); int Digits.getGenericDigitsTypeOfDigits(); String Digits.setGenericDigitsDecoded(int encodingScheme, int typeOfDigits, String digits);

[vetss]

We decided to add this into ISUP (not CAP) level.

I added your commits and also my extra commit so code fits some Restcomm code style. If you need extra update fill free to provide a new pull request.

https://github.com/RestComm/jss7/commit/69dff56f3dcff91eced997ba652f3f944ea22dbc https://github.com/RestComm/jss7/commit/31eb7c9ab3ca7e3b6c27b38a5e806607694412bb https://github.com/RestComm/jss7/commit/564d4af41f56a4748f270335daec14b3748c8c74