search

Aditi16 / jss7

Automatically exported from code.google.com/p/jss7
0 stars 0 forks source link

Implement insertSubscriberData MAP message #152

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Implement insertSubscriberData MAP message (Application Context Name : 
subscriberDataMngtContext, networkLocUpContext and gprsLocationUpdateContext) 
from Mobility - Subscriber management service

Original issue reported on code.google.com by serg.vet...@gmail.com on 22 Oct 2012 at 5:59

GoogleCodeExporter commented 9 years ago 
Issue 82 has been merged into this issue.

Original comment by amit.bha...@gmail.com on 9 Nov 2012 at 10:55

GoogleCodeExporter commented 9 years ago

Original comment by amit.bha...@gmail.com on 9 Nov 2012 at 11:25

GoogleCodeExporter commented 9 years ago 
A list of implemented but not tested primitives (unit tests are needed and may 
be testing with live tests)
- mobility.subscriberManagement.CUGFeatureImpl
- mobility.subscriberManagement.CUGInfoImpl
- mobility.subscriberManagement.CUGSubscriptionImpl
- mobility.subscriberManagement.ExtCallBarInfoImpl
- mobility.subscriberManagement.ExtCallBarringFeatureImpl
- mobility.subscriberManagement.ExtForwFeatureImpl
- mobility.subscriberManagement.ExtForwInfoImpl
- mobility.subscriberManagement.ExtForwOptionsImpl
- mobility.subscriberManagement.ExtSSDataImpl
- mobility.subscriberManagement.ExtSSInfoImpl
- mobility.subscriberManagement.ExtSSStatusImpl
- mobility.subscriberManagement.GPRSSubscriptionData
- mobility.subscriberManagement.EMLPPInfoImpl
- supplementary.SSSubscriptionOptionImpl
- mobility.subscriberManagement.InterCUGRestrictions
- mobility.subscriberManagement.ZoneCodeImpl
- mobility.subscriberManagement.AgeIndicatorImpl
- mobility.subscriberManagement.CSAllocationRetentionPriorityImpl

A list of primitives that internal structure needs to be implemented:
- primitives.ISDNSubaddressStringImpl

A list of unimplemented primitives
- primitives.NAEAPreferredCIImpl
- mobility.subscriberManagement.ODBDataImpl
- mobility.subscriberManagement.VoiceBroadcastDataImpl
- mobility.subscriberManagement.VoiceGroupCallDataImpl
- mobility.subscriberManagement.VlrCamelSubscriptionInfoImpl
- mobility.subscriberManagement.LSAInformationImpl
- mobility.subscriberManagement.LCSInformationImpl
- mobility.subscriberManagement.MCSSInfoImpl
- mobility.subscriberManagement.SGSNCAMELSubscriptionInfoImpl
- mobility.subscriberManagement.AccessRestrictionDataImpl
- mobility.subscriberManagement.EPSSubscriptionDataImpl
- mobility.subscriberManagement.CSGSubscriptionDataImpl
- mobility.subscriberManagement.ODBGeneralDataImpl
- mobility.subscriberManagement.SupportedFeaturesImpl

Original comment by serg.vet...@gmail.com on 19 Nov 2012 at 1:01

GoogleCodeExporter commented 9 years ago 
I have implemented following test classes. Please review them and give me your 
comments so that I can work on others by considering comments as well.
- mobility.subscriberManagement.CUGFeatureImpl
- mobility.subscriberManagement.CUGInfoImpl
- mobility.subscriberManagement.CUGSubscriptionImpl
- mobility.subscriberManagement.ExtCallBarInfoImpl
- mobility.subscriberManagement.ExtCallBarringFeatureImpl
- mobility.subscriberManagement.ExtForwFeatureImpl
- mobility.subscriberManagement.ExtForwInfoImpl
- mobility.subscriberManagement.ExtForwOptionsImpl
- mobility.subscriberManagement.ExtSSDataImpl
- mobility.subscriberManagement.ExtSSInfoImpl
- mobility.subscriberManagement.ExtSSStatusImpl
- mobility.subscriberManagement.GPRSSubscriptionData
- mobility.subscriberManagement.EMLPPInfoImpl

I have done small corrections to following files as well.

PDPContextImpl.java
CUGFeatureImpl.java
EMLPPInfoImpl.java
ExtCallBarringFeatureImpl.java
ExtForwInfoImpl.java
ExtSSDataImpl.java
ExtSSInfoImpl.java

Original comment by reachlas...@gmail.com on 24 Nov 2012 at 6:34

Attachments:

GoogleCodeExporter commented 9 years ago 
Hello!

Sorry for delay.
I have checked your update and committed it into a master branch.
Good work.

I have some remarks and also a have made some update to your code to fit our 
coding style. My reemarks are below.

1. PDPContextDataImpl: 
if (this.pdpType == null) {
            System.out.println(" this.pdpType " + this.pdpType  );
            throw new MAPParsingComponentException("Error while decoding " + _PrimitiveName + ": A mandatory parameter pdpType has not found",
                    MAPParsingComponentExceptionReason.MistypedParameter);
}
Why do we need "System.out.println()"? I removed this

