Implementing CAP phase 3 operations for SMS

[GoogleCodeExporter]

We need to implement operations phase 3 for SMS:
- initialDPSMS
- connectSMS
- releaseSMS
- requestReportSMSEvent
- eventReportSMS
- resetTimerSMS
- furnishChargingInformationSMS
- continueSMS

Original issue reported on code.google.com by serg.vet...@gmail.com on 24 Oct 2012 at 4:20

[GoogleCodeExporter]

Original comment by amit.bha...@gmail.com on 16 Apr 2013 at 2:44

• Added labels: Version-2.1.0.BETA2
• Removed labels: Version-2.1.0.BETA1

[GoogleCodeExporter]

Hi ,

Please review the attached patch.

Thank you.

Original comment by reachlas...@gmail.com on 24 May 2013 at 11:06

• Changed state: Started

Attachments:

• capv3_SMS_1.patch

[GoogleCodeExporter]

Hello!

I think we can test 3 scenarios for CAP operations for SMS:

1)
-> initialDPSMSRequest
<- resetTimerSMS
<- requestReportSMSEventRequest
-> eventReportSMSRequest
<- furnishChargingInformationSMS
<- connectSMS   

2)
-> initialDPSMSRequest
<- continueSMS  

3)
-> initialDPSMSRequest
<- releaseSMS   

Original comment by serg.vet...@gmail.com on 27 May 2013 at 1:53

[GoogleCodeExporter]

Hi,
Please review the attached patch.

Thank you.

Original comment by reachlas...@gmail.com on 9 Jun 2013 at 2:04

Attachments:

• cap_sms_2.patch

[GoogleCodeExporter]

Hello!

1. continueSMS operation is not implemented. We need to add it into api too.

2. We need to add toString() methods in ALL implemented primitives (even for 
example in empty primitive like OSmsSubmissionSpecificInfoImpl)

3. OSmsFailureSpecificInfoImpl, OSmsSubmissionSpecificInfoImpl, 
TSmsFailureSpecificInfoImpl, TSmsDeliverySpecificInfoImpl, 
FCIBCCCAMELsequence1Impl:
we do not need getTag() and getTagClass() here, instead we need to use such 
tags definition in EventSpecificInformationSMSImpl 
(EventSpecificInformationSMSImpl is well implemented)

4. FurnishChargingInformationSMSRequestImpl: _ID_eventTypeSMS and 
_ID_eventSpecificInformationSMS are not needed

5. FurnishChargingInformationSMSRequestTest:
getData() must be: 4, 15, -96, 13, -128, 8, 48, 6, -128, 1, 3, -118, 1, 1, 
-127, 1, 1
So there must not be eztra "Sequense" - this part - 48, 15
This is a bug from FurnishChargingInformationSMSRequestImpl

6. SMSAddressString needs extra implementing when alphanumeric character string 
cause. Here ias specification:
SMS-AddressString ::= AddressString (SIZE (1 .. maxSMS-AddressStringLength))
-- This data type is used to transport CallingPartyNumber for MT-SMS.
-- If this data type is used for MO-SMS, then the maximum number of digits 
shall be 16.
-- An SMS-AddressString may contain an alphanumeric character string. In this
-- case, a nature of address indicator '101'B is used, in accordance with
-- 3GPP TS 23.040 [6]. The address is coded in accordance with the GSM 7-bit
-- default alphabet definition and the SMS packing rules as specified in
-- 3GPP TS 23.038 [15] in this case.

So if AddressString.getAddressNature()==AddressNature.reserved (=='101'B) we 
have to make another implementation of encoding / decoding.
We have to override AddressString._decode() and encodeData(). For 
"AddressNature!=reserved" we will invoke corresponded super.*() methods and
for reserved - implement our code.
We have already implemented such encoding in 
org.mobicents.protocols.ss7.map.smstpdu.AddressFieldImpl (map stack) - look 
please there for details

7. SMSEventImpl._ID_monitorMode 10 -> 1

