Problem reading the Content Sequence tag of DICOM file using DCMTK - dicom
Using DCMTK, I am trying to get the entire node of Content Sequence of .dcm SR files to extract measurements related to obstetrical scans. I use C-Find query. I am able to get the entire Content Sequence with Toshiba ultrasound machine but not with other brands. I don't think that this is a brand issue but the way I have set up the C-Find process. I am very new to this and am struggling to resolve the issue. I have included 2 log files below: one for the working case that successfully gets the entire node of Content Sequence tag, and another log for the non-working case that stops the process with an error "DIMSE Status: 0xc000: Error: Failed - Unable to process error". I appreciate any help or your insightful advice.
This the log for the non-working query
D: Request Parameters:
D: ====================== BEGIN A-ASSOCIATE-RQ =====================
D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.5
D: Our Implementation Version Name: OFFIS_DCMTK_365
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: KATIBA
D: Called Application Name: ORTHANC
D: Responding Application Name: ORTHANC
D: Our Max PDU Receive Size: 16384
D: Their Max PDU Receive Size: 0
D: Presentation Contexts:
D: Context ID: 1 (Proposed)
D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
D: Proposed SCP/SCU Role: Default
D: Proposed Transfer Syntax(es):
D: =LittleEndianExplicit
D: =BigEndianExplicit
D: =LittleEndianImplicit
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 ======================
I: Requesting Association
T: DUL FSM Table: State: 1 Event: 0
T: DUL Event: A-ASSOCIATE request (local user)
T: DUL Action: AE 1 Transport Connect
D: setting network send timeout to 60 seconds
D: setting network receive timeout to 60 seconds
T: checking whether environment variable TCP_BUFFER_LENGTH is set
T: environment variable TCP_BUFFER_LENGTH not set, using the system defaults
T: checking whether environment variable TCP_NODELAY is set
T: environment variable TCP_NODELAY not set, using the default value (0)
T: DUL FSM Table: State: 4 Event: 1
T: DUL Event: Transport conn confirmation (local)
T: DUL Action: AE 2 Send Associate RQ PDU
D: Constructing Associate RQ PDU
T: setting timeout for first PDU to be read to 30 seconds
T: Read PDU HEAD TCP: 02 00 00 00 00 ba
T: Read PDU HEAD TCP: type: 02, length: 186 (ba)
T: DUL FSM Table: State: 5 Event: 2
T: DUL Event: A-ASSOCIATE-AC PDU (on transport)
T: DUL Action: AE 3 Associate Confirmation Accept
D: PDU Type: Associate Accept, PDU Length: 186 + 6 bytes PDU header
D: 02 00 00 00 00 ba 00 01 00 00 4f 52 54 48 41 4e
D: 43 20 20 20 20 20 20 20 20 20 4b 41 54 49 42 41
D: 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00
D: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D: 00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
D: 32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
D: 31 2e 31 21 00 00 1b 01 00 00 00 40 00 00 13 31
D: 2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32
D: 2e 31 50 00 00 3a 51 00 00 04 00 00 40 00 52 00
D: 00 1b 31 2e 32 2e 32 37 36 2e 30 2e 37 32 33 30
D: 30 31 30 2e 33 2e 30 2e 33 2e 36 2e 34 55 00 00
D: 0f 4f 46 46 49 53 5f 44 43 4d 54 4b 5f 33 36 34
D:
D: Parsing an A-ASSOCIATE PDU
T: PDU type: 2 (A-ASSOCIATE AC), PDU Length: 186
T: DICOM Protocol: 1
T: Called AP Title: ORTHANC
T: Calling AP Title: KATIBA
T: Parsing remaining 118 bytes of A-ASSOCIATE PDU
T: Next item type: 10
T: Subitem parse: Type 10, Length 0021, Content: 1.2.840.10008.3.1.1.1
T: Successfully parsed Application Context
T: Parsing remaining 93 bytes of A-ASSOCIATE PDU
T: Next item type: 21
T: Parsing Presentation Context: (21), Length: 27
T: Presentation Context ID: 01
T: Parsing remaining 23 bytes of Presentation Context
T: Next item type: 40
T: Subitem parse: Type 40, Length 0019, Content: 1.2.840.10008.1.2.1
T: Successfully parsed Transfer Syntax
T: Successfully parsed Presentation Context
T: Parsing remaining 62 bytes of A-ASSOCIATE PDU
T: Next item type: 50
T: Parsing user info field (50), Length: 58
T: Parsing remaining 58 bytes of User Information
T: Next item type: 51
T: Maximum PDU Length: 16384
T: Successfully parsed Maximum PDU Length
T: Parsing remaining 50 bytes of User Information
T: Next item type: 52
T: Subitem parse: Type 52, Length 0027, Content: 1.2.276.0.7230010.3.0.3.6.4
T: Parsing remaining 19 bytes of User Information
T: Next item type: 55
T: Subitem parse: Type 55, Length 0015, Content: OFFIS_DCMTK_364
T: Successfully parsed User Information
D: Association Parameters Negotiated:
D: ====================== BEGIN A-ASSOCIATE-AC =====================
D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.5
D: Our Implementation Version Name: OFFIS_DCMTK_365
D: Their Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.4
D: Their Implementation Version Name: OFFIS_DCMTK_364
D: Application Context Name: 1.2.840.10008.3.1.1.1
D: Calling Application Name: KATIBA
D: Called Application Name: ORTHANC
D: Responding Application Name: ORTHANC
D: Our Max PDU Receive Size: 16384
D: Their Max PDU Receive Size: 16384
D: Presentation Contexts:
D: Context ID: 1 (Accepted)
D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
D: Proposed SCP/SCU Role: Default
D: Accepted SCP/SCU Role: Default
D: Accepted Transfer Syntax: =LittleEndianExplicit
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-AC ======================
I: Association Accepted (Max Send PDV: 16372)
I: Sending Find Request
D: ===================== OUTGOING DIMSE MESSAGE ====================
D: Message Type : C-FIND RQ
D: Presentation Context ID : 1
D: Message ID : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : present
D: Priority : medium
D: ======================= END DIMSE MESSAGE =======================
I: Request Identifiers:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0016) UI (no value available) # 0, 0 SOPClassUID
I: (0008,0018) UI (no value available) # 0, 0 SOPInstanceUID
I: (0008,0020) DA [20210218-] # 10, 1 StudyDate
I: (0008,0021) DA [20210218-] # 10, 1 SeriesDate
I: (0008,0030) TM [0000-2359] # 10, 1 StudyTime
I: (0008,0031) TM [0000-2359] # 10, 1 SeriesTime
I: (0008,0050) SH (no value available) # 0, 0 AccessionNumber
I: (0008,0052) CS [SERIES] # 6, 1 QueryRetrieveLevel
I: (0008,0061) CS [SR] # 2, 1 ModalitiesInStudy
I: (0008,0070) LO (no value available) # 0, 0 Manufacturer
I: (0008,0080) LO (no value available) # 0, 0 InstitutionName
I: (0008,0090) PN (no value available) # 0, 0 ReferringPhysicianName
I: (0008,1030) LO (no value available) # 0, 0 StudyDescription
I: (0008,103e) LO (no value available) # 0, 0 SeriesDescription
I: (0008,1040) LO (no value available) # 0, 0 InstitutionalDepartmentName
I: (0008,1048) PN (no value available) # 0, 0 PhysiciansOfRecord
I: (0010,0010) PN (no value available) # 0, 0 PatientName
I: (0010,0020) LO [200167394] # 10, 1 PatientID
I: (0010,0030) DA (no value available) # 0, 0 PatientBirthDate
I: (0010,0040) CS (no value available) # 0, 0 PatientSex
I: (0010,1010) AS (no value available) # 0, 0 PatientAge
I: (0010,21b0) LT (no value available) # 0, 0 AdditionalPatientHistory
I: (0020,000d) UI (no value available) # 0, 0 StudyInstanceUID
I: (0020,0010) SH (no value available) # 0, 0 StudyID
I: (0032,1032) PN (no value available) # 0, 0 RequestingPhysician
I: (0040,a730) SQ (Sequence with explicit length #=0) # 0, 1 ContentSequence
I: (fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
I:
T: DcmItem::insert() Element (0000,0000) VR="UL" inserted at beginning
T: DcmItem::insert() Element (0000,0100) VR="US" inserted
T: DcmItem::insert() Element (0000,0110) VR="US" inserted
T: DcmItem::insert() Element (0000,0800) VR="US" inserted
T: DcmItem::insert() Element (0000,0002) VR="UI" inserted
T: DcmItem::insert() Element (0000,0700) VR="US" inserted
T: DIMSE Command to be sent on Presentation Context ID: 1
T: DIMSE Command to send:
T:
T: # Dicom-Data-Set
T: # Used TransferSyntax: Little Endian Explicit
T: (0000,0000) UL 0 # 4, 1 CommandGroupLength
T: (0000,0002) UI =FINDStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
T: (0000,0100) US 32 # 2, 1 CommandField
T: (0000,0110) US 1 # 2, 1 MessageID
T: (0000,0700) US 0 # 2, 1 Priority
T: (0000,0800) US 1 # 2, 1 CommandDataSetType
T:
T: DIMSE sendDcmDataset: sending 88 bytes
T: DUL FSM Table: State: 6 Event: 8
T: DUL Event: P-DATA request primitive
T: DUL Action: DT 1 Send P DATA PDU
T: DIMSE sendDcmDataset: sending 270 bytes
T: DUL FSM Table: State: 6 Event: 8
T: DUL Event: P-DATA request primitive
T: DUL Action: DT 1 Send P DATA PDU
T: DIMSE receiveCommand
T: Read PDU HEAD TCP: 04 00 00 00 00 5e
T: Read PDU HEAD TCP: type: 04, length: 94 (5e)
T: DUL FSM Table: State: 6 Event: 9
T: DUL Event: P-DATA-TF PDU (on transport)
T: DUL Action: DT 2 Indicate P DATA PDU Received
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
T: DcmItem::insert() Element (0000,0000) VR="UL" inserted at beginning
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0002) VR="UI" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0100) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0120) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0800) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0900) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::read() returns error = Normal
T: DcmDataset::read() returns error = Normal
T: DIMSE receiveCommand: 1 PDVs (88 bytes), PresID=1
T: DIMSE Command Received:
T:
T: # Dicom-Data-Set
T: # Used TransferSyntax: Little Endian Implicit
T: (0000,0002) UI =FINDStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
T: (0000,0100) US 32800 # 2, 1 CommandField
T: (0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo
T: (0000,0800) US 257 # 2, 1 CommandDataSetType
T: (0000,0900) US 49152 # 2, 1 Status
T:
T: DcmItem::searchSubFromHere() Element (0000,0100) found
T: DcmItem::searchSubFromHere() Element (0000,0100) found
T: DcmItem::searchSubFromHere() Element (0000,0120) found
T: DcmItem::searchSubFromHere() Element (0000,0800) found
T: DcmItem::searchSubFromHere() Element (0000,0900) found
T: DcmItem::searchSubFromHere() Element (0000,0002) found
I: Received Final Find Response
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type : C-FIND RSP
D: Message ID Being Responded To : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : none
D: DIMSE Status : 0xc000: Error: Failed - Unable to process
D: ======================= END DIMSE MESSAGE =======================
I: Releasing Association
T: DUL FSM Table: State: 6 Event: 10
T: DUL Event: A-RELEASE request primitive
T: DUL Action: AR 1 Send Release RQ
T: Read PDU HEAD TCP: 06 00 00 00 00 04
T: Read PDU HEAD TCP: type: 06, length: 4 (04)
T: DUL FSM Table: State: 7 Event: 12
T: DUL Event: A-RELEASE-RP PDU (on transport)
T: DUL Action: AR 3 Confirm Release
And this is the log for the working query:
D: Request Parameters:
D: ====================== BEGIN A-ASSOCIATE-RQ =====================
D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.5
D: Our Implementation Version Name: OFFIS_DCMTK_365
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: KATIBA
D: Called Application Name: ORTHANC
D: Responding Application Name: ORTHANC
D: Our Max PDU Receive Size: 16384
D: Their Max PDU Receive Size: 0
D: Presentation Contexts:
D: Context ID: 1 (Proposed)
D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
D: Proposed SCP/SCU Role: Default
D: Proposed Transfer Syntax(es):
D: =LittleEndianExplicit
D: =BigEndianExplicit
D: =LittleEndianImplicit
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 ======================
I: Requesting Association
T: DUL FSM Table: State: 1 Event: 0
T: DUL Event: A-ASSOCIATE request (local user)
T: DUL Action: AE 1 Transport Connect
D: setting network send timeout to 60 seconds
D: setting network receive timeout to 60 seconds
T: checking whether environment variable TCP_BUFFER_LENGTH is set
T: environment variable TCP_BUFFER_LENGTH not set, using the system defaults
T: checking whether environment variable TCP_NODELAY is set
T: environment variable TCP_NODELAY not set, using the default value (0)
T: DUL FSM Table: State: 4 Event: 1
T: DUL Event: Transport conn confirmation (local)
T: DUL Action: AE 2 Send Associate RQ PDU
D: Constructing Associate RQ PDU
T: setting timeout for first PDU to be read to 30 seconds
T: Read PDU HEAD TCP: 02 00 00 00 00 ba
T: Read PDU HEAD TCP: type: 02, length: 186 (ba)
T: DUL FSM Table: State: 5 Event: 2
T: DUL Event: A-ASSOCIATE-AC PDU (on transport)
T: DUL Action: AE 3 Associate Confirmation Accept
D: PDU Type: Associate Accept, PDU Length: 186 + 6 bytes PDU header
D: 02 00 00 00 00 ba 00 01 00 00 4f 52 54 48 41 4e
D: 43 20 20 20 20 20 20 20 20 20 4b 41 54 49 42 41
D: 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00
D: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D: 00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
D: 32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
D: 31 2e 31 21 00 00 1b 01 00 00 00 40 00 00 13 31
D: 2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32
D: 2e 31 50 00 00 3a 51 00 00 04 00 00 40 00 52 00
D: 00 1b 31 2e 32 2e 32 37 36 2e 30 2e 37 32 33 30
D: 30 31 30 2e 33 2e 30 2e 33 2e 36 2e 34 55 00 00
D: 0f 4f 46 46 49 53 5f 44 43 4d 54 4b 5f 33 36 34
D:
D: Parsing an A-ASSOCIATE PDU
T: PDU type: 2 (A-ASSOCIATE AC), PDU Length: 186
T: DICOM Protocol: 1
T: Called AP Title: ORTHANC
T: Calling AP Title: KATIBA
T: Parsing remaining 118 bytes of A-ASSOCIATE PDU
T: Next item type: 10
T: Subitem parse: Type 10, Length 0021, Content: 1.2.840.10008.3.1.1.1
T: Successfully parsed Application Context
T: Parsing remaining 93 bytes of A-ASSOCIATE PDU
T: Next item type: 21
T: Parsing Presentation Context: (21), Length: 27
T: Presentation Context ID: 01
T: Parsing remaining 23 bytes of Presentation Context
T: Next item type: 40
T: Subitem parse: Type 40, Length 0019, Content: 1.2.840.10008.1.2.1
T: Successfully parsed Transfer Syntax
T: Successfully parsed Presentation Context
T: Parsing remaining 62 bytes of A-ASSOCIATE PDU
T: Next item type: 50
T: Parsing user info field (50), Length: 58
T: Parsing remaining 58 bytes of User Information
T: Next item type: 51
T: Maximum PDU Length: 16384
T: Successfully parsed Maximum PDU Length
T: Parsing remaining 50 bytes of User Information
T: Next item type: 52
T: Subitem parse: Type 52, Length 0027, Content: 1.2.276.0.7230010.3.0.3.6.4
T: Parsing remaining 19 bytes of User Information
T: Next item type: 55
T: Subitem parse: Type 55, Length 0015, Content: OFFIS_DCMTK_364
T: Successfully parsed User Information
D: Association Parameters Negotiated:
D: ====================== BEGIN A-ASSOCIATE-AC =====================
D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.5
D: Our Implementation Version Name: OFFIS_DCMTK_365
D: Their Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.4
D: Their Implementation Version Name: OFFIS_DCMTK_364
D: Application Context Name: 1.2.840.10008.3.1.1.1
D: Calling Application Name: KATIBA
D: Called Application Name: ORTHANC
D: Responding Application Name: ORTHANC
D: Our Max PDU Receive Size: 16384
D: Their Max PDU Receive Size: 16384
D: Presentation Contexts:
D: Context ID: 1 (Accepted)
D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
D: Proposed SCP/SCU Role: Default
D: Accepted SCP/SCU Role: Default
D: Accepted Transfer Syntax: =LittleEndianExplicit
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-AC ======================
I: Association Accepted (Max Send PDV: 16372)
I: Sending Find Request
D: ===================== OUTGOING DIMSE MESSAGE ====================
D: Message Type : C-FIND RQ
D: Presentation Context ID : 1
D: Message ID : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : present
D: Priority : medium
D: ======================= END DIMSE MESSAGE =======================
I: Request Identifiers:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0016) UI (no value available) # 0, 0 SOPClassUID
I: (0008,0018) UI (no value available) # 0, 0 SOPInstanceUID
I: (0008,0020) DA [20210218-] # 10, 1 StudyDate
I: (0008,0021) DA [20210218-] # 10, 1 SeriesDate
I: (0008,0030) TM [0000-2359] # 10, 1 StudyTime
I: (0008,0031) TM [0000-2359] # 10, 1 SeriesTime
I: (0008,0050) SH (no value available) # 0, 0 AccessionNumber
I: (0008,0052) CS [SERIES] # 6, 1 QueryRetrieveLevel
I: (0008,0061) CS [SR] # 2, 1 ModalitiesInStudy
I: (0008,0070) LO (no value available) # 0, 0 Manufacturer
I: (0008,0080) LO (no value available) # 0, 0 InstitutionName
I: (0008,0090) PN (no value available) # 0, 0 ReferringPhysicianName
I: (0008,1030) LO (no value available) # 0, 0 StudyDescription
I: (0008,103e) LO (no value available) # 0, 0 SeriesDescription
I: (0008,1040) LO (no value available) # 0, 0 InstitutionalDepartmentName
I: (0008,1048) PN (no value available) # 0, 0 PhysiciansOfRecord
I: (0010,0010) PN (no value available) # 0, 0 PatientName
I: (0010,0020) LO [01TEST12] # 8, 1 PatientID
I: (0010,0030) DA (no value available) # 0, 0 PatientBirthDate
I: (0010,0040) CS (no value available) # 0, 0 PatientSex
I: (0010,1010) AS (no value available) # 0, 0 PatientAge
I: (0010,21b0) LT (no value available) # 0, 0 AdditionalPatientHistory
I: (0020,000d) UI (no value available) # 0, 0 StudyInstanceUID
I: (0020,0010) SH (no value available) # 0, 0 StudyID
I: (0032,1032) PN (no value available) # 0, 0 RequestingPhysician
I: (0040,a730) SQ (Sequence with explicit length #=0) # 0, 1 ContentSequence
I: (fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
I:
T: DcmItem::insert() Element (0000,0000) VR="UL" inserted at beginning
T: DcmItem::insert() Element (0000,0100) VR="US" inserted
T: DcmItem::insert() Element (0000,0110) VR="US" inserted
T: DcmItem::insert() Element (0000,0800) VR="US" inserted
T: DcmItem::insert() Element (0000,0002) VR="UI" inserted
T: DcmItem::insert() Element (0000,0700) VR="US" inserted
T: DIMSE Command to be sent on Presentation Context ID: 1
T: DIMSE Command to send:
T:
T: # Dicom-Data-Set
T: # Used TransferSyntax: Little Endian Explicit
T: (0000,0000) UL 0 # 4, 1 CommandGroupLength
T: (0000,0002) UI =FINDStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
T: (0000,0100) US 32 # 2, 1 CommandField
T: (0000,0110) US 1 # 2, 1 MessageID
T: (0000,0700) US 0 # 2, 1 Priority
T: (0000,0800) US 1 # 2, 1 CommandDataSetType
T:
T: DIMSE sendDcmDataset: sending 88 bytes
T: DUL FSM Table: State: 6 Event: 8
T: DUL Event: P-DATA request primitive
T: DUL Action: DT 1 Send P DATA PDU
T: DIMSE sendDcmDataset: sending 268 bytes
T: DUL FSM Table: State: 6 Event: 8
T: DUL Event: P-DATA request primitive
T: DUL Action: DT 1 Send P DATA PDU
T: DIMSE receiveCommand
T: Read PDU HEAD TCP: 04 00 00 00 00 5e
T: Read PDU HEAD TCP: type: 04, length: 94 (5e)
T: DUL FSM Table: State: 6 Event: 9
T: DUL Event: P-DATA-TF PDU (on transport)
T: DUL Action: DT 2 Indicate P DATA PDU Received
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
T: DcmItem::insert() Element (0000,0000) VR="UL" inserted at beginning
T: DcmItem::readSubItem() returns error = Normal
T: DcmDataset::read() returns error = Normal
T: DIMSE receiveCommand: 1 PDVs (88 bytes), PresID=1
T: DIMSE Command Received:
T:
T: # Dicom-Data-Set
T: # Used TransferSyntax: Little Endian Implicit
T: (0000,0002) UI =FINDStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
T: (0000,0100) US 32800 # 2, 1 CommandField
T: (0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo
T: (0000,0800) US 1 # 2, 1 CommandDataSetType
T: (0000,0900) US 65280 # 2, 1 Status
T:
T: DcmItem::searchSubFromHere() Element (0000,0100) found
T: DcmItem::searchSubFromHere() Element (0000,0100) found
T: DcmItem::searchSubFromHere() Element (0000,0120) found
T: DcmItem::searchSubFromHere() Element (0000,0800) found
T: DcmItem::searchSubFromHere() Element (0000,0900) found
T: DcmItem::searchSubFromHere() Element (0000,0002) found
T: Read PDU HEAD TCP: 04 00 00 00 3f f8
T: Read PDU HEAD TCP: type: 04, length: 16376 (3ff8)
T: DUL FSM Table: State: 6 Event: 9
T: DUL Event: P-DATA-TF PDU (on transport)
T: DUL Action: DT 2 Indicate P DATA PDU Received
D: DcmDataset::read() TransferSyntax="Little Endian Explicit"
T: DcmSequenceOfItems::read() returns error = Normal
T: DcmItem::insert() Element (0040,a043) VR="SQ" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DIMSE receiveDataSetInMemory: 11642 bytes read (last: YES)
T: DcmItem::searchSubFromHere() Element (0008,0018) found
T: DcmItem::searchSubFromHere() Element (0008,0016) found
T: DcmItem::searchSubFromHere() Element (0040,a730) found
T: DcmItem::searchSubFromHere() Element (0040,a010) found
T: DcmItem::searchSubFromHere() Element (0040,a040) found
T: DcmItem::searchSubFromHere() Element (0040,a043) found
//more truncated repetitive log
T: DIMSE receiveCommand
T: Read PDU HEAD TCP: 04 00 00 00 00 5e
T: Read PDU HEAD TCP: type: 04, length: 94 (5e)
T: DUL FSM Table: State: 6 Event: 9
T: DUL Event: P-DATA-TF PDU (on transport)
T: DUL Action: DT 2 Indicate P DATA PDU Received
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
T: DcmItem::insert() Element (0000,0000) VR="UL" inserted at beginning
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0002) VR="UI" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0100) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0120) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0800) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::insert() Element (0000,0900) VR="US" inserted
T: DcmItem::readSubItem() returns error = Normal
T: DcmItem::read() returns error = Normal
T: DcmDataset::read() returns error = Normal
T: DIMSE receiveCommand: 1 PDVs (88 bytes), PresID=1
T: DIMSE Command Received:
T:
T: # Dicom-Data-Set
T: # Used TransferSyntax: Little Endian Implicit
T: (0000,0002) UI =FINDStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
T: (0000,0100) US 32800 # 2, 1 CommandField
T: (0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo
T: (0000,0800) US 257 # 2, 1 CommandDataSetType
T: (0000,0900) US 0 # 2, 1 Status
T:
T: DcmItem::searchSubFromHere() Element (0000,0100) found
T: DcmItem::searchSubFromHere() Element (0000,0100) found
T: DcmItem::searchSubFromHere() Element (0000,0120) found
T: DcmItem::searchSubFromHere() Element (0000,0800) found
T: DcmItem::searchSubFromHere() Element (0000,0900) found
T: DcmItem::searchSubFromHere() Element (0000,0002) found
I: Received Final Find Response
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type : C-FIND RSP
D: Message ID Being Responded To : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : none
D: DIMSE Status : 0x0000: Success
D: ======================= END DIMSE MESSAGE =======================
I: Releasing Association
Your requests only differ in that your non-working query queries for a different patient ID.
An obvious mistake in both queries is that for a SERIES-level request in STUDY-ROOT, you must not include a value for the Patient ID, but for the Study Instance UID. This is wrong in terms of DICOM, but Orthanc seems to be capable of handling it in general. This is however the only hint that I can obtain from your logs, so I would give it a try.
Please note, that the Content Sequence is not a mandatory Return Key for the C-FIND, so you can never rely on the SCP supporting it.
Related
Parsing bytes as BCD with Indy C++ Builder
I am trying to parse the length of a message received. The length is in BCD. When I use ReadSmallInt(), I get a reading interpreted as a hex value, not as BCD. So, if I have a message like this: 00 84 60 00 00 00 19 02 10 70 38 00 00 0E C0 00 00 16 45 93 56 00 01 79 16 62 00 00 00 00 00 00 08 00 00 00 00 02 10 43 02 04 02 35 31 35 31 35 31 35 31 35 31 35 31 53 41 4C 45 35 31 30 30 31 32 33 34 35 36 37 38 31 32 33 34 35 36 37 38 39 30 31 32 33 I am expecting ReadSmallInt() to return 84, but instead it is returning 132, which is correct if you are reading a hex value instead of a BCD one. According to this answer, ReadSmallInt() reads BCD, as in the examples it gets 11 and 13 (BCD) as lengths instead of 17 and 19 (hex). I have fixed this with duct tape, but is there a more elegant way? int calculated_length; // getting the length in Hexa calculated_length = AContext->Connection->IOHandler->ReadSmallInt(); // converting from hex binary to hex string UnicodeString bcdLength = UnicodeString().sprintf(L"%04x", calculated_length); // converting from hex string to int calculated_length = bcdLength.ToInt(); ucBuffer.Length = calculated_length -2; AContext->Connection->IOHandler->ReadBytes(ucBuffer, calculated_length - 2);
According to this answer, ReadSmallInt reads BCD
That is incorrect. You have misinterpreted what that answer is saying. NOTHING in that answer indicates that ReadSmallInt() reads in a Binary Coded Decimal, because it doesn't, as Indy DOES NOT support reading/writing BCDs at all. ReadSmallInt() simply reads in 2 bytes and returns them as-is as a 16-bit decimal integer (swapping the byte order, if needed). So, if you need to read in a BCD instead, you will have to read in the bytes and then parse them yourself. Or find a BCD library to handle it for you.
If you re-read that other question again more carefully, in the 2 examples it gives:
24 24 00 11 12 34 56 FF FF FF FF 50 00 8B 9B 0D 0A
24 24 00 13 12 34 56 FF FF FF FF 90 02 00 0A 8F D4 0D 0A
The 3rd and 4th bytes represent the message lengths (x00 x11 and x00 x13, respectively). As 16-bit values in network byte order, they represent decimal integers 17 and 19, respectively. And if you count the bytes present, you will see those values are the correct byte lengths of those messages. So, there are no BCDs involved here.
That is different than your example. Bytes x00 x84 in network byte order represent decimal integer 132. But your message is 84 bytes in size, not 132 bytes. So clearly the bytes x00 x84 DO NOT represent a 16-bit decimal value, so ReadSmallInt() is the wrong method to use in the first place.
In your "duct tape" code, you are taking the decimal value that ReadSmallInt() returns (132), converting it to a hex string ('0084'), and then parsing that to a decimal value (84). There is no method in Indy that will do that kind of conversion for you.
That "works" in your case, but whether or not that is the correct conversion to perform, I could not say for sure as you have not provided any details about the protocol you are dealing with. But, if you think the bytes represent a BCD then you should interpret the bytes in terms of an actual BCD.
In a packed BCD, a byte can represent a 2-digit number. In this case, byte x84 (10000100b) contains two nibbles 1000b (8) and 0100b (4), thus put together they form decimal 84, which is calculated as follows:
BYTE b = 0x84;
int len = (int((b >> 4) & 0x0F) * 10) + int(b & 0x0F);
Now, how that extends to multiple bytes in a BCD, I'm not sure, as my experience with BCDs is very limited. But, you are going to have to figure that out if you need to handle message lengths greater than 99 bytes, which is the highest decimal that a single BCD byte can represent.
Decoding Thrift Object what are these extra bytes?
I'm working on writing a pure JS thrift decoder that doesn't depend on thrift definitions. I have been following this handy guide which has been my bible for the past few days: https://erikvanoosten.github.io/thrift-missing-specification/ I almost have my parser working, but there is a string type that throws a wrench into the program, and I don't quite understand what it's doing. Here is an excerpt of the hexdump, which I did my best to annotate: Correctly parsing: 000001a0 0a 32 30 32 31 2d 31 31 2d 32 34 16 02 00 18 07 |.2021-11-24.....| ........................blah blah blah............| | | Object End-| | | 0x18 & 0xF = 0x8 = Binary-| | The binary sequence is 0x7 characters long-| 000001b0 53 65 61 74 74 6c 65 18 02 55 53 18 02 55 53 18 |Seattle..US..US.| S E A T T L E |___| U S |___| U S Another string, 2 bytes long |------------| So far so good. But then I get to this point: There string I am trying to extract is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4592.0 Safari/537.36 Edg/94.0.975.1" and is 134 bytes long. 000001c0 09 54 61 68 6f 65 2c 20 43 41 12 12 00 00 08 c8 |.Tahoe, CA......| Object ends here-| | | 0x8 & 0xF = 0x8 = Binary -| | 0xc8 bytes long (200)-| 000001d0 01 86 01 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 20 28 |...Mozilla/5.0 (| | | | M o z i l l a ???? |--|-134, encoded as var-int 000001e0 4d 61 63 69 6e 74 6f 73 68 3b 20 49 6e 74 65 6c |Macintosh; Intel| As you can see, I have a byte sequence 0x08 0xC8 0x01 0x86 0x01 which contains the length of the string I'm looking for, is followed by the string I'm looking for but has 3 extra bytes that are unclear in purpose. The 0x01 is especially confusing as it neither a type identifier, nor seems to have a concrete value. What am I missing?
Thrift supports pluggable serialization schemes. In tree you have binary, compact and json. Out of tree anything goes. From the looks of it you are trying to decode compact protocol, so I'll answer accordingly. Everything sent and everything returned in a Thrift RPC call is packaged in a struct. Every field in a struct has a 1 byte type and a 2 byte field ID prefix. In compact protocol field ids, when possible, are delta encoded into the type and all ints are compressed down to just the bits needed to store them (and some flags). Because ints can now take up varying numbers of bytes we need to know when they end. Compact protocol encodes the int bits in 7 bits of a byte and sets the high order bit to 1 if the next byte continues the int. If the high order bit is 0 the int is complete. Thus the int 5 (101) would be encoded in one byte as 0000101. Compact knows this is the end of the int because the high order bit is 0. In your case, the int 134 (binary 10000110) will need 2 bytes to encode because it is more than 7 bits. The fist 7 bits are stored in byte 1 with the 0x80 bit set to flag "the int continues". The second and final byte encodes the last bit (00000001). What you thought was 134 was just the encoding of the first seven bits. The stray 1 was the final bit of the 134. I'd recommend you use the in tree source to do any needed protocol encoding/decoding. It's already written and tested: https://github.com/apache/thrift/blob/master/lib/nodejs/lib/thrift/compact_protocol.js
The byte sequence reads as follows 0x08: String type, the next 2 bytes define the elementId 0xC8 0x01: ElementId, encoded in 16 bits 0x86 0x01: String length, encoded as var int It turns out that if the type identifier does not contain bits defining the elementId, the elementId will be stored in the next 2 bytes.
TCPDF - Problem with Alphanumerical characters (wrong size)
I have a size problem when using TCPDF to generate QR code with only ALPHANUMERICAL characters. My objective: generate the longest URL (with a random part), but keeping the QR code at its lowest size, i.e. 21x21 modules (version1).
Documentation (QRcode.com) reports that using only alphanumerical characters set (thonky.com), URL can be 25 characters long with ERC set to L.
Using write2DBarCode with this 25 Alphanumerical URL leads to version1 (21x21mod) QR as expected
$pdf->write2DBarcode('HTTP://SITE-COM/123456789', 'QRCODE,L', 20, 20, 40, 40, $style, 'N');
but changing to this other URL, with also 25 Alphanumerical, I get a version 2 (25x25mod) QR code, whereas a version 1 could be done (Tested on Nayuki)
$pdf->write2DBarcode('HTTP://TXT-CH/AYAWEQYAF4A', 'QRCODE,L', 20, 70, 40, 40, $style, 'N');
I join the TCPDF Outputs of the 2 QR codes given as examples TCPDF Outputs
Thank you in advance for your help on this wonderful TCPDF library.
Short answer: The TCPDF software that you are using is suboptimal. It is generating a full 4-bit terminator even when a shorter one suffices. Please contact the software's authors to fix the problem. You can link them to this thread. So I cropped your image into two QR Code images, and submitted them to ZXing Decoder Online and KaarPoSoft QR Decode with debug output. ZXing, first barcode: Decode Succeeded Raw text HTTP://SITE-COM/123456789 Raw bytes 20 83 1a a6 5f 9f d5 b4 75 3e 8d 20 48 81 23 db 91 8a 80 Barcode format QR_CODE Parsed Result Type URI Parsed Result HTTP://SITE-COM/123456789 ZXing, second barcode: Decode Succeeded Raw text HTTP://TXT-CH/AYAWEQYAF4A Raw bytes 20 cb 1a a6 5f 9f d6 5e ae 82 ca 0f 21 e2 52 18 11 53 94 00 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 Barcode format QR_CODE Parsed Result Type URI Parsed Result HTTP://TXT-CH/AYAWEQYAF4A KaarPoSoft, first barcode: Debug output skew_limit=7.21875 skew=0 left=31 right=427 top=27 bottom=423 size=397 matchVersion version=1 finder0=64 finder1=64 finder2=64 matchVersion version=1 timing0=1 timing1=1 alignment=1 matchVersion version=1 format_NW =14 0 format_NESW =14 1 format = 14 ecl = 1 mask = 6 matchVersion version=1 grades(F(V)TAF): 4444->4 findModuleSize matchVersion version=1 grade=4 findModuleSize version=1 grade=4 error_correction_level=1 mask=6 getCodewords mask=6 length=26 getCodewords = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128,62,191,105,157,147,176,164 setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=19 n_block_words_second=0 n_block_ec_words=7 total=26 setBlocks block 0 (26): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25 RS calculateSyndroms: No errors correctErrors in = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128,62,191,105,157,147,176,164 correctErrors out = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128 error_grade=4 extractData bytes in (19) = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128 extractData mode = 2 extractAlphanum charcount = 16 extractData mode = 1 extractNumeric charcount = 9 extractData mode = 0 extractData data(25) = 72,84,84,80,58,47,47,83,73,84,69,45,67,79,77,47,49,50,51,52,53,54,55,56,57 KaarPoSoft, second barcode: Debug output skew_limit=7.015625 skew=1 left=21 right=417 top=30 bottom=425 size=396.5 findModuleSize matchVersion version=1 grade=0 matchVersion version=2 finder0=64 finder1=64 finder2=64 matchVersion version=2 timing0=1 timing1=1 alignment=1 matchVersion version=2 format_NW =14 0 format_NESW =14 1 format = 14 ecl = 1 mask = 6 matchVersion version=2 grades(F(V)TAF): 4444->4 findModuleSize matchVersion version=2 grade=4 findModuleSize version=2 grade=4 error_correction_level=1 mask=6 getCodewords mask=6 length=44 getCodewords = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17,87,194,99,197,7,184,131,204,163,52 setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=34 n_block_words_second=0 n_block_ec_words=10 total=44 setBlocks block 0 (44): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43 RS calculateSyndroms: No errors correctErrors in = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17,87,194,99,197,7,184,131,204,163,52 correctErrors out = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17 error_grade=4 extractData bytes in (34) = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17 extractData mode = 2 extractAlphanum charcount = 25 extractData mode = 0 extractData data(25) = 72,84,84,80,58,47,47,84,88,84,45,67,72,47,65,89,65,87,69,81,89,65,70,52,65 Both QR Codes appear to have no problems regarding error correction or format violations. From the KaarPoSoft output, we can see the segments in the QR Codes. The first barcode has two segments: Alphanumeric mode, count = 16, text = "HTTP://SITE-COM/". Segment bit length = 4 (mode) + 9 (count) + 88 (data) = 101 bits. Numeric mode, count = 9, text = "123456789". Segment bit length = 4 (mode) + 10 (count) + 30 (data) = 44 bits. The second barcode has one segment: Alphanumeric mode, count = 25, text = "HTTP://TXT-CH/AYAWEQYAF4A". Segment bit length = 4 (mode) + 9 (count) + 138 (data) = 151 bits. Now, a QR Code at version 1 with low error correction level has capacity for 19 data codeword bytes, or 152 bits. The first barcode uses 101 + 44 = 145 bits = 19 bytes (rounded up), so it fits. The second barcode uses 151 bits = 19 bytes (rounded up), so it fits. So in theory, both lists of segments of text data should fit in version 1 low ECC. According to the QR spec, after the list of segments ends, these bits are appended: (TERM) Up to four "0" bits (but less if the data capacity is reached) for the terminator pseudo-mode. (BITPAD) Zero to seven "0" bits to fill up the last partial byte. (BYTEPAD) Alternating bytes of 0xEC and 0x11 until the data capacity is reached. Let's dissect what actually happened. Convert the ZXing hexadecimal byte output to binary, and annotate the fields. First barcode: 20 83 1a a6 5f 9f d5 b4 75 3e 8d 20 48 81 23 db 91 8a 80 0010 000010000 [88 bits] 0001 0000001001 [30 bits] 0000 000 (Total length = 152 bits) ^Mode ^Count ^Data ^Mode ^Count ^Data ^TERM ^BITPAD Second barcode: 20 cb 1a a6 5f 9f d6 5e ae 82 ca 0f 21 e2 52 18 11 53 94 00 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 0010 000011001 [138 bits] | 0000 00000 11101100 00010001 [...] (Total length = 272 bits) ^Mode ^Count ^Data | ^TERM ^BITPAD ^BYTEPAD Note that in the second barcode, at the position | just before the TERMinator, there are 151 bits on the left side. The terminator is normally four "0" bits, but is allowed to be shortened if the capacity (of 152 bits) is reached. So the optimal terminator is a single bit of "0", and then there must be no bit padding and no byte padding.
Cannot write CIE's IEEE address to IAS zone device
I am using trying to add the following IAS zone devices (from HEIMAN) to my ZCL co-ordinator(CIE) + IoT gateway (from NXP) emergency button - gets added easily and triggers successfully door sensor - joins the network but no enrolment process is seen Q1. Why is it such that one device undergoes enrolment process correctly and the other doesn't? My understanding is that the ZCL stack should do all the enrolment activities. Am I correct? Q2. I tried writing IEEE address of the CIE to the node's cluster(0x0500) attribute (0x0010) of attribute type (0xf0). But no response. How to tackle this issue?
For a CIE device, the enrolment is more complex and the ZCL stack will not perform this for you (although this may depend on the stack, and any add-on features it provides). A CIE device may perform its own service discovery using the ZDO Match Descriptor functions. It may send a MatchDescriptorRequest report looking for an IAS server, and you will need to respond with the MatchDescriptorResponse to report that you support this. Typically the request will be looking for the IAS Zone Server cluster (0x500), but you should inspect the packets and respond appropriately. See 2.4.3.1.7 Match_Desc_req, and 2.4.4.1.7 Match_Desc_rsp of the ZigBee specification. If an IAS device is looking for a zone controller, it may not accept any requests until it receives this response, and in fact some devices may leave the network if they don't find the services they are requesting. Next, it may enrol with the IAS service by sending the ZoneEnrollRequest command, and your application will need to respond to this with the ZoneEnrollResponse to tell the device that it is now enrolled in your system. Refer to 8.2.2.4.2 Zone Enroll Request Command in the ZCL specification. From your traces, it is hard to say what is happening as the log viewer doesn't provide any information on the contents of the Data Request frames in this view. However, we can see a lot of frames being sent from the device to the coordinator, and it is likely that it is performing one, or both of the discovery services discussed above. You should inspect the requests to find out what they are, and check the appropriate sections of the ZigBee specification, or the ZigBee Cluster Library Specification.
CIE IEEE Address to IAS zone worked successfully. Tested using Xbee s2c. Explicit Addressing Command Frame (API 2) 7E 00 22 7D 31 01 28 6D 97 00 01 04 2B 7D 5D FF FE E8 01 05 00 01 04 00 20 00 01 02 10 00 F0 6B 7A 29 41 00 A2 7D 33 00 FD Start delimiter: 7E Length: 00 22 (34) Frame type: 11 (Explicit Addressing Command Frame) Frame ID: 01 (1) 64-bit dest. address: 28 6D 97 00 01 04 2B 7D 16-bit dest. address: FF FE Source endpoint: E8 Dest. endpoint: 01 Cluster ID: 05 00 Profile ID: 01 04 Broadcast radius: 00 (0) Transmit options: 20 RF data: 00 01 02 10 00 F0 6B 7A 29 41 00 A2 13 00 Checksum: FD Explicit RX Indicator (API 2) 7E 00 16 91 28 6D 97 00 01 04 2B 7D 5D A3 87 01 E8 05 00 01 04 21 18 01 04 00 3A Start delimiter: 7E Length: 00 16 (22) Frame type: 91 (Explicit RX Indicator) 64-bit source address: 28 6D 97 00 01 04 2B 7D 16-bit source address: A3 87 Source endpoint: 01 Destination endpoint: E8 Cluster ID: 05 00 Profile ID: 01 04 Receive options: 21 RF data: 18 01 04 00 Checksum: 3A
Which standards are SS7 MAP Tags defined in?
Can anyone give me information on which standard contains MAP Tags - sm-RP-UI? 04 1a - sm-RP-UI 24 - TP-RP/UDHI/SRI/MMS/MTI 0b - length 91 26 18 18 55 32 f7 - TP-Originating-Address 00 - TP-PID 00 - TP-DCS 90 40 02 91 61 42 82 - TP-Service-Centre-Time-Stamp 07 - TP-User-Data-Length: (7) depends on Data-Coding-Scheme ca f0 3a 2c a7 87 01 - TP-User-Data The details are needed for coding and I'd like to know which standard they are in. I have been looking in GSM 29.002, GSM 23.040, and GSM 24.011 and I haven't found them. Any help would be greatly appreciated, Thank you.
The SMTL PDUs are defined in 3GPP TS 23.040 - Technical realization of the Short Message Service (SMS) More specifically: 04 1a This is ASN.1 tag a length (OCTET STRING). Since you say this is sm-RP-UI it would be the SignalInfo ASN.1 type defined in 3GPP TS 29.002 used with labels sm-RP-UI on different MAP operations. 24 First thing to look here are the last two bits (TP-Message-Type-Indicator: 9.2.3.1 of 23.040) Since you have H'24 -> B'00100100. This is an SMS-DELIVER (SC to MS) SMS-DELIVER (9.2.2.1) contains TP-Message-Type-Indicator (TP-MTI on 9.2.3.1) (bit 0-1 --> 00) TP-More-Messages-To-Send (TP-MMS on 9.2.3.2) (bit 2 --> 1: "No more messages are waiting for the MS in this SC TP-Status-Report-Indication (TP-SRI on 9.2.3.4) (bit 5 --> 1: "A status report shall be returned to the SME") TP-User-Data_Header-Indicator (TP-UDHI on 9.2.3.23) (bit 6 -> 0: "The TP-UD field contains only the short message") TP-Reply-Path (TP-RP on 9.2.3.17) (bit 7 -> 0: "Not set") 0b 91 26 18 18 55 32 f7 TP-Originating-Address (TP-OA 9.2.3.7 - Address fields in 9.1.2.5) that works: ** Address-Length: H'B = D'11 (not this is in semi-octets) ** Type-of-Address: H'91=B'10010001 with Type-of-Nuymber (B'001: International number) and Numbering-Plan (B'0001: ISDN/E.164) ** Address-Value: BCD: 62818155327 (F is filler) 00 TP-Protocol-Identifier (TP-PID 9.2.3.9) 00 TP-Data-Coding-Scheme (TP-DCS 9.2.3.10) 90 40 02 91 61 42 82 TP-Service-Centre-Time-Stamp (TP-SCTS 9.2.3.11) 2009/04/20 19:16:24 07 TP-User-Data-Length (TP-UDL 9.2.3.16) ca f0 3a 2c a7 87 01 * TP-User-Data (TP-UD 9.2.3.24)