Closed GoogleCodeExporter closed 9 years ago
Original comment by reachlas...@gmail.com
on 29 Dec 2012 at 5:21
Hi
Please review the attached patch file for issues from 205 to 216 (except issue
215).
Original comment by reachlas...@gmail.com
on 8 Jan 2013 at 7:43
Attachments:
Hello!
Here is a my comments:
1.
org.mobicents.protocols.ss7.cap.api.service.gprs.primitive.AccessPointName: and
org.mobicents.protocols.ss7.map.api.service.mobility.subscriberManagement.APN
(from TS 3GPP TS 23.003):
The encoding of the APN shall follow the Name Syntax defined in RFC 2181 [18],
RFC 1035 [19] and RFC 1123 [20].
The APN consists of one or more labels. Each label is coded as a one octet
length field followed by that number of
octets coded as 8 bit ASCII characters. Following RFC 1035 [19] the labels
shall consist only of the alphabetic
characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following RFC 1123
[20], the label shall begin and end with
either an alphabetic character or a digit. The case of alphabetic characters is
not significant. The APN is not terminated
by a length byte of zero.
NOTE: A length byte of zero is added by the SGSN/MME at the end of the APN
before interrogating a DNS
server.
For the purpose of presentation, an APN is usually displayed as a string in
which the labels are separated by dots (e.g.
"Label1.Label2.Label3").
May be can create a getter (String getAPN()) amd a constructor with a parameter
(String apn) where apn string=="Label1.Label2.Label3".
2. We need unittests for:
CAMELFCIGPRSBillingChargingCharacteristics, SGSNCapabilities
3. FreeFormatData: do we need to implement this internal structure?
4. ChargingCharacteristics:
for "empty" values for parameters I meant "0" values, not "-1".
because "0" is not possible.
But your chaice is possible, you only should add comments in
ChargingCharacteristics like:
"-1 means an absent value"
5. GPRSCause:
I am little confused here.
A specification says about mapping to GTP cause, GMM cause and SM cause values.
But I do not undwerstand which values to use.
Can anybody help me?
6. ApplyChargingReportGPRS:
- active [2] BOOLEAN DEFAULT TRUE:
there are two approaches for encoding a parameter when value==TRUE:
a) sending boolean(true)
b) just sending nothing ("nothing" means "TRUE")
You selected the option a). I do not really know which of approaches is better
:(
We can look at live traces to find which method is usually ised.
Another solution is boolean->Boolean replacing. And we can give to a CAP user
an opportunity to select between true and null.
- pay attention to "RETURN RESULT TRUE" in ApplyChargingReportGPRS.
This means that we must implement "empty" (parameterless)
ApplyChargingReportGPRSResponse
(not only ApplyChargingReportGPRSRequest) primitive.
7. EntityReleasedGPRSResponse:
we need to implement it
8. furnishChargingInformationGPRS:
bad implementation, look:
FurnishChargingInformationGPRSArg {PARAMETERS-BOUND : bound} ::=
FCIGPRSBillingChargingCharacteristics{bound}
FCIGPRSBillingChargingCharacteristics {PARAMETERS-BOUND : bound} ::= OCTET
STRING (SIZE(1 .. 160))
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type -
CAMEL-FCIGPRSBillingChargingCharacteristics {bound}})
So the top level is OCTET STRING, getTag()->Tag.STRING_OCTET,
getIsPrimitive()->true
And the OCTET STRING contains an encoded SEQUENCE
Original comment by serg.vet...@gmail.com
on 9 Jan 2013 at 7:52
Hi
Thank you for your comments. Please review the attached patch as well. This
patch includes implementations of issue 215 and 217.
A CAPFunctionalTest was also included just to check the gprs package.
Original comment by reachlas...@gmail.com
on 20 Jan 2013 at 1:39
Attachments:
Hi
I am doing some test cases based on the live trace. When I create a test case
for EventReportGPRSRequest using the No.21 of the live trace, the encoded
message byte stream didnt match with the live trace byte stream. When I check
the error, i found that it is a problem with LocationInformationGPRS encoding.
When I use below to encode CellGlobalIdOrServiceAreaIdOrLAIImpl of
LocationInformationGPRS, our encoded stream matched with the live stream.
if (this.cellGlobalIdOrServiceAreaIdOrLAI != null) {
((CellGlobalIdOrServiceAreaIdOrLAIImpl) this.cellGlobalIdOrServiceAreaIdOrLAI).encodeAll(asnOs, Tag.CLASS_CONTEXT_SPECIFIC, _ID_cellGlobalIdOrServiceAreaIdOrLAI);
}
Please advice me the whether this change is right or wrong.
And same thing happened for InitialDpGprsRequest live trace test case.
Thank you.
Original comment by reachlas...@gmail.com
on 24 Jan 2013 at 2:37
Hello!
I have revised cap-gprs2.patch. Here are my remarks:
1. SGSNCapabilities - we need extra constructor (+ CAPParameterFactory):
SGSNCapabilitiesImpl(boolean aoCSupportedBySGSN)
2.
DetachSpecificInformation,DisconnectSpecificInformation,PdpContextchangeOfPositi
onSpecificInformation,
PDPContextEstablishmentAcknowledgementSpecificInformation,PDPContextEstablishmen
tSpecificInformation:
please replase code like
public int getTag() throws CAPException {
return _ID_PdpContextchangeOfPositionSpecificInformation;
}
with
public int getTag() throws CAPException {
return Tag.SEQUENCE;
}
That is while _ID_PdpContextchangeOfPositionSpecificInformation code (and
similar ones for other primitives) are only for encoding
in GPRSEventSpecificInformation. Potencially it can be used in other place as a
part of other primitives
3. ApplyChargingReportGPRSResponseImpl:
getMessageType():
applyChargingReportGPRS_Request -> applyChargingReportGPRS_Response (need to be
created)
4. EntityReleasedGPRSResponseImpl:
getMessageType():
entityReleasedGPRS_Request -> entityReleasedGPRS_Response (need to be created)
5. EventReportGPRSResponseImpl:
getMessageType():
eventReportGPRSResponse_Request -> eventReportGPRSResponse_Response (need to be
created)
6. About application context names support for different GPRS operations:
- initialDP is supported only by cap3-gprssf-scf ANC (21.3.50)
- ALL other GPRS operations are supported by both cap3-gprssf-scf ANC (21.3.50)
and cap3-gsmscf-gprsssf (21.3.51)
Now several operations not supported by cap3-gsmscf-gprsssf. Please update it -
it is important (both in CAPDialog* and CAPService*)
7. furnishChargingInformationGPRS: still bad encoding from my point of view
Your unit test encoded data for furnishChargingInformationGPRS is:
4, 20, -96, 18, -96, 16, -128, 8, 48, 6, -128, 1, 5, -127, 1, 2, -127, 1, 2,
-126, 1, 1
I think it must be:
4, 20, 48, 18, -96, 16, -128, 8, 48, 6, -128, 1, 5, -127, 1, 2, -127, 1, 2,
-126, 1, 1
4, 20, OCT_STR - FCIGPRSBillingChargingCharacteristics
48, 18, SEQ CAMEL-FCIGPRSBillingChargingCharacteristics
-96, 16, [0] SEQ fCIBCCCAMELsequence1 - choice 0
-128, 8, 48, 6, -128, 1, 5, -127, 1, 2, [0] OCT_STR - FreeFormatData
-127, 1, 2, [1] OCT_STR - PDPID
-126, 1, 1 [2] ENUM - AppendFreeFormatData
So CAMEL-FCIGPRSBillingChargingCharacteristics must be SEQUENCE UNIVERSA, not
CONTEXT-SPECIFIC
8. CAPServiceGprsImpl.furnishChargingInformationGPRSRequest:
error when tag checking: tag==octetstring+primitive
9. SendChargingInformationGPRSRequestImpl:
bad encoding - the root element is SEQUENCE, not STRING_OCTET
10. activityTestGPRS operation - is not implemented at all
Please commit your patch and then fix bugs
I will public CAPFunctional test scenarios soon for implementing
Original comment by serg.vet...@gmail.com
on 27 Jan 2013 at 4:36
Hello!
Here is scenarios for CAPFunctionalTest for GPRS.
Let's implement them.
/**
* GPSR messageflow 1
* ACN=cap3-gprssf-scf
*
* TC-BEGIN + InitialDPGPRSRequest + originationReference=1001
* TC-CONTINUE + requestReportGPRSEventRequest + destinationReference=1001 + originationReference=2001
* TC-CONTINUE + furnishChargingInformationGPRSRequest
* TC-CONTINUE + eventReportGPRSRequest
* TC-CONTINUE + eventReportGPRSResponse
* TC-CONTINUE + resetTimerGPRSRequest
* TC-CONTINUE + applyChargingGPRSRequest + connectGPRSRequest
* TC-CONTINUE + applyChargingReportGPRSRequest
* TC-END + applyChargingReportGPRSResponse
*/
/**
* GPSR messageflow 2
* ACN=cap3-gsmscf-gprsssf
*
* TC-BEGIN + activityTestGPRSSRequest + destinationReference=1001 + originationReference=2001
* TC-CONTINUE + activityTestGPRSSResponse + destinationReference=2001 + originationReference=1001
* TC-CONTINUE + furnishChargingInformationGPRSRequest + continueGPRSRequest
* TC-CONTINUE + eventReportGPRSRequest
* TC-END + eventReportGPRSResponse + cancelGPRSRequest
*/
/**
* GPSR messageflow 3
* ACN=cap3-gprssf-scf
*
* TC-BEGIN + eventReportGPRSRequest + destinationReference=2001 + originationReference=1001
* TC-END + eventReportGPRSResponse + connectGPRSRequest + sendChargingInformationGPRSRequest + destinationReference=1001 + originationReference=2001
*/
/**
* GPSR messageflow 4
* ACN=cap3-gsmscf-gprsssf
*
* TC-BEGIN + releaseGPRSRequest + destinationReference=1001 + originationReference=2001
* TC-END + destinationReference=2001 + originationReference=1001
*/
Original comment by serg.vet...@gmail.com
on 28 Jan 2013 at 5:43
Hi
Thank you for the review and test cases. Please review the attached patch which
includes test cases and bug fixes.
Original comment by reachlas...@gmail.com
on 9 Feb 2013 at 1:33
Attachments:
Hello!
About the last patch:
1. SendChargingInformationGPRSRequest
It looks like the encdoding is still wrong:
From your test:
48, 44,
-96, 42,
-96, 37, -96, 21, -128, 1, 1, -127, 1, 2, -126, 1, 3, -125, 1, 4, -124, 1, 5, -123, 1, 6, -122, 1, 7, -95, 12, -96, 6, -125, 1, 4, -124, 1, 5, -127, 2, 0, -34,
-127, 1, 1
I think it should be:
48, <length>, SEQUENCE - SendChargingInformationGPRSArg {PARAMETERS-BOUND:
bound}::= SEQUENCE {
128, <length>, [0] - primitive (OCTET STRING) - SCIGPRSBillingChargingCharacteristics {PARAMETERS-BOUND : bound} ::= OCTET STRING (SIZE (4 .. 255))
48, <length> - CAMEL-SCIGPRSBillingChargingCharacteristics ::= SEQUENCE {
160, <length>, <element> - aOCGPRS [0] AOCGPRS
129, <length>, <element> - pDPID [1] PDPID OPTIONAL
2. CAPFunctionalTests: I have not checked details. You can check MAP and CAP
functional tests now by creating a test trace pcap file and checking it then by
WireShark.
To do this please follow these steps:
- select one test for testing, for example we starts with testGPRS1()
- insert at the beginning of the test code (for example before "long stamp =
System.currentTimeMillis();") this code:
"this.saveTrafficInFile();"
- run the test for example in Eclipse
- then you can find a new file "MsgLog.pcap" in "cap" folder
- open it by WireShark and check if it "understands" all correctly
- remove or comment "this.saveTrafficInFile();" line
then you can move to a next gprs test.
Please commit your update. Pay attention that it will be conflicts in
initialDPGprs merging because of this my update:
http://code.google.com/p/jss7/source/detail?r=b35cb0b7edbebd38ba4653b686cc576ff7
b185cd
Original comment by serg.vet...@gmail.com
on 10 Feb 2013 at 9:28
Hi
Please review the attached patch for SendChargingInformationGPRSArg encoding
error.
Thank you.
Original comment by reachlas...@gmail.com
on 13 Feb 2013 at 2:09
Attachments:
This update looks good for me. Please commit it.
Original comment by serg.vet...@gmail.com
on 13 Feb 2013 at 5:40
Original comment by reachlas...@gmail.com
on 5 Mar 2013 at 2:28
Original comment by amit.bha...@gmail.com
on 3 Nov 2013 at 12:10
Original comment by amit.bha...@gmail.com
on 3 Nov 2013 at 12:12
Original issue reported on code.google.com by
amit.bha...@gmail.com
on 19 Dec 2012 at 12:37