2. Tests: lets use MAPExtensionContainerTest.CheckTestExtensionContainer() and 
GetTestExtensionContainer() for testing MAPExtensionContainer parameters.
This lets us to reuse a code. You use:
assertNotNull(extensionContainer);
MAPExtensionContainer extensionContainer = getMapExtensionContainer();      
It is better to test:
assertTrue(MAPExtensionContainerTest.CheckTestExtensionContainer(extensionContai
ner));
MAPExtensionContainer extensionContainer = 
MAPExtensionContainerTest.GetTestExtensionContainer();

3. Tests: if primitives a rather simple let's use a more clear way of them 
creation / testing. For example the following looks more clear:
assertEquals((int) prim.getPreferentialCugIndicator(), 1);
assertEquals(prim.getInterCugRestrictions().getInterCUGRestrictionsValue(), 
InterCUGRestrictionsValue.CUGOnlyFacilities);
InterCUGRestrictions interCugRestrictions = new 
InterCUGRestrictionsImpl(InterCUGRestrictionsValue.CUGOnlyFacilities);
IntraCUGOptions intraCugOptions = IntraCUGOptions.noCUGRestrictions;

than:
assertTrue(prim.getPreferentialCugIndicator().equals(new Integer(1)));
assertTrue(prim.getInterCugRestrictions().getInterCUGRestrictionsValue().equals(
InterCUGRestrictionsValue.CUGOnlyFacilities));
InterCUGRestrictions interCugRestrictions = new InterCUGRestrictionsImpl(0);
IntraCUGOptions intraCugOptions = IntraCUGOptions.getInstance(0);

I have updated CUGFeatureTest, please look at my update

4. Do you have any live trace data for ISDNSubaddressString. We need to 
implement an internal structure of this primitive.

Original comment by serg.vet...@gmail.com on 2 Dec 2012 at 5:38

GoogleCodeExporter commented 9 years ago 
Here is an updated list of primitives for this MAP operation:

A list of implemented primitives:
- mobility.subscriberManagement.CUGFeature
- mobility.subscriberManagement.CUGInfo
- mobility.subscriberManagement.CUGSubscription
- mobility.subscriberManagement.EMLPPInfo
- mobility.subscriberManagement.ExtCallBarInfo
- mobility.subscriberManagement.ExtCallBarringFeature
- mobility.subscriberManagement.ExtForwFeature
- mobility.subscriberManagement.ExtForwInfoImpl
- mobility.subscriberManagement.ExtForwOptionsImpl
- mobility.subscriberManagement.ExtSSDataImpl
- mobility.subscriberManagement.ExtSSInfoImpl
- mobility.subscriberManagement.ExtSSStatusImpl

A list of implemented but not tested primitives (unit tests are needed and may 
be testing with live tests)
- mobility.subscriberManagement.GPRSSubscriptionData
- supplementary.SSSubscriptionOptionImpl
- mobility.subscriberManagement.InterCUGRestrictions
- mobility.subscriberManagement.ZoneCodeImpl
- mobility.subscriberManagement.AgeIndicatorImpl
- mobility.subscriberManagement.CSAllocationRetentionPriorityImpl

A list of primitives that internal structure needs to be implemented:
- primitives.ISDNSubaddressStringImpl

A list of unimplemented primitives
- mobility.locationManagement.SupportedFeatures 
- mobility.subscriberManagement.AccessRestrictionData   
- mobility.subscriberManagement.AdditionalInfo  
- mobility.subscriberManagement.AdditionalSubscriptions 
- mobility.subscriberManagement.AllocationRetentionPriority 
- mobility.subscriberManagement.AMBR    
- mobility.subscriberManagement.AMBR    
- mobility.subscriberManagement.APNConfiguration    
- mobility.subscriberManagement.APNConfigurationProfile 
- mobility.subscriberManagement.APNOIReplacement    
- mobility.subscriberManagement.CauseValue  
- mobility.subscriberManagement.ChargingCharacteristics 
- mobility.subscriberManagement.CSGSubscriptionData 
- mobility.subscriberManagement.DCSI    
- mobility.subscriberManagement.DestinationNumberCriteria   
- mobility.subscriberManagement.DPAnalysedInfoCriterium 
- mobility.subscriberManagement.EPSQoSSubscribed    
- mobility.subscriberManagement.EPSSubscriptionData 
- mobility.subscriberManagement.ExternalClient  
- mobility.subscriberManagement.FQDN    
- mobility.subscriberManagement.GPRSCamelTDPData    
- mobility.subscriberManagement.GPRSCSI 
- mobility.subscriberManagement.GroupId 
- mobility.subscriberManagement.LCSInformation  
- mobility.subscriberManagement.LCSPrivacyClass 
- mobility.subscriberManagement.LongGroupId 
- mobility.subscriberManagement.LSAAttributes   
- mobility.subscriberManagement.LSAData 
- mobility.subscriberManagement.LSAIdentity 
- mobility.subscriberManagement.LSAInformation  
- mobility.subscriberManagement.MCSI    
- mobility.subscriberManagement.MCSSInfo    
- mobility.subscriberManagement.MGCSI   
- mobility.subscriberManagement.MMCode  
- mobility.subscriberManagement.MOLRClass   
- mobility.subscriberManagement.MTsmsCAMELTDPCriteria   
- mobility.subscriberManagement.OBcsmCamelTdpCriteria   
- mobility.subscriberManagement.ODBData 
- mobility.subscriberManagement.ODBGeneralData  
- mobility.subscriberManagement.ODBHPLMNData    
- mobility.subscriberManagement.PDNGWIdentity   
- mobility.subscriberManagement.PDNType 
- mobility.subscriberManagement.PDPAddress  
- mobility.subscriberManagement.QoSClassIdentifier  
- mobility.subscriberManagement.ServiceType 
- mobility.subscriberManagement.SGSNCAMELSubscriptionInfo   
- mobility.subscriberManagement.SMSCAMELTDPData 
- mobility.subscriberManagement.SMSCSI  
- mobility.subscriberManagement.SpecificAPNInfo 
- mobility.subscriberManagement.SSCamelData 
- mobility.subscriberManagement.SSCSI   
- mobility.subscriberManagement.TBcsmCamelTdpCriteria   
- mobility.subscriberManagement.Time    
- mobility.subscriberManagement.VlrCamelSubscriptionInfo    
- mobility.subscriberManagement.VoiceBroadcastData  
- mobility.subscriberManagement.VoiceGroupCallData  
- primitives.NAEACIC    
- primitives.NAEAPreferredCI

