Hi
> RNSAP does not yet register to SCCP.
> The sample you sent unfortunatelly does not have the CR/CC pair in
> which conveys information regarding the user. So that would not be
> decoded even if RNSAP registered to SCCP. I don't know whether there
> is a good way to (heuristically) identify RNSAP.
How do you identify RANAP today?
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?)
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).
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.
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.
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)
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
Any finally: The RNSAP messages are segmented over several DT1 frames
(frames 16,17,18,19)
/Roger
--
DSL-Aktion wegen gro�er Nachfrage bis 28.2.2006 verl�ngert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
Attachment:
1xIuCS_1xIur.cap
Description: Binary data