[Debian-med-packaging] Bug#716971: pixelmed-java: Incorrect handling of C-ECHO-RQ

[Mathieu Malaterre]

Package: pixelmed-java
Version: 20100617-1
Severity: normal

Right now pixelmed has an incorrect behavior for C-ECHO-RQ. When one send:

D: ====================== BEGIN A-ASSOCIATE-RQ =====================
D: Our Implementation Class UID:      
D: Our Implementation Version Name:   
D: Their Implementation Class UID:    
D: Their Implementation Version Name: 
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    AWSPIXELMEDPUB  
D: Called Application Name:     GDCMDASH        
D: Responding Application Name: 
D: Our Max PDU Receive Size:    
D: Their Max PDU Receive Size:  
D: Presentation Contexts:
D:   Context ID:        1 (Proposed)
D:     Abstract Syntax: =1.2.840.10008.1.1
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =1.2.840.10008.1.2.4.95
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation:  none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response:  none
D: ======================= END A-ASSOCIATE-RQ ======================

pixelmed simply goes one and answer:

D: ====================== BEGIN A-ASSOCIATE-AC =====================
D: Our Implementation Class UID:      
D: Our Implementation Version Name:   
D: Their Implementation Class UID:    
D: Their Implementation Version Name: 
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    GDCMDASH        
D: Called Application Name:     AWSPIXELMEDPUB  
D: Responding Application Name: 
D: Our Max PDU Receive Size:    
D: Their Max PDU Receive Size:  
D: Presentation Contexts:
D:   Context ID:        1 (transfer-syntaxes-not-supported (provider rejection))
D:       =[field shall not be significant]
D: Requested Extended Negotiation: 
D: Accepted Extended Negotiation:  
D: Requested User Identity Negotiation: 
D: User Identity Negotiation Response:  
D: ======================= END A-ASSOCIATE-AC ======================


which eventually ends up with:

(0000,0000) ?? (UL) 66                                            # 4,1 Command Group Length
(0000,0002) ?? (UI) [1.2.840.10008.1.1]                           # 18,1 Affected SOP Class UID
(0000,0100) ?? (US) 32816                                         # 2,1 Command Field
(0000,0120) ?? (US) 1                                             # 2,1 Message ID Being Responded To
(0000,0800) ?? (US) 257                                           # 2,1 Data Set Type
(0000,0900) ?? (US) 0                                             # 2,1 Status


Thus it is impossible to detect the error from a user prospective.

Thanks for fixing handling of this broken behavior (no SCU should be sending this, but SCP should be able to report the error).

DVTk nicely handles that right after the -RQ:

Result: rejected-permanent
Source: DICOM UL service-provider (ACSE related function)
Reason: 1 - no-reason-given