Original comment by serg.vet...@gmail.com on 2 Dec 2012 at 7:21

GoogleCodeExporter commented 9 years ago 
Thank you for the review and comments. I have incorporated those suggestions 
and comments to my developments. 

Please review the attached patch file.

Please check following files as I have done some changes to existing 
implementations.
MMCodeValue.java
TeleserviceCodeValue.java
VLRCamelSubscriptionInfo.java

In this patch file, i have included following primities.
AdditionalInfoImpl
AdditionalSubscriptionsImpl
CauseValueImpl
DCSIImpl
DestinationNumberCriteriaImpl
DPAnalysedInfoCriteriumImpl
GroupIdImpl
LongGroupIdImpl
MCSIImpl
MMCodeImpl
MTsmsCAMELTDPCriteriaImpl
OBcsmCamelTdpCriteriaImpl
ODBDataImpl
ODBGeneralDataImpl
ODBHPLMNDataImpl
SMSCAMELTDPDataImpl
SMSCSIImpl
SSCamelDataImpl
SSCSIImpl
TBcsmCamelTdpCriteriaImpl
VlrCamelSubscriptionInfoImpl
VoiceBroadcastDataImpl
VoiceGroupCallDataImpl

And following Test Classes.
AgeIndicatorTest
CSAllocationRetentionPriorityTest
DCSITest
DestinationNumberCriteriaTest
DPAnalysedInfoCriteriumTest
GPRSSubscriptionDataTest
InterCUGRestrictionsTest
MCSITest
MTsmsCAMELTDPCriteriaTest
OBcsmCamelTdpCriteriaTest
ODBDataTest
SMSCAMELTDPDataTest
SMSCSITest
SSCamelDataTest
SSCSITest
SSSubscriptionOptionTest
TBcsmCamelTdpCriteriaTest
VlrCamelSubscriptionInfoTest
VoiceBroadcastDataTest
VoiceGroupCallDataTest
ZoneCodeTest

Original comment by reachlas...@gmail.com on 5 Dec 2012 at 5:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Hello!

I have several remarks for your update:

1. MCSI:
we should use
public long getServiceKey();
instead of 
public Long getServiceKey();
because ServiceKey parameter is mandatory and can not be null

2. MMCodeValue:
You have updated values so for example 
RouteingAreaUpdateToOtherSGSNUpdateFromNewSGSN was 128+1==129 and it is now 
-128+1==127. 
May be it is better to keep old values (to be all positives) and when decoding 
in MMCodeImpl.getMMCodeValue() use something like 
return MMCodeValue.getInstance(data | 0xFF)
to garantee a positive value?
It is not a bug, but from my point of view code will look better.

3. A very important issue:
we can test like this
assertEquals(a, b);
when a and b are digits (like int, Integer, long, Long and so on) and enums.
We can not use this for Strings, arrays or complex classes.
So this:
assertEquals(forwardedToNumber.getAddress(),"22228"); (from ExtSSInfoTest)
only if Strings (arrays, objects) are the same instantces. If Strings a and b 
are two different instances with the same context (string) the result will be 
false.
So we should use:
int a, b;
assertEquals(a, b);
enum a, b;
assertEquals(a, b);
String a, b;
assertTrue(a.equals(b));
byte[] a,b;
assertTrue(Arrays.equals(a, b));

Can you please revise all tests and fix this?

to be continued

Original comment by serg.vet...@gmail.com on 5 Dec 2012 at 4:11

GoogleCodeExporter commented 9 years ago 

