Ethereal-dev: Re: [Ethereal-dev] Questions about Connection Oriented SCCP

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jeff Morriss <morriss@xxxxxxxxx>
Date: Tue, 14 Oct 2003 10:32:27 -0400


Michael Lum wrote:


-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
Sent: Wednesday, October 08, 2003 12:11 AM
To: Michael Lum
Cc: packet steve; ethereal-dev@xxxxxxxxxxxx; Jeff Morriss
Subject: Re: [Ethereal-dev] Questions about Connection Oriented SCCP


On Tue, Oct 07, 2003 at 01:37:41PM -0700, Michael Lum wrote:

OK, a given MTP3 point code pair, SSN=142 (RANAP), and the associated
SLR/DLR defines a conversation.  We can associate a dissector with that
conversation.

Why would the SSN be needed to define the conversation? Can there be
more than one SSN used in a connection? If so, how do you know how to
dissect the payload of packets lacking an SSN?


The SSN is only available with the SCCP Connection Request and is required
to know what type the payload is.  There is only one SSN for a connection.
I was trying to say that if the SCCP CR is for SSN=142 then we know what
dissector is required for the payload (RANAP).  Any subsequent SCCP messages
in the connection will also contain a RANAP payload (if any) and I am
assuming that means for the conversation.

For example SSN=142 would imply RANAP, SSN=252 would imply IOS, SSN=254
could be GSM BSSAP or IS-634 or IOS.

I suppose you could rely on heuristics but I have found that doesn't work
all of the time.

The SSN isn't needed to define the conversation but needs to be part of the conversation data (so that the SCCP dissector knows that a DT1 for DPC1/DLR1 and OPC2/SLR2 has SSN Y).

In thinking about it, though, I suppose that just xPC+xLR isn't quite sufficient: really it should use the called party address + DLR and calling party address + SLR. (Not that I've ever seen SCCP-Class2 use GT but I don't think the specs preclude it.)

SCCP Release Complete MTP3 [OPC=X, DPC=Y, SLR=A, DLR=B] or

[OPC=Y, DPC=X,

SLR=B, DLR=A]
	end of conversation

Note that, currently, conversations have no notion of a beginning or
end; we could add one, along the lines of what we do for "circuits".


The notion of 'end' is important because xLRs will eventually be reused.
One would normally expect a given OPC/DPC pair to use one SSN but you
never know.

That's true--especially since xLRs are "only" 24 bits long--and at least at the A-interface connections are very short lived.