8. TPValidityPeriodImpl: we have to implement an extra funtionality here:
- extra getter: org.mobicents.protocols.ss7.map.api.smstpdu.ValidityPeriod 
getValidityPeriod();
- extra constructor with a parameter "ValidityPeriod"
New methods must contain encoding/decoding functionality. 
org.mobicents.protocols.ss7.map.smstpdu.SmsSubmitTpduImpl contains decoding (in 
SmsSubmitTpduImpl(byte[] data, Charset gsm8Charset))
and encoding (in encodeData()) templates 

9. ConnectSMSRequestImpl.getMessageType() reeturns wrong value

10. EventReportSMSRequestImpl: eventTypeSMS paramater is mandatory - add 
checking for it

11.ResetTimerSMSRequestImpl: getMessageType() and getOperationCode() return 
wrong value

12. For SMS part we need to support CapV3_cap3_sms and CapV4_cap4_sms for 
incoming and outgoing parts

13. CAPServiceImpl.connectSMSRequest() - doule lines:
                ((CAPServiceSmsListener) serLis).onConnectSMSRequest(ind);
                ((CAPServiceSmsListener) serLis).onConnectSMSRequest(ind);

14. CAPServiceImpl.resetTimerSMSRequest() getTag() != Tag.STRING_OCTET -> 
SEQUESNCE

I will commit your update becaus ewe need this implementation is a short time

Original comment by serg.vet...@gmail.com on 12 Jun 2013 at 11:50

[GoogleCodeExporter]

Hello!

These are firest commites (not all is done):

https://code.google.com/p/jss7/source/detail?r=085ed85a2c9a81f8c75a41d0df8ca2f24
99283b3
https://code.google.com/p/jss7/source/detail?r=5e509130ce3c026ba1b40c9040842242d
fbc0ddd

Original comment by serg.vet...@gmail.com on 18 Jun 2013 at 8:24

[GoogleCodeExporter]

Hello

jss7 update:
https://code.google.com/p/jss7/source/detail?r=88186e327834b42e63f35f50f8ecd302c
ff32615
CAP RA update:
https://code.google.com/p/jain-slee/source/detail?r=226e539ae4c11754bb13c65a37d1
9ffc6c8acb96&repo=ss7

Original comment by serg.vet...@gmail.com on 19 Jun 2013 at 8:54

[GoogleCodeExporter]

Now this issues are still unfixed:

6. SMSAddressString needs extra implementing when alphanumeric character string 
cause. Here ias specification:
SMS-AddressString ::= AddressString (SIZE (1 .. maxSMS-AddressStringLength))
-- This data type is used to transport CallingPartyNumber for MT-SMS.
-- If this data type is used for MO-SMS, then the maximum number of digits 
shall be 16.
-- An SMS-AddressString may contain an alphanumeric character string. In this
-- case, a nature of address indicator '101'B is used, in accordance with
-- 3GPP TS 23.040 [6]. The address is coded in accordance with the GSM 7-bit
-- default alphabet definition and the SMS packing rules as specified in
-- 3GPP TS 23.038 [15] in this case.

So if AddressString.getAddressNature()==AddressNature.reserved (=='101'B) we 
have to make another implementation of encoding / decoding.
We have to override AddressString._decode() and encodeData(). For 
"AddressNature!=reserved" we will invoke corresponded super.*() methods and
for reserved - implement our code.
We have already implemented such encoding in 
org.mobicents.protocols.ss7.map.smstpdu.AddressFieldImpl (map stack) - look 
please there for details

8. TPValidityPeriodImpl: we have to implement an extra funtionality here:
- extra getter: org.mobicents.protocols.ss7.map.api.smstpdu.ValidityPeriod 
getValidityPeriod();
- extra constructor with a parameter "ValidityPeriod"
New methods must contain encoding/decoding functionality. 
org.mobicents.protocols.ss7.map.smstpdu.SmsSubmitTpduImpl contains decoding (in 
SmsSubmitTpduImpl(byte[] data, Charset gsm8Charset))
and encoding (in encodeData()) templates 

Original comment by serg.vet...@gmail.com on 21 Jun 2013 at 9:57

[GoogleCodeExporter]

Hello!

The final update:
https://code.google.com/p/jss7/source/detail?r=c0d662e87c5348187fe14767ab75f36d8
f4495d9

Original comment by serg.vet...@gmail.com on 23 Jun 2013 at 8:36