0. That is not may be a bug and we not not now update it totally but:
let's in future the code like (for enums !!!)
assertEquals(one.getData(),SupplementaryCodeValue.allFacsimileTransmissionServic
es.getCode());
replase with
assertEquals(one.getSupplementaryCodeValue(),SupplementaryCodeValue.allFacsimile
TransmissionServices);
This test is far more correct.

1. AdditionalSubscriptions - needs unittest and toString()
2. CauseValue - may be we can expose Cause values (look at Q.850) + unittest 
and toString() (but I am not sure)
3. DestinationNumberCriteria: look at it's definition:
    -- one or both of destinationNumberList and destinationNumberLengthList 
    -- shall be present
may be we add some checks for this?
4. GroupId and Long-GroupId:
    -- When Group-Id is less than six characters in length, the TBCD filler (1111)
    -- is used to fill unused half octets.
    -- Refers to the Group Identification as specified in 3GPP TS 23.003 
    -- and 3GPP TS 43.068/ 43.069
Let's implement unittests for case when "Group-Id is less than six characters 
in length". There may be some extra code needed to work with this case (may be 
adding chars in a constructor and removing fillers in a getter).
and: "super(1, 3, "GroupId");" - can GroupId have a length!=3/4 ?
5. OBcsmCamelTdpCriteria, TBcsmCamelTdpCriteria: when we decoding a choice 
(basicServiceCriteria in this case) we need not check tag/tagClass/isPrimitive, 
here:
if (!(tag2 == ExtBasicServiceCodeImpl._ID_ext_BearerService || tag2 == 
ExtBasicServiceCodeImpl._ID_ext_Teleservice)
|| ais2.getTagClass() != Tag.CLASS_CONTEXT_SPECIFIC || !ais2.isTagPrimitive())
throw new MAPParsingComponentException("Error while decoding " + _PrimitiveName
+ ".: extBasicServiceCode bad tag or tagClass or is not primitive ", 
MAPParsingComponentExceptionReason.MistypedParameter);
There are two reasons:
- this should be checked in a choice itself
- imagine yourself that in next specification version a qhuantity of choices 
will increase so we will have to search for all places in code when the choise 
are decoded and update a code.
This is not a bug.
6. ODBGeneralData - we need a couple of unittests here - the primitive is too 
complicated
I also guess that we need
super(15, 32, 28, "ODBGeneralData"); -> super(15, 32, 29, "ODBGeneralData");
because the last index is 28 and if we calculate with 0 we will have 29 bits 
(not 28)
7. ODBHPLMNData - may be a unittest too?
8. SMSCAMELTDPData - here and may be somethere else. serviceKey parameter is 
mandatory but it can not be null. The question is - how to check if it is 
present in a primitive when decoding. Some flag can be used. But the sompliest 
way is: serviceKey can not be negative, so before decoding we can set 
"serviceKey=-1;" and after decoding w can check "if(serviceKey==-1) { 
Exception(...) }". Please fix it.
And: in "toString()" let's add "sb.append("serviceKey==");"

to be continued ...

Original comment by serg.vet...@gmail.com on 5 Dec 2012 at 6:57

GoogleCodeExporter commented 9 years ago 
1. GPRSSubscriptionData - unittest does not looks good for me:
- assertEquals(apnOiReplacement.getData(), this.getAPNOIReplacementData()); - 
this can not be used for arrays
2. InterCUGRestrictionsTest - use the constructor 
"InterCUGRestrictionsImpl(InterCUGRestrictionsValue val)" and a getter 
"InterCUGRestrictionsValue getInterCUGRestrictionsValue()" for testing

Other primitives look good for me.

Thanks for a good work.

To go forward, please:
1. commit himself THIS patch WITHOUT CHANGES into a jss7 master branch
2. make updates for about which I said in my remarks 
3. public your next patch for revising

Feel free for asking questions if you have some doubts

Original comment by serg.vet...@gmail.com on 6 Dec 2012 at 6:00

GoogleCodeExporter commented 9 years ago 
Hi 
Please review the attached patch file. 

I haven't included fixes for causeValue and GroupId issues as I have some 
questions for you.

Original comment by reachlas...@gmail.com on 17 Dec 2012 at 6:11

Attachments:

GoogleCodeExporter commented 9 years ago 
In the above patch file I have included following implementation classes and 
relevant Test classes.

