Comment #4 on issue 204 by [email protected]: Some updates for
messageflow in TCAP/MAP/CAP layers
http://code.google.com/p/jss7/issues/detail?id=204
5. I have some doubts about a processing of one abnormal situation in
TCAP/MAP/CAP - Reject with the reason problem code = invoke problem =
duplicate invoke ID:
"The invoke ID is that of a previously invoked operation which has not
been completed. This code is generated by the TC-User."
This situation must be processed at the receiving side. TCAP-user must
have list of incoming invocations that have not yet processed. Now we
have in MAP/CAP stacks "incomingInvokeList" where incoming invokeId's
are added. ("incomingInvokeList" was also used for linkedId resolving
- that was a mistake and we do not neet it). After a response
(returnResultLast or returnError) the invokeId is removed from
"incomingInvokeList". When new Invoke incoming we check if Invoke's
invokeId is present in "incomingInvokeList" and if yes - we reject
this Invoke with the cause "duplicate invoke ID".
This works fine in MAP when almost all operations are class1 and have
response or error answers. But in CAP most of operations usually has
no answers and this lead "incomingInvokeList" keeps all this incoming
invokeId's and will reject new incoming Invokes with the same
InvokeId. This case is not very often but it can occure.
Possible solution may be:
1. We remove "incomingInvokeList" at all and let a MAP/CAP user itself
keep a list of unanswered Invokes and generates "duplicate invoke ID"
itself
2. We have to introduce a new method (for example
MAPMessage.processWithoutAnswer()) which should be invoked if there
will be no answer to an incoming MAP/CAP message (it will remove
invokeId from "incomingInvokeList"). This way looks better for me but
it leads to update previous written code that uses CAP stack (insert
this message). Althow I guess there is not much such written code for
CAP (unlike MAP) yet.
WDYT?
6. Another missed functional in TCAP layer:
We have various different reasons for parsing error:
GeneralProblemType, InvokeProblemType, ReturnResultProblemType,
ErrorProblemType.
But now when parsing we generate a singe ParseException without any
parameters and send the only reason for all errors -
PAbortCauseType.BadlyFormattedTxPortion.
This issue needs also some testing.
WDYT, will we fix it?
7. PAbortCauseType.DialogIdleTimeout - is not used, may be we need to
remove it?
