["Graeme Lunt" <graeme.lunt@xxxxxxxxx>]

Anders,

> >The ACSE dissector seems to keep track of the ACSE OIDS not the 
> >presentation context OIDs (it doesn't have access to that 
> information).
> Yes.
>  What I was traying to say was that the second "PC" of Frame 89 
> "register_ber_oid_name("2.9.1.1.4","joint-iso-itu-t(2) ms(9) 
> cmip(1) cmip-pci(1) abstractSyntax(4)");"
> sort of corresonds to the "aso-context-name (2.9.0.0.2 
> "CMIP") of the ASCE part of the message.

I see what you are saying and we are agreeing. But in general there
may be multiple PCs (in addition to ACSE) that map to the same AC.

Here is a dump from my P1 associate:

ISO 8823 OSI Presentation Protocol
    PPDU Type: Connection request/confirm PDU (49)
    Message Length: 122
    Mode Selector
        Mode selector: 160
        Length:3
        Integer
    Sequence
        Sequence: 162
        Length:115
        Presentation context definition list
            Sequence
                Presentation context identifier
                    01
                Abstract syntax name
                    Value: 2.2.1.0.1 (joint-iso-ccitt.2.1.0.1)
                Transfer syntax names
                    Value: 2.1.1 (joint-iso-ccitt.1.1)
            Sequence
                Presentation context identifier
                    03
                Abstract syntax name
                    Value: 2.6.0.2.12 (joint-iso-ccitt.6.0.2.12)
                Transfer syntax names
                    Value: 2.1.1 (joint-iso-ccitt.1.1)
            Sequence
                Presentation context identifier
                    05
                Abstract syntax name
                    Value: 2.6.0.2.7 (joint-iso-ccitt.6.0.2.7)
                Transfer syntax names
                    Value: 2.1.1 (joint-iso-ccitt.1.1)
        User data
            Fully encoded data 
                Sequence
                    Presentation context identifier
                        01
                    Single ASN.1 type
                        User data
ACSE
    aarq
        aSO-context-name: 2.6.0.1.6
        user-information: 1 item

There are two PC (2.6.0.2.12 and 2.6.0.2.7) (in addition ACSE) that map to
the one AC (2.6.0.1.6). 
X.400 P7 and P3 protocols have 4 PCs in addition to ACSE. The dissectors
must be able to handle this.
So dissection must be based on PC (the AC does not aid dissection). 

Note the dump above also shows that the ACSE dissector should register
itself is ACSE syntax (2.2.1.0.1) dissector.
The presentation dissector should then use the PCI in the "User data" (1) to
lookup the ACSE AS oid (2.2.1.0.1) and then call call_ber_oid_callback().
This way the presentation dissector does not explicitly know about the acse
dissector. 
I don't think you are ever forced to use ACSE in an application protocol?

> Looking at the current trace the only way to know if it's a 
> PC or an AC is to analyse the OID - correct?

They are both presentation contexts. 
The AC comes from ACSE (the "aSO-context-name") in my dump above.

> I think the OID registration should be done by the dissector 
> "owning" that OID 

I agree.

> e.g RTSE in this case.

But in this case the OID is "owned" by X.400 (P1) and hence why the
registration is done here.
There are other PCs that use RTSE - depending on the application. RTSE could
register itself on all of  
them that it knows about but I think it is clearer to put it in the ultimate
application dissector handoff.

> Currently there might a problem here as we don't distiguish 
> between PER and BER in the OID tables in
> practice we don't have any example of a protocol beeing 
> encoded in both PER and BER (yet).

Yes - I'd seen that too and sort of skipped past it.

> >I think there should also be a registration/dispatch for 
> ACSE on the acse
> >presentation context (in the acse handoff), 
> >but I haven't investigated that yet. 
> 
> Yes

Well, the dump I above helped make this clearer to me.

> >This can lead to multiple dissectors being registered on the 
> same PC (OID) -
> >so I now have 
> >register_rtse_oid_dissector() and 
> register_ros_oid_dissector() to enable the
> >dissection of each wrapper based on the same PC.
> 
> I'm not shure I follow you here, using the example abowe a 
> way to do dissection would be:
> Register resentation-context-identifier: 1 to the OID of ASCE
> Register resentation-context-identifier: 3 to the OID 2.9.1.1.4
>  call oid dissector of PCI 1

The issue here is that ACSE, RTSE and ROS will all use the same PC (OID) to 
call sub-dissectors for User Data (EXTERNALs) they find. 
This can't be handled with register_ber_oid_dissector() as each dissector
registration will override the last. 
So each service element needs its own hash table (though ACSE can probably
use the BER hash table).

So for the P1 PC (2.6.0.2.12) I would have something like in the X411
handoff:

/* the ACSE dissector has self-registered and uses the BER callback list
like : */
/* register_ber_oid_dissector("2.2.1.0.1", dissect_acse, proto_acse,
"id-as-acse"); */

register_ACSE_oid_dissector("2.6.0.2.12", dissect_rtse, proto_rtse,
"id-as-mta-rtse");
register_RTSE_oid_dissector("2.6.0.2.12", dissect_ros, proto_ros,
"id-as-mta-rtse");
register_ROS_oid_dissector("2.6.0.2.12", dissect_x411, proto_x411,
"id-as-mta-rtse");

This way each service element can dispatch using the same PC.

And then if the application protocol just uses ROS (i.e. no RTSE) (e.g.
CMIP) you can do:

register_ACSE_oid_dissector("2.9.1.1.4", dissect_ros, proto_rtse,
"id-as-cmip");
register_ROS_oid_dissector("2.9.1.1.4", dissect_cmip, proto_cmip,
"id-as-cmip");

Is this making any sense?

Graeme