- mobility.locationManagement.SupportedFeatures 
- mobility.subscriberManagement.AccessRestrictionData   
- mobility.subscriberManagement.AllocationRetentionPriority     
- mobility.subscriberManagement.AMBR    
- mobility.subscriberManagement.APNConfiguration        
- mobility.subscriberManagement.APNConfigurationProfile 
- mobility.subscriberManagement.CSGSubscriptionData     
- mobility.subscriberManagement.EPSQoSSubscribed        
- mobility.subscriberManagement.EPSSubscriptionData     
- mobility.subscriberManagement.ExternalClient  
- mobility.subscriberManagement.FQDN    
- mobility.subscriberManagement.GPRSCamelTDPData        
- mobility.subscriberManagement.GPRSCSI 
- mobility.subscriberManagement.LCSInformation  
- mobility.subscriberManagement.LCSPrivacyClass 
- mobility.subscriberManagement.LSAAttributes   
- mobility.subscriberManagement.LSAData 
- mobility.subscriberManagement.LSAInformation  
- mobility.subscriberManagement.MCSI    
- mobility.subscriberManagement.MCSSInfo        
- mobility.subscriberManagement.MGCSI   
- mobility.subscriberManagement.MMCode  
- mobility.subscriberManagement.MOLRClass       
- mobility.subscriberManagement.MTsmsCAMELTDPCriteria   
- mobility.subscriberManagement.OBcsmCamelTdpCriteria   
- mobility.subscriberManagement.ODBData 
- mobility.subscriberManagement.ODBGeneralData  
- mobility.subscriberManagement.ODBHPLMNData    
- mobility.subscriberManagement.PDNGWIdentity   
- mobility.subscriberManagement.PDNType 
- mobility.subscriberManagement.QoSClassIdentifier      
- mobility.subscriberManagement.ServiceType     
- mobility.subscriberManagement.SGSNCAMELSubscriptionInfo       
- mobility.subscriberManagement.SMSCAMELTDPData 
- mobility.subscriberManagement.SMSCSI  
- mobility.subscriberManagement.SpecificAPNInfo 
- mobility.subscriberManagement.SSCamelData     
- mobility.subscriberManagement.SSCSI   
- mobility.subscriberManagement.TBcsmCamelTdpCriteria   
- mobility.subscriberManagement.Time    
- mobility.subscriberManagement.VlrCamelSubscriptionInfo        
- mobility.subscriberManagement.VoiceBroadcastData      
- mobility.subscriberManagement.VoiceGroupCallData

Original comment by reachlas...@gmail.com on 17 Dec 2012 at 6:15

GoogleCodeExporter commented 9 years ago 
1. PDNTypeValue
Please use a header like " * TeleStax, Open Source Cloud Communications  
Copyright 2012." at the top of a file

2. SMSCAMELTDPDataImpl and may be soemelse:
toString(): missed something like:
sb.append("serviceKey=");

3. TimeImpl:
from RFC 3588
Time
      The Time format is derived from the OctetString AVP Base Format.
      The string MUST contain four octets, in the same format as the
      first four bytes are in the NTP timestamp format.  The NTP
      Timestamp format is defined in chapter 3 of [SNTP].

      This represents the number of seconds since 0h on 1 January 1900
      with respect to the Coordinated Universal Time (UTC).

      On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
      SNTP [SNTP] describes a procedure to extend the time to 2104.
      This procedure MUST be supported by all DIAMETER nodes.
And you can look at rfc2030 for "NTP Timestamp Format"
I think we need to implement an internal structure + unittest

4. AllocationRetentionPriority:
- Bad implementation for:
    pre-emption-capability  [1] BOOLEAN OPTIONAL,
    pre-emption-vulnerability   [2] BOOLEAN OPTIONAL,
replace
  ais.readNull();
with
  this.preEmptionCapability = ais.readBoolean);
(and same for encoding)
- I am not sure that "priority-level must not be equal -1"
priority-level  [0] INTEGER
I am talking of:
        if (this.priorityLevel == -1) {
            throw new MAPParsingComponentException("Error while decoding " + _PrimitiveName + ": Parament priorityLevel is mandatory but does not found",
                    MAPParsingComponentExceptionReason.MistypedParameter);
        }
But I am not sure. If I am right we need some other kind of checking for 
example extra boolean flag like "priorityLevelIsRead".

5. APNConfigurationProfileImpl:
- _decode():
if (this.ePSDataList.size() < 1 || this.ePSDataList.size() > 10) -> if 
(this.ePSDataList.size() < 1 || this.ePSDataList.size() > 50)
- encodeData():
we need not "if(ePSDataList != null){" because this parametr is mandatory
- test: here and may be somethere else:
if we are testing a parameter like "completeDataListIncluded    NULL" (i.e. 
"NULL") lets test only "true" values for it because only this value force 
encoding "null" parameter into a stream (if "false" value we just skip writing 
"NULL" and nothing is tested)

to be continued...

Original comment by serg.vet...@gmail.com on 19 Dec 2012 at 6:59

GoogleCodeExporter commented 9 years ago 
6. EPSQoSSubscribedImpl: for such type sequences (when ALL parameters are 
context-specific even if some of them are mandatory) we can not to use "num" 
but just use "switch (tag)" for all parameters. Code will be less complicated. 
Moreover you do not use "num" for checking if all mandatory parameters are 
present. Your current implementatiopn is absolutely fine, you need not make any 
update. This is just for info for future.

7. LSAAttributes:
LSAAttributes content is described 3GPP TS 48.008:
Bits 1 to 4 of octet (x+1) define the priority of the LSA identification.
Bit 4321
0000 priority 1 = lowest priority
0001 priority 2 = second lowest priority
: : : :
1111 priority 16= highest priority
If the preferential access indicator (bit 5 of octet (x+1)) is set to 1 the 
subscriber has preferential access in the LSA. If
the active mode support indicator (bit 6 of octet (x+1)) is set to 1 the 
subscriber has active mode support in the LSA.

