On 2/22/06, Roger Mahler <roger.mahler@xxxxxxx> wrote:
> > RNSAP does not yet register to SCCP.
> How do you identify RANAP today?
Either because it uses a well known SSN (0x8e) or heuristically by
means of the lenght being right and the opcode (the heuristics fail
sometimes to get ranap packets and sometimes they might interpret as
ranap things that aren't realy ranap, that's heuristic isn't it :-).
> Why can I not force Ethereal to decode RNSAP _unconditionally_ on top of
> SCCP (I thought this is the purpose of these USER DLT, but how?)
Because sccp does not know (yet) even that RNSAP exists . In order to
do so the RNSAP dissector has to register to use an SCCP SSN (don't
worry I'll add it soon).
Even at that point not everything is solved, A problem is that the SSN
appears only in the setup packets of the SCCP "call" so unless your
capture contains these two messages SCCP will try to guess If the
payload is unknown. Theres no heuristics for RNSAP (I don't even know
if some reliable method to guess RNSAP exists, so it's not possible
for me to write it).
User DLT was born with no purpose other than helping me write the K12
rf5 file import. Even if the k12 code did not needed it once finished,
It turned out handy, so I packet it and left it there.
What it does is it takes a USER_DLT (unassigned PCAP encasulation
type) and maps it to an arbitrary protocol optionaly removing some
bytes before and some after. If you have a file that uses one of this
encapsulation types (usually a node's log passed through text2pcap) it
allows you to decode the payloadof the frames.
>
> I see 3 possibilities:
>
> Solution 1
> Both RANAP and RNSAP subscribe to SCCP. The user shall have the chance to
> decide which of the two is chosen on top of SCCP. This then would decode the
> correctly chosen frames error free and the wrongly chosen frames (most
> likely) with errors. This works fine for every frame (also if no CR/CC is
> present).
Very Ugly.
> Solution 2
> Both RANAP and RNSAP subscribe to SCCP. The decision whether to load the one
> or the other shall be based on the SSN from the CR message and all
> subsequent CC, DT1, RLSD, RLC within the same <SLR,DLR> shall be treated
> alike.
This one is neat and feasable.
> The problem just remains: What if the SSN is the same (for both RANAP and
> RNSAP). Is that possible? I think so. But then we still have solution 1.
While over a certain association (DPC-OPC) there should be no more
than one SSN per application. There could be someone tat uses the same
ssn for different applications,
However good practice is to use different SSNs for different
Applications even over different associations.
If you find something like that in the field make sure the System
Engineer is transfered to marketing before he causes more damage!!!
:-)
Solution 1 is ugly!
A Protocol preference in RNSAP for telling which SSN to use is a must!
So we go with 2.
As per the heuristics do you have an Idea on how we can guess if
something is RNSAP and not something else?
> Solution 3
> Make a protocol discriminator based on the <opc,dpc> from the SCCP Routing
> Label, but this might be a configuration nightmare. This is by the way
> exactly what the Network Elements are doing (i.e. the MGW)
I think the MGW is at most an STP for RNSAP messages, AFAIK in most
cases the IuR is cross-connected via ATM and as such completely
transparent to the MGw which works only as an ATM switch.
> In my attachment there is 1 IuCS transaction and 1 Iur transaction.
> For IuCS RANAP is used when SSN=142 (frame 1)
> For Iur RNSAP is used when SSN=143 (frame 12)
> If you are interested in Solution 3:
> PCs starting with 3 are RNCs,
> 2107 is the MGC
MGC in regard of the MGw only, MSC for the RNCs I guess.
>
> Any finally: The RNSAP messages are segmented over several DT1 frames
> (frames 16,17,18,19)
Thanks I'll take a look at this.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
