Rosen Ira-IROSEN1 kirjoittaa perjantaina, 12. hein�kuuta 2002, kello
20:10:Using the 'test_ppg' program, I have the PPG forwarding a response
to an SI PUSH request to an SMSC. I'm trying to understand the details
of the response forwarded by Kannel to the SMSC. I have parsed most of
the content of the message, but there are several response bytes I've
been unable to identify. I've used several WAP PUSH-related standards
documents and read through some Kannel source to try and find how/where
the bytes are packed. To be more specific, I've parsed the complete SI
portion of the response. Does anyone have any suggestions on how I can
determine the meaning of the values of the remaining fields? I've
replicated some of the data below with some details removed such as
portions of text strings such as URI-related information and other text
strings. I've also removed portions of the IP header fields.
There are two different push protocols one between PI (push initiator)
and PPG, called PAP, and another between PPG and phone,
called Push OTA. PAP works over HTTP, with its PDU packed as MIME
multipart structure. Push control document is non-payload
part of PAP PDU, so it controls PPG operation,and only address is sended
forward. What you see an OTA PDU, or, because OTA
is almost directly mapped to WSP, unconfirmed push WSP pdu. This is SMS
payload, so structure of the message Kannel sends is:
SMS headers | SMS IEs | WSP headers | tokenized SI document
PPG set only SMS IEs (ports IE and segmentation and reassembly IE).
> The POS column is the byte number in the output (including TCP/IP
> header information). HEX is the hex value of the output character. CHAR
> is the character representation ('.' shows where the hex value is a
> non-displayable character), Description is provided where I've been
> able to identify a byte meaning.
>
> POS HEX CHAR DESCRIPTION
> 71 00 . Operation = submit_sm (1 of 4).
> 74 04 . Operation = submit_sm (4 of 4).
> 75 00 .
> 76 00 .
> 77 00 .
> 78 00 .
> 79 00 . Sequence (1 of 4).
> 82 03 . Sequence (4 of 4).
> 83 00 .
> 84 01 . Number Type (Origin) = International
> 85 01 . Number Plan Indicator (Origin) = ISDN
> 86 37 7 Origin Phone (1 of 7).
> 93 00 . Origin Phone Terminator
> 94 01 . Number Type (Dest) = International
> 95 01 . Number Plan Indicator (Dest) = ISDN
> 96 37 7 Dest Phone (1 of 7).
> 103 00 . Dest Phone Terminator.
> 104 43 C (0100 0011) Low 2 bits: msg mode (store/fwd); middle
> 4 bits: Default msg type; 2 high bits: UDHI.
> 105 00 . Protocol ID
> 106 00 . Priority Level
> 107 00 . mclass (?)
> 108 00 . mwi(?)
> 109 00 . (0000 0000) Low 2 bits (bits 0 and 1): No SMSC
> delivery Receipt requested; Bits 2-3: Msg Type (no recipient SME ack
> requested); Bit 4 (intermediate notification): not requested
> 110 00 . Low bit (bit 0): Don't replace
> 111 08 . Data coding: UCS2 (ISO/IEC-10646)
> 112 00 . Pre-defined message
> 113 88 . Message Length (136).
Here we have ports IE (IEI 6). PPG must specify push port for SI document
> 114 06 . Ports IEI
> 115 05 . Length of IE
> 116 04 . Length of address
> 117 0b . Destination port hex high
> 118 84 . Destination port hex low
> 119 23 # Originator port hex high
> 120 f0 . Originator port hex low
Then there is WSP part, control unit:
> 121 00 . Push Id
> 122 06 . WSP PDU - unconfirmed push
> 123 22 " WSP headers length: 34
> 124 ae . Content-Type: application/vnd.wap.sic
> 125 96 . Host:
> 126 64 Name of host
> 151 00 . Terminator of hostname.
> 152 af . X-WAP-Application-Id:
> 153 80 . any
> 154 8d . Content-Length:
> 155 dc . 220
> 156 b4 . Push-Flag
> 157 80 . 0
Then the tokenized SI document (Note that this *byte* code. If there is
more
bytes to consider, this is always spelled out, for instance, terminator
for text
strings.):
> 158 02 . WBXML Version 1.2
> 159 05 . SI public identifier (untokenize to SI document)
> 160 6a j UTF-8 charset
> 161 00 . string table length (string table is used for
> compression,
it is hardly necessary here)
> 162 45 E si, with content
> 163 c6 . indication with content and attributes
> 164 0d . href (http://www.)
> 165 03 . Inline string follows
> 166 63 c URL for request (1 of 7).
> 173 00 . Terminator for URL for request.
> 174 85 . URL Type (.com).
> 175 03 . Inline string follows
> 176 7e ~ Path for request (1 of 29).
> 205 00 . Terminator for PATH for request.
> 206 07 . Action = signal-medium.
> 207 0a . "Created ="
> 208 c3 . OPAQUE data follows:
> 209 07 . Length of data
> 210 19 . Begin creation time (hex).
> 217 10 . SI-expires =
> 218 c3 . OPAQUE data follows:
> 219 04 . Length of data
> 220 20 Begin expiration time (hex).
> 221 02 . Continue expiration time.
> 224 01 . End Indication attribute list.
> 225 03 . Inline string follows
> 226 57 W Begin text message for phone (1 of 21).
> 247 00 . Terminator for text message for phone.
> 248 01 . End Indication Element
> 249 01 . End SI Document.
>
>
>
>
> Since I was able to identify all the fields in the SI document, I
> thought the unidentified fields would relate to the push control
> document, but I've been unable to make these connections using WAP
> standards documents and Kannel source/headers, primarily in the gw and
> gwlib directories. I think byte numbers 116 through 125 and 152 through
> 157 will contain the most important information. In particular, I
> wonder if these positions represent the values in the
> "quality-of-service" portion of the Push Control Document. The SI and
> Push Control documents I've used are provided below:
Quality of service is used for controlling PPG, it is, telling it to use
confirmed or unconfirmed push and a specific bearer for sending
the push.
Aarno