Coding of the i-th LSA identification with attributes:
8 7   6   5    4 3 2 1
spare act pref priority

9. LSAIdentity:
11 Identification of Localised Service Area
Cells may be grouped into specific localised service areas. Each localised 
service area is identified by a localised
service area identity (LSA ID). No restrictions are placed on what cells may be 
grouped into a given localised service
area.
The LSA ID can either be a PLMN significant number or a universal identity. 
This shall be known both in the networks
and in the SIM.
The LSA ID consists of 24 bits, numbered from 0 to 23, with bit 0 being the 
LSB. Bit 0 indicates whether the LSA is a
PLMN significant number or a universal LSA. If the bit is set to 0 the LSA is a 
PLMN significant number; if it is set to
1 it is a universal LSA.

I think the only one getter can be added for LSAIdentity: boolean 
isPlmnSignificantLSA() { return !(data[2] & 0x01); }
Do your agree?

10. LSAInformationImpl:
please replace into toString()
sb.append("completeDataListIncluded ");
with
sb.append("completeDataListIncluded, ");

to be continued...

Original comment by serg.vet...@gmail.com on 21 Dec 2012 at 11:33

GoogleCodeExporter commented 9 years ago 
All other primitives look good for me.
Please commit your update and then we will able fix bugs and finish what is not 
yet implemented.

Here is an updated list of primitive's state:

A list of implemented primitives:
- mobility.subscriberManagement.CUGFeature
- mobility.subscriberManagement.CUGInfo
- mobility.subscriberManagement.CUGSubscription
- mobility.subscriberManagement.EMLPPInfo
- mobility.subscriberManagement.ExtCallBarInfo
- mobility.subscriberManagement.ExtCallBarringFeature
- mobility.subscriberManagement.ExtForwFeature
- mobility.subscriberManagement.ExtForwInfoImpl
- mobility.subscriberManagement.ExtForwOptionsImpl
- mobility.subscriberManagement.ExtSSDataImpl
- mobility.subscriberManagement.ExtSSInfoImpl
- mobility.subscriberManagement.ExtSSStatusImpl
- mobility.subscriberManagement.GPRSSubscriptionData
- supplementary.SSSubscriptionOption
- mobility.subscriberManagement.InterCUGRestrictions
- mobility.subscriberManagement.ZoneCode
- mobility.subscriberManagement.AgeIndicator
- mobility.subscriberManagement.CSAllocationRetentionPriority
- mobility.locationManagement.SupportedFeatures 
- mobility.subscriberManagement.AccessRestrictionData
- mobility.subscriberManagement.AdditionalInfo  
- mobility.subscriberManagement.AdditionalSubscriptions 
- mobility.subscriberManagement.AMBR    
- mobility.subscriberManagement.APNConfiguration    
- mobility.subscriberManagement.APNConfigurationProfile 
- mobility.subscriberManagement.CSGSubscriptionData 
- mobility.subscriberManagement.DCSI    
- mobility.subscriberManagement.DestinationNumberCriteria   
- mobility.subscriberManagement.DPAnalysedInfoCriterium 
- mobility.subscriberManagement.EPSQoSSubscribed    
- mobility.subscriberManagement.EPSSubscriptionData 
- mobility.subscriberManagement.ExternalClient  
- mobility.subscriberManagement.FQDN    
- mobility.subscriberManagement.GPRSCamelTDPData    
- mobility.subscriberManagement.GPRSCSI 
- mobility.subscriberManagement.LCSInformation  
- mobility.subscriberManagement.LCSPrivacyClass 
- mobility.subscriberManagement.LSAData 
- mobility.subscriberManagement.LSAInformation  
- mobility.subscriberManagement.MCSI    
- mobility.subscriberManagement.MCSSInfo    
- mobility.subscriberManagement.MGCSI   
- mobility.subscriberManagement.MMCode  
- mobility.subscriberManagement.MOLRClass   
- mobility.subscriberManagement.MTsmsCAMELTDPCriteria   
- mobility.subscriberManagement.OBcsmCamelTdpCriteria   
- mobility.subscriberManagement.ODBData 
- mobility.subscriberManagement.ODBGeneralData  
- mobility.subscriberManagement.ODBHPLMNData    
- mobility.subscriberManagement.PDNGWIdentity   
- mobility.subscriberManagement.PDNType 
- mobility.subscriberManagement.QoSClassIdentifier  
- mobility.subscriberManagement.ServiceType 
- mobility.subscriberManagement.SGSNCAMELSubscriptionInfo   
- mobility.subscriberManagement.SMSCAMELTDPData 
- mobility.subscriberManagement.SMSCSI  
- mobility.subscriberManagement.SpecificAPNInfo 
- mobility.subscriberManagement.SSCamelData 
- mobility.subscriberManagement.SSCSI   
- mobility.subscriberManagement.TBcsmCamelTdpCriteria   
- mobility.subscriberManagement.VlrCamelSubscriptionInfo    
- mobility.subscriberManagement.VoiceBroadcastData  
- mobility.subscriberManagement.VoiceGroupCallData  

