["Michael Lum" <mlum@xxxxxxxxxxxxx>]

I don't know much (anything) about conversations, do they have the
capability to follow what could be long lasting SCCP connections.

I am currently using an heuristic dissector.

Does anyone know of other Connection Oriented SCCP protocols other
than RANAP, GSM BSSAP, and IOS/IS-634 BSAP ?

I currently have all 3 working but for BSSAP/BSAP you have to set
a preference to have the payload pushed out as one or the other
because you can't tell the difference.

It seems like a lot of work to keep track of the MTP3/xLR/SSN
data.

> -----Original Message-----
> From: Jeff Morriss [mailto:morriss@xxxxxxxxxxx]
> Sent: Tuesday, October 07, 2003 8:01 AM
> To: packet steve
> Cc: guy@xxxxxxxxxxxx; mlum@xxxxxxxxxxxxx; ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] Questions about Connection Oriented SCCP
>
>
>
> I agree the best way would be to track the connections--there's a
> comment about this in the dissector now:
>
> >   case MESSAGE_TYPE_CC:
> >     /*  TODO: connection has been established;  theoretically
> we could keep
> >      *  keep track of the SLR/DLR with the called/calling from
> the CR and
> >      *  track the connection (e.g., on subsequent messages
> regarding this
> >      *  SLR we could set the global vars "call*_ssn" so data could get
> >      *  sub-dissected).
> >      */
>
> I think a conversation is probably the best way to go--MTP3 point codes
> are the addresses and xLRs are the "ports", though in order to do this I
> think the conversation routines would need to know about MTP3 point
> codes as addresses (probably as guint32's so the conversation code
> wouldn't have to learn about all the different variants?).
>
> packet steve wrote:
>
> > A heuristic dissector would be difficult.  A better solution is
> to track
> > of the SCCP connections.   SCCP tries hard to save bytes:  Few messages
> > contain both source and destination reference numbers.   For RANAP, the
> > SCCP Connection Request comes from the radio network (UTRAN) and
> > contains a UTRAN local reference number.   The subsequent SCCP
> > Connection Confirm has both core network and UTRAN reference numbers:
> > these are key values for the connection, though you'll probably also
> > want to track MTP3.
> >
> > DATA FORM 1 will contain RANAP messages.
> >
> >
> >> On Oct 6, 2003, at 8:29 AM, Michael Lum wrote:
> >>
> >>> There is a problem with the RANAP dissector in that it
> >>> will only dissect packets that have the correct SSN.
> >>>
> >>> However, RANAP, and A-interface (BSSAP/BSAP) protocols
> >>> use connection oriented SCCP.  Most of the messages do not
> >>> contain an SSN field.
> >>>
> >>> The following messages are used:
> >>>
> >>> UNITDATA
> >>> Connection Request
> >>> Connection Confirm
> >>> Connection Refused
> >>> DATA FORM 1
> >>> RELEASED
> >>> RELEASE COMPLETE
> >>>
> >>> Only the UNITDATA and Connection Request contain an SSN field.
> >>
> >>
> >> I presume at least one of those other message types contains payload
> >> to be dissected as, for example, RANAP, even though they
> contain no SSN.
> >>
> >>> What is the best solution for making sure the dissector gets all
> >>> the messages?
> >>
> >>
> >> Either
> >>
> >>     1) make the dissectors in question heuristic
> >>
> >> or
> >>
> >>     2) add support for some notion of an SCCP connection that includes
> >> the ability to attach a dissector to the connection.
> >>
> >> There are two mechanisms that could be used for that notion of a
> >> connection:
> >>
> >>     1) conversations, for protocols where packets contain identifiers
> >> for both endpoints;
> >>
> >>     2) circuits, for protocols where packets contain a circuit ID
> >> value rather than endpoint identifiers.
> >>
> >> _______________________________________________
> >> Ethereal-dev mailing list
> >> Ethereal-dev@xxxxxxxxxxxx
> >> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >
> > _________________________________________________________________
> > Share your photos without swamping your Inbox.  Get Hotmail Extra
> > Storage today! http://join.msn.com/?PAGE=features/es
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>
> --
> Jeff Morriss
> Senior Software Support Engineer
> Ulticom, Inc.
> Helpdesk: +1-856-787-2765
> Fax: +1-856-222-9947