> -----Original Message-----
> From: Jeff Morriss [mailto:morriss@xxxxxxxxx]
> Sent: Tuesday, October 14, 2003 7:32 AM
> To: mlum@xxxxxxxxxxxxx
> Cc: Guy Harris; packet steve; ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] Questions about Connection Oriented SCCP
>
>
>
>
> 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.)
>
Unfortunately the Calling party address in the SCCP Conn Req is optional
as is the Called party address in the SCCP Conn Confirm!
I am working on a new IOS dissector and I already have a BSSAP/BSAP
dissector
that is heuristic. I also have mods to the RANAP dissector to make it
heuristic (I removed them from the last patch). I want to just go with
that for now.
> >>>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.
>