A list of primitives that internal structure needs to be implemented:
- primitives.ISDNSubaddressString
- mobility.subscriberManagement.APNOIReplacement    
- mobility.subscriberManagement.CauseValue  
- mobility.subscriberManagement.ChargingCharacteristics 
- mobility.subscriberManagement.GroupId 
- mobility.subscriberManagement.LongGroupId 
- mobility.subscriberManagement.LSAAttributes   
- mobility.subscriberManagement.LSAIdentity 
- mobility.subscriberManagement.PDPAddress  
- mobility.subscriberManagement.Time    

A list of badly implemented primitives
- mobility.subscriberManagement.AllocationRetentionPriority 

A list of unimplemented primitives
- primitives.NAEACIC    
- primitives.NAEAPreferredCI

Original comment by serg.vet...@gmail.com on 21 Dec 2012 at 6:32

GoogleCodeExporter commented 9 years ago 
Hello!

> 1
> CauseValue is consist of two values; CauseValue class and value within the 
class. 
> Previously I thought of having two enums for CauseValue and Value within the 
class and have another constructor which takes two enums as arguments. 
>But with the actual values and the names for those values I though of having 
one enum instead of having two enums.
I vote for a single enum. We should have two constructirs: one with (int data) 
parameter, another with (new enum) parameter

> My second question is related to TBCD filler of GroupId and LongGroupId.
> GroupID extends TBCDString and it contaisn two static method (encodeString, 
decodeString). 
> Why those two methods are marked as static. 
That is why they are used also from classes that does not inherit TBCDString 
class.

> To have TBCS filler I though of overriding these two methods if it is not 
static. 
> The other solution I though is overriding encodeData and _decode method.
>What would you suggest to solve this. Are there any alternative solutions 
better than this.
For decoding: it looks like decodeString() just skip all fillers, so it is well 
for GroupId.
For encoding: encodeString() does not add fillers into "OutputStream asnOs", so 
we need something like it (+ some code for size==1, 0):
if(((AsnOutputStream)asnOs).size==2)asnOs.write(255);

To acheave it we need to override TBCDString.encodeData(AsnOutputStream asnOs). 
We can also create a superclass for GroupId and LongGroupId that implements it.

Original comment by serg.vet...@gmail.com on 23 Dec 2012 at 7:58

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi,

Thank you for the review and comments.
Please review the attached new patch file. This patch file contains fixes 
related to issue 172 as well.

Original comment by reachlas...@gmail.com on 28 Dec 2012 at 3:30

Attachments:

GoogleCodeExporter commented 9 years ago 
About the latest patch:
1. CauseValueCodeValue, LSAAttributes, LSAIdentity, Time: 
let's put at the top of files quotations from specifications that describe the 
intrenal structure of a primitive.

2. LSAAttributesImpl:
- we need "toString()" method
- lets create a "static private int" constants for masks like 0x0F, 0x10, 0x20 
and so on

3. NAEACIC:
Internal structure is described in 
ftp://ftp.3gpp2.org/Archive/TSGN%20(inactive)/Working/2001/2001_02_Chandler/Open
ing_Plenary/fyi%20T1%20Ballots/T1.113Ballot.pdf
in figures Figure 9/T1.113.3 and Figure 9A/T1.113.3 and in chapter "3.8A 
Carrier Identification"
Let's implement it

4. NAEAPreferredCI, TimeImpl, CCBSIndicatorsImpl:
- we need "toString()" method

5. Time:
- I have not revised all details of your implementation, but may be better to 
use for converting long->int->byte[] (and byte[]->int->long) 
ByteBuffer.getInt() / putInt() methods. It is more elegant and more fast

6. ExtendedRoutingInfo:
- we need an extra unit test for CamelRoutingInfo choice

7. GroupId, LongGroupId:
replace
    public GroupIdImpl() {
        super(1, 3, "GroupId");
    }
with
    public GroupIdImpl() {
        super(3, 3, "GroupId");
    }
(+ other 3 cases) - minLength constructor parameter must be 3 or 4

8. VoiceBroadcastData, VoiceGroupCallData
- may be can acccept when encoding "this.groupId == null" if 
"longGroupId!=null" and do not throw an exception?
- for unittests: lets provide two unittests:
one when groupId!=null and longGroupId==null
second when groupId==null and longGroupId!=null
(now you provide a test in testEncode() you use groupId!=null and 
longGroupId!=null)

9. InsertSubscriberDataRequestImpl:
- let's remove TeleServiceCode, BearerServiceCode and Charging Characteristics 
Flags from here. We have separate enums for this.

10. SendRoutingInformationRequestImpl:
- no unittests for MAP V3
- this test does not cover all parameters

11. SendRoutingInformationResponseImpl: this test does not cover all parameters

to be continued ...

Original comment by serg.vet...@gmail.com on 30 Dec 2012 at 8:15

GoogleCodeExporter commented 9 years ago 
1. So the list unimplemented messages

