DCMTK movescu error: response suceed but no file received - windows

I am new in DICOM and DCMTK. I was trying to retrieve dcm files from a private PACS server(172.18.1.1) with movescu command in Windows platform. The incoming and outgoing message were normal but no data was received in the specified directory.The command is as following:
movescu.exe -d -S -aec GEPACS -aet TEST1 -od c:\windows\dcmtk\dcm 172.18.1.1 4100 -k QueryRetrieveLevel=STUDY -k StudyInstanceUID=1.2.840.113619.186.351258914078.20100708160459594.417
The output message is as follow:
>D: $dcmtk: movescu v3.6.3 2018-02-05 $
>D:
>D: Request Parameters:
>D: ====================== BEGIN A-ASSOCIATE-RQ =====================
>D: Our Implementation Class UI>D: 1.2.276.0.7230010.3.0.3.6.3
>D: Our Implementation Version Name: OFFIS_DCMTK_363
>D: Their Implementation Class UI>D:
>D: Their Implementation Version Name:
>D: Application Context Name: 1.2.840.10008.3.1.1.1
>D: Calling Application Name: TEST1
>D: Called Application Name: GEPACS
>D: Responding Application Name: GEPACS
>D: Our Max PDU Receive Size: 16384
>D: Their Max PDU Receive Size: 0
>D: Presentation Contexts:
>D: Context I>D: 1 (Proposed)
>D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
>D: Proposed SCP/SCU Role: Default
>D: Proposed Transfer Syntax(es):
>D: =LittleEndianExplicit
>D: =BigEndianExplicit
>D: =LittleEndianImplicit
>D: Context I>D: 3 (Proposed)
>D: Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
>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
>D: setting network send timeout to 60 seconds
>D: setting network receive timeout to 60 seconds
>D: Constructing Associate RQ PDU
>D: PDU Type: Associate Accept, PDU Length: 208 + 6 bytes PDU header
>D: 02 00 00 00 00 d0 00 01 00 00 47 45 50 41 43 53
>D: 20 20 20 20 20 20 20 20 20 20 41 45 5f 41 52 43
>D: 48 31 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 21 00 00 1b 03 00 00 00 40 00 00 13 31 2e
>D: 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32 2e
>D: 31 50 00 00 31 51 00 00 04 00 00 70 00 52 00 00
>D: 13 31 2e 32 2e 38 34 30 2e 31 31 33 36 31 39 2e
>D: 36 2e 39 34 55 00 00 0e 43 45 4e 54 52 49 43 49
>D: 54 59 5f 34 2e 30
>D: Parsing an A-ASSOCIATE PDU
>D: Association Parameters Negotiate>D:
>D: ====================== BEGIN A-ASSOCIATE-AC =====================
>D: Our Implementation Class UI>D: 1.2.276.0.7230010.3.0.3.6.3
>D: Our Implementation Version Name: OFFIS_DCMTK_363
>D: Their Implementation Class UI>D: 1.2.840.113619.6.94
>D: Their Implementation Version Name: CENTRICITY_4.0
>D: Application Context Name: 1.2.840.10008.3.1.1.1
>D: Calling Application Name: TEST1
>D: Called Application Nae: GEPACS
>D: Responding Application Name: GEPACS
>D: Our Max PDU Receive Size: 16384
>D: Their Max PDU Receive Size: 28672
>D: Presentation Contexts:
>D: Context I>D: 1 (Accepted)
>D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
>D: Proposed SCP/SCU Role: Default
>D: Accepted SCP/SCU Role: Default
>D: Accepted Transfer Syntax: =LittleEndianExplicit
>D: Context I>D: 3 (Accepted)
>D: Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
>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: 28660)
>I: Sending Move Request
>D: ===================== OUTGOING DIMSE MESSAGE ====================
>D: Message Type : C-MOVE RQ
>D: Presentation Context ID : 3
>D: Message ID : 1
>D: Affected SOP Class UID : MOVEStudyRootQueryRetrieveInformationModel
>D: Data Set : present
>D: Priority : medium
>D: Move Destination : TEST1
>D: ======================= END DIMSE MESSAGE =======================
>I: Request Identifiers:
>I:
>I: # Dicom-Data-Set
>I: # Used TransferSyntax: Little Endian Explicit
>I: (0008,0052) CS [STUDY] # 6, 1 QueryRetrieveLevel
>I: (0020,000d) UI [1.2.840.113619.186.351258914078.20100708160459594.417] # 54, 1 StudyInstanceUID
>I:
>D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
>I: Received Final Move Response
>D: ===================== INCOMING DIMSE MESSAGE ====================
>D: Message Type : C-MOVE RSP
>D: Message ID Being Responded To : 1
>D: Affected SOP Class UID : MOVEStudyRootQueryRetrieveInformationModel
>D: Remaining Suboperations : none
>D: Completed Suboperations : 6
>D: Failed Suboperations : 0
>D: Warning Suboperations : 0
>D: Data Set : none
>D: DIMSE Status : 0x0000: Success
>D: ======================= END DIMSE MESSAGE =======================
>I: Releasing Association
And also I tried to add --port 104 or -aem TEST1, but failed either.

