search

harshsxn / jss7

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

TCAP stack core update: unproper message processing details #40

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
As for now when processing incoming TCAP messages provider errors are not 
processing correctly. We need to announce both of the local TCAP user and the 
remote peer.

To achieve this I have added TCPAbortIndication.isLocalProviderOriginated().
TCListener.onTCPAbort(TCPAbortIndication ind) will be delivered to both of the 
local and remote peer.

Original issue reported on code.google.com by serg.vet...@gmail.com on 28 Apr 2012 at 5:11

GoogleCodeExporter commented 9 years ago 
2. DialogImpl.send(...) - several methods for TCBeginRequest, TCContinueRequest 
and so on:
All Exceptions that occure at below levels (SCCP/MTP) are caught there and do 
not sent to the upper levels
At MAP, CAP, SCCP and MTP levels all Exceptions are sent to the upper level
I mean exceptions of bad data, bad formatting and so on when sending messages 
to the other peer.
Exceptions at MTP level relating to transmitting data failure are not exposing 
to the upper levels and I think it is good
But at the TCAP level exceptions from SCCP/MTP are cut
So we need to expose Exceptions that have come from below levels to TCAP-Users

3. TCAP stack keeps Dialogs for 30 seconds after it is really released.
Keeps for 30 second after END is sent or received:
basically this is to make sure correct events are fired for TCAP User
correct sequence of events.
We can refactor code so the correct sequence of events will be kept without 
this delay

4. We need also the update of corresponding parts of MAP/CAP stackes

Original comment by serg.vet...@gmail.com on 30 Apr 2012 at 5:29

GoogleCodeExporter commented 9 years ago 
The update for this issue is included in this update
http://code.google.com/p/jss7/issues/detail?id=39

Several comments:
- Parsing protocol-version fields of AARQ, AARE apdu's and checking if the 
other side supports Version 1 of the TCAP protocol (the only current supported) 
and returning an error message if no
- the algorithm of getting new dialogId and invokeId's ha been updated
- processing of incoming TCAP messages has been updated, adding proper 
processing for some abnormal cases, added several unit-tests for it
- unstructured Dialog (for TC-UNI processing)is not now added into the dialogs 
collection and dialogId's does not assigned for it
- TCAP Dialogs 30-seconds delay after releasing has been removed

Original comment by serg.vet...@gmail.com on 9 May 2012 at 5:48

GoogleCodeExporter commented 9 years ago

Original comment by serg.vet...@gmail.com on 15 May 2012 at 12:15