Status: Accepted
Owner: [email protected]
Labels: Type-Defect Priority-Medium Component-SS7 Roadmap-Fix
Version-2.0.0.BETA4
New issue 223 by [email protected]: docs update for changing CLI
interface for TCAP stack - a cumulative list
http://code.google.com/p/jss7/issues/detail?id=223
For TCAP manual we need:
- in "8.1. Mobicents jSS7 Stack TCAP Usage"
replase
"The TCAP stack creates internaly Mobicents MAP Stack implementation"
with
"The TCAP stack can be created internaly by Mobicents MAP/CAP Stack
implementations or it can be created directly"
- add at the end of chapter "8.1. Mobicents jSS7 Stack TCAP Usage" some
extra info:
----------------------
TCAPStack has the following configurable options:
- DialogIdleTimeout:
public void setDialogIdleTimeout(long l);
Sets millisecond value for dialog timeout. It specifies how long dialog can
be idle - not receive/send any messages. After this timeout occur
TCListener.onDialogTimeout() will be invoked and if a TCAP user does not
invoke Dialog.keepAlive() inside TCListener.onDialogTimeout() method the
TCAP Dialog will be released
- DialogIdleTimeout:
public void setDialogIdleTimeout(long l);
Sets millisecond value for default Invoke timeout. It specifies how long
Invoke will wait for a response from a peer. If a TCAP used does not
specify a custom Invoke timeout when a new Invoke sending this value will
be used for outgoing Invoke timeout. After this timeout occur
TCListener.onInvokeTimeout() will be invoked.
- MaxDialogs:
public void setMaxDialogs(int v);
Sets the maximum number of dialogs allowed to be alive at a given time. If
not set, a default value of 5000 dialogs will be used.
- DialogIdRangeStart and DialogIdRangeEnd:
public void setDialogIdRangeStart(long val);
public void setDialogIdRangeEnd(long val);
TCAP stack can be configured to use a range of local DialogId ranges. We
may install a set of TCAP stack instances with different DialogId ranges.
These ranges can be used for loadsharing of SS7 traffic between TCAP
instances.
- PreviewMode:
public void setPreviewMode(boolean val);
PreviewMode is needed for special processing mode.
When PreviewMode in TCAP level we have:
- we only listern incoming messages and sends nothing. send(),
close(), sendComponent() and other such methods do nothing.
- A TCAP Dialog is temporary. TCAP Dialog is discarded after any
icoming message like TC-BEGIN or TC-CONTINUE has been processed
- for any incoming messages (including TC-CONTINUE, TC-END, TC-ABORT)
a new TCAP Dialog is created (end then deleted).
- no timers and timeouts
default state: no PreviewMode
Common scenario of using TCAP stack is:
- Creating TCAP Dialog by TCAPProvider.getNewDialog() or
getNewUnstructuredDialog()
- adding components into a Dialog for sending by Dialog.sendComponent();
- sending a TCAP message TC-UNI, TC-BEGIN, TC-CONTINUE, TC-END or TC-ABORT
via Dialog.send() methods
- waiting for responses of a peer
- when TCAP stack receives a message from a peer events like
TCListener.onTCUni(), onTCBegin(), onTCContinue(), onTCEnd(),
onTCUserAbort(), onTCPAbort() will be invoked
- after an Invoke component is received a TCAP user should process it and
- send a response (ReturnResult, ReturnResulLast components) or
- send an error (ReturnError or Reject components) or
- invoke Dialog.processInvokeWithoutAnswer() method if TCAP uses will not
answer to the Invoke
----------------------