The default "move destination" (option -aem) of movescu is "MOVESCU". Does your PACS know anything about this AE title? It seems that the 6 DICOM SOP Instances ("Completed Suboperations: 6") were sent successfully to this AE (Application Entity). The output directory (option -od) is only used when movescu also acts as a Storage SCP, i.e. if option --port (or +P) is used.
And also I tried to add --port 104 or -aem TEST1, but failed either.
Did you configure your PACS to map the AE title "TEST1" to the IP address of the system movescu is running on and to port 104?

It seems that the C-MOVE operation is successful:
>I: Received Final Move Response
>D: ===================== INCOMING DIMSE MESSAGE ====================
>D: Message Type : C-MOVE RSP
>D: Message ID Being Responded To : 1
>D: Affected SOP Class UID : MOVEStudyRootQueryRetrieveInformationModel
>D: Remaining Suboperations : none
>D: Completed Suboperations : 6
>D: Failed Suboperations : 0
>D: Warning Suboperations : 0
>D: Data Set : none
>D: DIMSE Status : 0x0000: Success
>D: ======================= END DIMSE MESSAGE =======================
According to the message from the server, 6 Sub-Operations were successsfully completed (i.e. 6 images were moved to the move destination), and the Status is "Success". Thus, I would suspect that the AET "TEST1" maps to a different system, not yours.
As J. Riesmeier suggested, you should check the IP and Port configuration for "TEST1" in the PACS.

Related

Getting ADF from PPSE by android Pay applicatons

I'm trying to read a smartcard information by android pay application. So I send the following SELECT PPSE command:
00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
I get the following response:
That is, I need to get an ADF <A0 00 00 06 58 10 10>, but when I try to get it by SELECT:
00 A4 04 00 07 A0 00 00 06 58 10 10
I get the following response:
SW1SW2 = 6A82: File not found.
The tag 9F2A in PPSE means that I need to use Kernel specification (Kernel 1 for me).
But the documentation talks about actions from the moment when there is already a PDOL.
How do I get the PDOL if the ADF in which it is located is not found?

getUserMedia and WEBUSB over the same device Windows