A list of primitives that internal structure needs to be implemented or not 
fully implemented primitives:
- primitives.ISDNSubaddressString
- primitives.Time   
- primitives.NAEACIC
- mobility.subscriberManagement.APNOIReplacement
- mobility.subscriberManagement.ChargingCharacteristics
- mobility.subscriberManagement.GroupId
- mobility.subscriberManagement.LongGroupId
- mobility.subscriberManagement.PDPAddress  

2. We need to update org.mobicents.protocols.ss7.map.api.MAPParameterFactory 
and add there new uplemented MAP parameters creating (for choices we need 
several methods for creating!) and a corresponded update in 
MAPParameterFactoryImpl.

3. Other procedures and functional tests look good for me. Please commit you 
update. We need to finish that has not beed yet implemented. 
Also I will update Issue 172 (sendRoutingInfo operation).

Pay attenstion that when functional tests (nlike unittests) we need not test 
absolutely all parameters encoded, just mandatory and may be some typical used. 
Also for unittests we need not test all subparameters for sequence parameters. 
Only all parameters for root sequence of a priimitive (if it is a SEQUENCE of 
cause)

Original comment by serg.vet...@gmail.com on 1 Jan 2013 at 1:55

GoogleCodeExporter commented 9 years ago 
Hi 

Thank you. Please review the attached patch file as well. TimeImpl internal 
structure changes were not included in this file.

Original comment by reachlas...@gmail.com on 1 Jan 2013 at 5:10

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi 
The reason for build fail is the timezone. Time should be based on the UTC 
time. Therefore i changed the implementation to get the UTC time and also 
changes the long -> byte conversion. Please check the attached path.

Original comment by reachlas...@gmail.com on 6 Jan 2013 at 7:08

Attachments:

GoogleCodeExporter commented 9 years ago 
Hello!

1. Time: In you r current implementation values in getters and in a constructor 
are presented in UTC time (not local time). Please make a remark about this in 
comments of Time.java / TimeImpl.java

2. Other looks good for me, commit it please

3. Let's update MAPParameterFactory and usage it in MAPFunctionalTest to have 
this MAP operation implemented

What is not done yet:
1. So the list unimplemented messages

A list of primitives that internal structure needs to be implemented or not 
fully implemented primitives:
- primitives.ISDNSubaddressString
- mobility.subscriberManagement.APNOIReplacement
- mobility.subscriberManagement.ChargingCharacteristics
- mobility.subscriberManagement.PDPAddress

2. We need to update org.mobicents.protocols.ss7.map.api.MAPParameterFactory 
and add there new uplemented MAP parameters creating (for choices we need 
several methods for creating!) and a corresponded update in 
MAPParameterFactoryImpl.

Original comment by serg.vet...@gmail.com on 8 Jan 2013 at 11:40

GoogleCodeExporter commented 9 years ago 
Hi
Attached herewith is the MAPParameterFactory update. Please review the patch.

Original comment by reachlas...@gmail.com on 8 Jan 2013 at 5:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi,
Could you please tell me what is really mean by "usage it in MAPFunctionalTest" 
in point number 2. You want me to use the creation methods in 
MAPParameterFactory to create primitives within MAPFunctionalTest.

Original comment by reachlas...@gmail.com on 9 Jan 2013 at 11:20

GoogleCodeExporter commented 9 years ago 
Hi 
Please use isd8.patch instead of isd7.patch. it contains all newly implemented 
methods for MAPParameterFactory and updates for MAPFunctionalTest.

Original comment by reachlas...@gmail.com on 9 Jan 2013 at 7:27

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi Please review the attached patch for PDP address and ChargingCharacteristics 
internal structure.

Original comment by reachlas...@gmail.com on 10 Jan 2013 at 5:00

Attachments:

GoogleCodeExporter commented 9 years ago 
Hello!

1. About MAPParameterFactory: this patch looks good for me. The only thing that 
I have not checked if all primitives that you have implemented (and all choices 
constructors) are included in the patch. You can check it from a primitive list 
from this issue (and insertRoutingInfo issue). It is a good idea to include 
primitives into MAPParameterFactory just after they have been implemented.

2. ChargingCheracteristic looks good for me

3. PDPAddress:
- We have to implement PDPType first of all. You can see details in 29.060 in 
"7.7.27 End User Address" chapter. It is simple. We need an extra enum 
PDPTypeValue for PDPType values enumerating
- Using "String" in a constructor of PDPAddress and in "getAddressString()" is 
a good idea. But for both cases we need an extra parameter - PDPTypeValue:
PDPAddressImpl(String address, PDPTypeValue typeValue) { ... }
String getAddressString(PDPTypeValue typeValue);
- PPP case: it looks like it is just digits encoded by TbcdString. Look for 
example here: http://en.wikipedia.org/wiki/X.121. I think we can add TbcdString 
encoding/decoding at this step for PPP case.

We have to release jss7 BETA4 today. I will commit your MAPParameterFactory 
patch now. 
ChargingCheracteristic and PDPAddress/Type we will postpone to a next release, 
please do not commit this now.

Original comment by serg.vet...@gmail.com on 12 Jan 2013 at 8:41

GoogleCodeExporter commented 9 years ago

Original comment by amit.bha...@gmail.com on 13 Jan 2013 at 5:57