| Bug ID |
9355
|
| Summary |
Session ID for ISUP
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.2
|
| Hardware |
x86
|
| OS |
Windows 8
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
Wireshark
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
--
I think it would be very useful if ISUP's protocol options supported the same
"Persistent stats for srtt" option as TCAP, adding an ISUP equivalent to the
"tcap.srt.session_id" field available in TCAP. There are several reasons for
this:
- ISUP protocol's session identifier is the "CIC". As an identifier for
Wireshark protocol analysis, it has significant limitations due to the nature
of its reuse between common endpoints. Many implementations of ISUP reuse CIC
values frequently after call termination, meaning an attempt to trace one ISUP
call via CIC value even within the context of a single trace file can be
difficult or impractical.
- The SS7 protocol stack allows for multiple ISUP messages to be sent in the
same frame. Because each subsequent ISUP message for a single call can occur in
different positions in each subsequent packet, tracing a single ISUP call by
CIC and sorting for a call termination specific to that CIC to identify a
session can be a manual challenge for the user.
- By its very nature, ISUP signaling is typically present between telecom
infrastructure under heavy packet-per-second load. This is unavoidable but it
does increase the value in having a persistent session identifier that is not
subject to reuse in the context of a single trace file, since typically the
start of a call (IAM message) will have unique/permanent identifiers and can be
easily found and referenced, but afterward all subsequent messages in the call
have no common value to predictably search by except the CIC value, which is
again subject to reuse.
In short, this would be useful to ISUP for the same reasons it is so useful for
TCAP analysis. providing a consistent identifier for a single call.
You are receiving this mail because:
- You are watching all bug changes.