We are developing a project based on Chrome (old USB API now migrating to WEBUSB) and a webcam. The USB Webcam has a button used for taking picture. In MAC and Linux I can show the live video of the webcam using getUserMedia () and on the same time I can use Web USB API to communicate with the device for detecting button press.
The problem is windows. On Windows Chorme can see the USB device as a Webcam accessible from getUserMedia (if I install the usb device original driver) or as USB device accessible form WebUSB (if I replace the original driver with WINUSB) but we are unable to use the two API toghether. This is a problem only on WINDOWS, in Mac or Linux all is working. How can we solve this?
N.B.
To make the javascript USB commands work on linux and OSX I had to replace "interface" with "endpoint" in transfer commands.
Linux lsusb dump:
Bus 001 Device 008: ID a168:0872 AnMo Electronics Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0xa168 AnMo Electronics Corporation
idProduct 0x0872
bcdDevice 20.01
iManufacturer 1 ANMO Electronics Corporation
iProduct 2 Dino-Lite Premier
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 509
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 2 Dino-Lite Premier
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 2 Dino-Lite Premier
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 80
dwClockFrequency 6.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x000200a2
Auto-Exposure Mode
Focus (Absolute)
Iris (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000147f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1d
None
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength 29
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {2652215a-8932-5641-894a-5c557cdf9664}
bNumControl 16
bNrPins 1
baSourceID( 0) 3
bControlSize 4
bmControls( 0) 0xff
bmControls( 1) 0xff
bmControls( 2) 0xff
bmControls( 3) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
INTERFACE CLASS: 0f 24 01 02 67 01 82 00 02 01 01 00 01 00 00
INTERFACE CLASS: 0b 24 06 01 05 00 01 00 00 00 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 02 00 40 01 f0 00 80 00 02 32 80 00 02 32 00 58 02 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 03 00 a0 00 78 00 a0 00 00 8c a0 00 00 8c 00 96 00 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 04 00 00 05 00 04 00 00 19 00 00 00 19 00 00 00 28 00 20 a1 07 00 01 20 a1 07 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1b 24 04 02 05 59 55 59 32 00 00 10 00 80 00 00 aa 00 38 9b 71 10 01 00 00 00 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 02 00 40 01 f0 00 80 00 02 32 80 00 02 32 00 58 02 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 03 00 a0 00 78 00 a0 00 00 8c a0 00 00 8c 00 96 00 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 04 00 00 05 00 04 00 00 19 00 00 00 19 00 00 00 28 00 20 a1 07 00 01 20 a1 07 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 06 24 0d 00 00 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x13fc 3x 1020 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
Based on the output from lsusb -v above I can see that this device has a single function comprised of two USB interfaces. The Interface Association Descriptor (IAD) signals to the host operating system that these two interfaces are related and operating systems like Windows will treat them as a single interface for the purposes of driver binding.
My guess is that on Linux and macOS you are able to communicate with the EP 1 IN endpoint because only interface 1 is claimed by the USB video class (UVC) driver. On Windows, since it considers both interfaces a single entity "function 0", you are unable to claim interface 0 because interface 1 is already claimed as part of function 0.

How to read binary blocks of mifare card?

I am developing an application which reads NFC card from the reader.
I know the code for reading binary block like this:
FF B0 00 04 10
04 for the block 4 and 10 for 16 bytes data. My card has the data "TEST009996".
I run 5 code for read binary blocks from 4-8 like this:
FF B0 00 04 10
FF B0 00 05 10
FF B0 00 06 10
FF B0 00 07 10
FF B0 00 08 10
I got the following results:
T☻enTEÉ ☺
T☻enTEST00É
T☻enTEST009996É
enTEST009996■ 6É
ST009996■ 6 É
or in hexadecimal:
01 03 A0 10 44 03 11 D1 01 0D 54 02 65 6E 48 43 90 00
44 03 11 D1 01 0D 54 02 65 6E 48 43 49 44 30 30 90 00
01 0D 54 02 65 6E 48 43 49 44 30 30 39 39 39 36 90 00
65 6E 48 43 49 44 30 30 39 39 39 36 FE 00 00 36 90 00
49 44 30 30 39 39 39 36 FE 00 00 36 00 00 00 00 90 00
Should I create an algorithm to cut the result to get the data? Are there any better ways?
Source:
http://downloads.acs.com.hk/drivers/en/API-ACR122U-2.02.pdf
It seems that your tag is an NFC Forum Type 2 Tag (find the NFC Forum Type 2 Tag Operation specification on the NFC Forum website). As you mention MIFARE this could, for instance, be a MIFARE Ultralight, MIFARE Ultralight C or NTAG tag.
A block on a Type 2 Tag consists of 4 bytes. The read command reads 4 blocks at a time. So the read command gives you 4 blocks (4 bytes each) starting at a given block offset plus a status word for the read command (0x9000 for success). In your case you get:
Read(4, 16): 0103A010 440311D1 010D5402 656E4843 9000
Read(5, 16): 440311D1 010D5402 656E4843 49443030 9000
Read(6, 16): 010D5402 656E4843 49443030 39393936 9000
Read(7, 16): 656E4843 49443030 39393936 FE000036 9000
Read(8, 16): 49443030 39393936 FE000036 00000000 9000
Consequently, the memory of your tag looks like this:
0103A010
440311D1
010D5402
656E4843
49443030
39393936
FE000036
00000000
A Type 2 Tag (btw. in order to make sure that this tag actually conforms to the Type 2 Tag Operation Specification you would also need to read the capability container which is located in block 3) contains a series of tag-length-value (TLV) structures:
01 (Tag: Lock Control TLV)
03 (Length: 3 bytes)
A0 10 44 (Value: Information on position and function of lock bytes)
03 (Tag: NDEF Message TLV)
11 (Length: 17 bytes)
D1010D5402656E48434944303039393936 (Value: NDEF message)
FE (Tag: Terminator TLV; has no length field)
So your tag contains the NDEF message
D1010D5402656E48434944303039393936
This translates to
D1 (Header byte of record 1)
- Message begin is set (= first record of an NDEF message)
- Message end is set (= last record of an NDEF message)
- Short record flag is set (= Payload length field consists of 1 byte only)
- Type Name Format = 0x1 (= Type field contains an NFC Forum well-known type)
01 (Type length: 1 byte)
0D (Payload length: 13 bytes)
54 (Type: "T")
02656E48434944303039393936 (Payload field)
The payload field of a NFC Forum Text record decodes like this:
02 (Status byte: Text is UTF-8 encoded, Language code has a length of 2 bytes)
656E (Language code: "en")
48434944303039393936 (Text: "TEST009996")

ISO 14443a Card Will Not Connect - Strange Error Code

I am getting a strange output when I try to connect my ISO 14443a card to an NFC reader.
0: : 26
0: 0: TAG 04 00
0: : 93 20
0: 0: TAG 47 82 db b3 ad
0: : 93 70 47 82 db b3 ad 3a f4
0: 0: TAG 28 b4 fc
0: : e0 50 bc a5
0: 0: TAG 13 78 80 82 02 80 31 80 66 b0 84 16 01 6e 01 83 00 90 00 03 d1
0: : e0 50 bc a5
0: 0: TAG 13 78 80 82 02 80 31 80 66 b0 84 16 01 6e 01 83 00 90 00 03 d1
0: : c2 e0 b4 <<<< WHAT??
0: 0: TAG 03 6a 82 4f 75
0: : 26
0: 0: TAG 04 00
0: : 78
You can see that the cards is woken up, performs the anti-collision, then sends its ATS when requested (it gets asked twice for some reason?).
After this, the reader sends a strange command (marked above) and the card responds with an 'Operation not supported' response.
The wake-up, anti-collision protocol then restarts, and this goes on and on.
My question is, what does the command (c2 e0 b4) sent from the reader mean?
Thanks in advance.
I do not know if you are still interested in the response, I will just save time for anyone else who might be looking for the solution(like I was).
This is nothing else but S(Deselect) block sent from the reader, consisting of Protcol Contol Byte(PCB) and 2 bytes of CRC_A
C2 E0 B4
The same applies for anyone who might be looking for this command coming from the reader:
B2 67 C7
It is R(NACK) block, consisting of Protcol Contol Byte(PCB) and 2 bytes of CRC_A
They both are a fundamental part of ISO-DEP protocol(Type 4A or Type 4B tags), so read description and how to properly handle them in the "NFC Digital Protocol" spec, chapter "13 ISO-DEP Protocol"

Sending wap push

I try send wap push message. I set datacoding 0xf5 and send submit sm with following message:
GSM Short Message Service User Data
udh length: 6
16-bit address 05 04
Destination port 08b4
Source port 23f0
Wireless Session Protocol, Method: Push (0x06), Content-Type: application/vnd.wap.sic
Transaction Id: 0x25
PDU Type: Push (0x06)
Header length: 1
Content type: application/vnd.wap.sic
WAP Binary XML, Version: 1.2, Public ID: "-//WAPFORUM//DTD SI 1.0//EN (Service Indication 1 .0)"
Version: 1.2 (0x02)
Public Identifier: (known): -//WAPFORUM//DTD SI 1.0//EN (Service Indication 1 .0)
Character Set: utf-8 (0x000006a)
String table: 0 bytes
Data representation:
45 <si>
c6 <indication
0c href='http://'
03 69 2e 69 6d 67 75 72 2e 63 6f 6d 2f 66 6a 49 44 4e 2e 6a 70 67 00 i.imgur.com/fjIDN.jpg'
07 action='signal-medium'
01 >
03 69 6d 67 75 72 00 'imgur'
01 </indication>
01 </si>
Message bytes:
06 05 04 0b 84 23 f0 25 06 01 ae 02 05 6a 00 45
c6 0c 03 69 2e 69 6d 67 75 72 2e 63 6f 6d 2f 66
6a 49 44 4e 2e 6a 70 67 00 07 01 03 69 6d 67 75
72 00 01 01
SMSC return: Submit_sm - resp: "OK".
But the phone did not show nothing. Any ideas?
Sorry for my ugly english :)
I can't fully justify why these changes work, but from extensive testing a few years back the following seemed to work reliably across the UK networks and a range of different handsets. It's in use in production code and we haven't seen any problems since.
06 - UDHL
05 - EI (Send to Ports 16bit addr)
04 - EIDL
0B - src port
84 - src port
23 - dest port
F0 - dest port (End of UDH)
01 - trans id
06 - Push
04 - Header Length
03 - Length
AE - Content type (application/vnd.wap.sic)
81 - Character Set (01 once removed high bit)
EA - UTF 8 (6A once removed high bit)
02 - Binary XML Version 1.2
05 - SI Identifier
6A - UTF-8
00 - End Data
45 - SI Binary XML Tag
C6 - Indication Tag
0B - href
03 - Open Text
(URL bytes go here...)
00 - End Data
0A - Created (date)
C3 - Data Follows
07 - Data Length
20 - date yy (century)
08 - date yy (year)
03 - date mm
26 - date dd
16 - date HH
09 - date MM
12 - date ss
01 - Close Attribute
03 - Open Text (Text Goes in here...)
00 - End Data
01 - Close Indication Tag
01 - Close SI Tag
There are a few differences to your send:
UTF-8 Character set specified on the Wireless Session Protocol header
http:// is written in full as bytes, I don't think this made a difference but it was required by the rest of our application.
No action on the indication tag
Added a created date attribute - This seemed to make a big difference to handset support (I'm not quite sure why).

Resources