Rejected pdu

Rejected pdu SearchSearch
Author Message
Robert
Posted on Thursday, October 02, 2003 - 02:21 am:   

Hi,
I have tried to post the following pdu to proxy server but got back unable to process. Can anyone spot a problem with this message pdu?
thanks
Rob.

DETAILS
----------------------------------------------
apn: mms
proxy address: 10.12.0.30
proxy port: 9201
proxy server: http://mms/servlets/mms


transmit 1:
0A7D AC32 0110 0D00 0480 8C9A 4004 818C 9A40 0283
0585 8585 8520 3020 7894 0B08 0494 0B08 3F00 7908

receive 1:
12FD AC02 8BA5 CD0B 0D52 0480 8C9A 4004 818C 9A40

0283 0578 2D75 702D 7072 6F78 792D 626F 6F6B 6D61
x - u p - p r o x y - b o o k m a
726B 0068 7474 703A 2F2F 7777 772E 6577 6170 2E63
r k h t t p : / / w w w . e w a p . c
6F2E 6165 2F6D 6172 6B00 782D 7570 2D70 726F 7879
m . a e / m a r k x - u p - p r o x y
2D75 706C 696E 6B2D 7665 7273 696F 6E00 352E 312E
- u p l i n k - v e r s i o n 5 . 1 .
312E 3561 0000 0000 0000 0000 0000 0000 0000 0000
1 . 5 a

transmit 2:
187D AC85 8585 8508 6600 0000 0300 0000 0000 0000
(ack)

transmit 3:
The message PDU that we sent was:

0A7D AD12 6017 2468 7474 703A 2F2F 6D6D 732F 7365
h t t p : / / m m s / s e
7276 6C65 7473 2F6D 6D73 6170 706C 6963 6174 696F
r v l e t s / m m s a p p l i c a t i o
6E2F 766E 642E 7761 702E 6D6D 732D 6D65 7373 6167
n / v n d . w a p . m m s - m e s s a g
6500 8080 8880 8C80 9839 3738 3335 3036 3431 008D
e 9 7 8 3 5 0 6 4 1
9189 0181 9736 3738 3130 3739 2F54 5950 453D 504C
6 7 8 1 0 7 9 / T Y P E = P L
4D4E 0084 A301 0405 0383 81EA 5465 7374 2085 8585
M N T e s t

pdu Receive:
12FD AD04 2063 6170 706C 6963 6174 696F 6E2F 766E
c a p p l i c a t i o n / v n
642E 7761 702E 6D6D 732D 6D65 7373 6167 6500 A652
d . w a p . m m s - m e s s a g e R
6573 696E 2F32 2E31 2E36 00AC 1F2D 8E6C 682D 6261
e s i n / 2 . 1 . 6 - b a
7365 2E65 7761 702E 636F 2E61 6500 2254 7261 6E73
s e . e w a p . c o . a e " T r a n s
666F 726D 6174 696F 6E20 4170 706C 6965 6422 0092
f o r m a t i o n A p p l i e d "
043F 77F3 AD8C 8198 3937 3833 3530 3634 3100 8D90
9 7 8 3 5 0 6 4 1
9288 9355 6E61 626C 6520 746F 2070 726F 6365 7373
U n a b l e t o p r o c e s s
2072 6571 7565 7374 2E00 0000 0000 0000 0000 0000
r e q u e s t .



Bryce Norwood - NowSMS Support
Posted on Thursday, October 09, 2003 - 08:33 pm:   

FWIW, I suspect the WAP protocol part of your request is ok ... although I did not analyse it in detail.

I do notice that you are getting an MMS content response back from the MMSC, and the MMSC is telling you that the "x-mms-response-status" is "error-unsupported-message".

So this tells me that the MMSC did not like something about the MMS PDU that was submitted. I notice that you specify MMS v1.1 in the header, and maybe the MMSC does not like that.

Good luck!
Anonymous
Posted on Friday, October 10, 2003 - 09:29 am:   

Hi,bryce,
I notice that you specify MMS v1.1 in the header
how do you know it ? would you please tell me in details? thanks.
Bryce Norwood - NowSMS Support
Posted on Friday, October 10, 2003 - 09:57 pm:   

The MMS PDU is the data of the WSP Post PDU in Transmit 3. (The WSP Post PDU itself is encapsulated in a WTP Invoke PDU.)

The MMS PDU data starts with ...

8C80 9839

The format of the MMS PDU is defined in the MMS Encapsulation Specification, published by the Open Mobile Alliance (part of the WAP specs).

8C 80 translates to "X-Mms-Message-Type: m-send-req"

9839 3738 3335 3036 3431 00 translates to "X-Mms-Transaction-Id: 978350641"

8D 91 translates to "X-Mms-MMS-Version: 1.1"
Robert
Posted on Wednesday, October 15, 2003 - 02:22 pm:   

Hi, I have now confirmed that I need to use mms1.0, however I still get the same rejection after changing to this. Does anyone have anymore ideas , I am sending to an ericsson mmsc.
Bryce Norwood - NowSMS Support
Posted on Wednesday, October 15, 2003 - 05:48 pm:   

If I had to hazard another guess, I can't understand why your PDU (transmit 3) has garbage data at the end of it.

And actually, Section 8.5.2 of the WSP specification says that the nEntries field in the multipart header is now deprecated:

quote:

This field is being deprecated as the receiver can determine the number of entries by
stepping through each entry till the end of the PDU.




So, I could see where this garbage data would basically be interpreted as the next multipart entry, and the message would be considered corrupt.