Yes, basically it is but with SCCP, ALCAP and GTP-C (and maybe more
that I do not know) the conversation API doesn't fit.
these protocols exchage session keys at various steps.
1. orig sends its new session reference
2. dest sends its new session ref to orig's ref
>From there on the exchange goes with each part addressing the message
to the peer's reference, never (but in the response to the setup
message) you see the references of both sides. more than that you are
not guaranteed to have the dest reference in every packet from orig to
dest nor viceversa.
I did it because I found RANAP heuristics way too heuristic to be
reliable, and the only way to map the calling/called SSN correctly in
connection oriented sessions was to keep track of the session.
These type of asymetric reference sessions should be handled by the
conversations API. There are two different and similar implementations
one in alcap and one in sccp to start with. But little spare time to
do it.
Luis.
On 1/19/06, Jeff Morriss <jeff.morriss@xxxxxxxxxxx> wrote:
>
> I'd been meaning to take a look at the binding_info stuff. Is it
> basically equivalent to a conversation for SCCP? (I had always
> envisioned using/adapting the conversation stuff to SCCP to keep track
> of Class-2 stuff but have never had time.)
>
> LEGO wrote:
> > I think it should not be hard to do it based of the binding_info.
> >
> > Beware that if (binding == &no_binding) we do not have a binding so
> > you should not reassemble or else we'll have trouble.
> >
> > BTW: binding is not the propper name, session or call might be better names.
> >
> > Luis
> >
> > On 1/18/06, Anders Broman <a.broman@xxxxxxxxx> wrote:
> >> Hi,
> >> I'm looking into it.
> >> Brg
> >> Anders
> >>
> >> Hi Olivier,
> >>
> >> you are correct, SCCP reassembly is currently not implemented.
> >>
> >> Best regards
> >> Michael
> >>
> >> On Jan 18, 2006, at 3:35 PM, Jacques, Olivier (OCBU-Test Infra) wrote:
> >>
> >>> Hello,
> >>>
> >>> It seems that SCCP (with TCAP payload) re-assembly (XUDTs) is not
> >>> supported in Ethereal.
> >>> Anyone already looked at it? Any thoughts?
> >>>
> >>> I have a trace I can send on demand.
> >>>
> >>> Olivier.
> >>> _______________________________________________
> >>> Ethereal-dev mailing list
> >>> Ethereal-dev@xxxxxxxxxxxx
> >>> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >> _______________________________________________
> >> Ethereal-dev mailing list
> >> Ethereal-dev@xxxxxxxxxxxx
> >> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >>
> >>
> >> _______________________________________________
> >> Ethereal-dev mailing list
> >> Ethereal-dev@xxxxxxxxxxxx
> >> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >>
> >
> >
> > --
> > This information is top security. When you have read it, destroy yourself.
> > -- Marshall McLuhan
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
