| MMS Receive: 403 Forbidden |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Ian Fitchet New member Username: Idf Post Number: 1 Registered: 12-2003 |
Hi, I haven't seen this come up but with b20031006 I have the following dialog with O2's MMSC when I am trying to receive an MMS. I have had the MMS Notification, the following is repeated every five minutes in MMSWAPDEBUG.LOG: 12:55:12:557 GetCIDForAPN: Standard 19200 bps Modem 12:55:12:557 GetCIDForAPN: wap.o2.co.uk 12:55:12:557 InitTAPI: Returning cached TAPI session information 12:55:14:197 GetCIDForAPN: AT+CGDCONT=? 12:55:14:354 GetCIDForAPN: +CGDCONT: (1-2),"IP",,,(0),(0) OK 12:55:14:354 GetCIDForAPN: minCID = 1, maxCID = 2 12:55:14:354 GetCIDForAPN: AT+CGDCONT? 12:55:14:510 GetCIDForAPN: +CGDCONT: 1,"IP","wap.o2.co.uk","",0,0 OK 12:55:14:510 GetCIDForAPN: Found CID=1 for APN wap.o2.co.uk 12:55:14:510 WSPRasDial: Before RasDial NowSMS - Standard 19200 bps Modem 12:55:22:932 WSPRasDial: RasDial connected to NowSMS - Standard 19200 bps Modem 12:55:22:948 WSPAddRoute: Routing 193.113.200.195 via 10.254.240.110 12:55:23:041 WSPConnect: Sending 44 byte request to 193.113.200.195 12:55:23:041 WSPConnect: Packet Length is 44 bytes 12:55:23:041 WSPConnect: 0A 00 06 12 01 10 0A 1A 04 80 8F F8 00 04 81 8F 12:55:23:041 WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G 12:55:23:041 WSPConnect: 61 74 65 77 61 79 20 76 35 2E 30 00 ateway v5.0 12:55:31:416 WSPConnect: Received 13 byte response from 193.113.200.195 12:55:31:416 WSPConnect: Packet Length is 13 bytes 12:55:31:416 WSPConnect: 13 80 06 03 40 C4 00 C0 34 C1 71 C8 97 @ 4 q 12:55:31:416 WSPConnect: Sending 44 byte request to 193.113.200.195 12:55:31:416 WSPConnect: Packet Length is 44 bytes 12:55:31:416 WSPConnect: 0A 00 06 12 01 10 0A 1A 04 80 8F F8 00 04 81 8F 12:55:31:416 WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G 12:55:31:416 WSPConnect: 61 74 65 77 61 79 20 76 35 2E 30 00 ateway v5.0 12:55:31:479 WSPConnect: Received 193 byte response from 193.113.200.195 12:55:31:479 WSPConnect: Packet Length is 193 bytes 12:55:31:479 WSPConnect: 12 80 06 02 81 C1 D8 F5 6B 0A 81 2B 04 80 8F F8 k + 12:55:31:479 WSPConnect: 00 04 81 8F F8 00 78 2D 75 70 2D 70 72 6F 78 79 x-up-proxy 12:55:31:479 WSPConnect: 2D 62 6F 6F 6B 6D 61 72 6B 00 68 74 74 70 3A 2F -bookmark http:/ 12:55:31:479 WSPConnect: 2F 62 65 6E 67 61 6C 2D 66 6D 61 67 63 67 69 33 /bengal-fmagcgi3 12:55:31:479 WSPConnect: 31 30 2E 6C 6F 6E 64 6F 6E 2E 30 32 2E 6E 65 74 10.london.02.net 12:55:31:479 WSPConnect: 2F 6D 61 72 6B 00 78 2D 75 70 2D 70 72 6F 78 79 /mark x-up-proxy 12:55:31:479 WSPConnect: 2D 75 70 6C 69 6E 6B 2D 76 65 72 73 69 6F 6E 00 -uplink-version 12:55:31:479 WSPConnect: 35 2E 31 2E 31 61 00 78 2D 75 70 2D 70 72 6F 78 5.1.1a x-up-prox 12:55:31:479 WSPConnect: 79 2D 68 6F 6D 65 2D 70 61 67 65 00 68 74 74 70 y-home-page http 12:55:31:479 WSPConnect: 3A 2F 2F 62 65 6E 67 61 6C 2D 66 6D 61 67 63 67 ://bengal-fmagcg 12:55:31:479 WSPConnect: 69 33 31 30 2E 6C 6F 6E 64 6F 6E 2E 30 32 2E 6E i310.london.02.n 12:55:31:479 WSPConnect: 65 74 2F 70 72 6F 76 69 73 69 6F 6E 2E 63 67 69 et/provision.cgi 12:55:31:479 WSPConnect: 00 12:55:31:479 WSPConnect: Packet Length is 3 bytes 12:55:31:479 WSPConnect: 18 00 06 12:55:31:479 WSPConnect: Gateway redirect to 193.113.200.151:49204 12:55:31:479 WSPDisconnect: Packet Length is 10 bytes 12:55:31:479 WSPDisconnect: 0A 00 07 12 05 81 C1 D8 F5 6B k 12:55:31:479 WSPRasDial: Connection to WAP gateway at 193.113.200.151:49204 OK! 12:55:32:494 WSPConnect: Sending 79 byte request to 193.113.200.151:49204 12:55:32:494 WSPConnect: Packet Length is 79 bytes 12:55:32:494 WSPConnect: 0A 00 08 12 01 10 0A 3D 04 80 8F F8 00 04 81 8F = 12:55:32:494 WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G 12:55:32:494 WSPConnect: 61 74 65 77 61 79 20 76 35 2E 30 00 80 83 80 61 ateway v5.0 a 12:55:32:494 WSPConnect: 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 pplication/vnd.w 12:55:32:494 WSPConnect: 61 70 2E 6D 6D 73 2D 6D 65 73 73 61 67 65 00 ap.mms-message 12:55:32:573 WSPConnect: Received 193 byte response from 193.113.200.151:49204 12:55:32:573 WSPConnect: Packet Length is 193 bytes 12:55:32:573 WSPConnect: 12 80 08 02 81 C1 D8 F5 73 0A 81 2B 04 80 8F F8 s + 12:55:32:573 WSPConnect: 00 04 81 8F F8 00 78 2D 75 70 2D 70 72 6F 78 79 x-up-proxy 12:55:32:573 WSPConnect: 2D 62 6F 6F 6B 6D 61 72 6B 00 68 74 74 70 3A 2F -bookmark http:/ 12:55:32:573 WSPConnect: 2F 62 65 6E 67 61 6C 2D 66 6D 61 67 63 67 69 33 /bengal-fmagcgi3 12:55:32:573 WSPConnect: 31 30 2E 6C 6F 6E 64 6F 6E 2E 30 32 2E 6E 65 74 10.london.02.net 12:55:32:573 WSPConnect: 2F 6D 61 72 6B 00 78 2D 75 70 2D 70 72 6F 78 79 /mark x-up-proxy 12:55:32:573 WSPConnect: 2D 75 70 6C 69 6E 6B 2D 76 65 72 73 69 6F 6E 00 -uplink-version 12:55:32:573 WSPConnect: 35 2E 31 2E 31 61 00 78 2D 75 70 2D 70 72 6F 78 5.1.1a x-up-prox 12:55:32:573 WSPConnect: 79 2D 68 6F 6D 65 2D 70 61 67 65 00 68 74 74 70 y-home-page http 12:55:32:573 WSPConnect: 3A 2F 2F 62 65 6E 67 61 6C 2D 66 6D 61 67 63 67 ://bengal-fmagcg 12:55:32:573 WSPConnect: 69 33 31 30 2E 6C 6F 6E 64 6F 6E 2E 30 32 2E 6E i310.london.02.n 12:55:32:573 WSPConnect: 65 74 2F 70 72 6F 76 69 73 69 6F 6E 2E 63 67 69 et/provision.cgi 12:55:32:573 WSPConnect: 00 12:55:32:573 WSPConnect: Packet Length is 3 bytes 12:55:32:573 WSPConnect: 18 00 08 12:55:32:573 WSPRequest: Accept: application/vnd.wap.mms-message 12:55:32:573 WSPRequest: 12:55:32:573 WSPRequest: Sending 97 bytes to 193.113.200.151:49204 12:55:32:573 WSPRequest: Packet Length is 97 bytes 12:55:32:573 WSPRequest: 0A 00 09 12 40 3A 68 74 74 70 3A 2F 2F 31 39 33 @:http://193 12:55:32:573 WSPRequest: 2E 31 31 33 2E 31 36 31 2E 31 3A 38 30 30 32 2F .113.161.1:8002/ 12:55:32:573 WSPRequest: 50 38 73 35 44 4D 46 78 6F 52 51 41 41 43 6D 58 P8s5DMFxoRQAACmX 12:55:32:573 WSPRequest: 41 41 41 41 41 77 41 41 43 34 4D 41 41 41 41 41 AAAAAwAAC4MAAAAA 12:55:32:573 WSPRequest: 80 61 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 application/vnd 12:55:32:573 WSPRequest: 2E 77 61 70 2E 6D 6D 73 2D 6D 65 73 73 61 67 65 .wap.mms-message 12:55:32:573 WSPRequest: 00 12:55:33:526 WSPRequest: Received 97 bytes from 193.113.200.151:49204 12:55:33:526 WSPRequest: Packet Length is 66 bytes 12:55:33:526 WSPRequest: 12 80 09 04 43 3C 00 AC 1F 38 8E 76 63 73 2D 66 C< 8 vcs-f 12:55:33:526 WSPRequest: 6D 61 67 64 69 73 70 33 31 35 2E 6C 6F 6E 64 6F magdisp315.londo 12:55:33:526 WSPRequest: 6E 2E 30 32 2E 6E 65 74 00 22 54 72 61 6E 73 66 n.02.net "Transf 12:55:33:526 WSPRequest: 6F 72 6D 61 74 69 6F 6E 20 41 70 70 6C 69 65 64 ormation Applied 12:55:33:526 WSPRequest: 22 00 " 12:55:33:526 WSPRequest: Sending 3 byte packet to 193.113.200.151:49204 12:55:33:526 WSPRequest: Packet Length is 3 bytes 12:55:33:526 WSPRequest: 18 00 09 12:55:33:526 WSPRequest: HTTP/1.0 403 Forbidden Content-type: application/x-x968-user-cert Content-length: 0 12:55:33:526 WSPDisconnect: Packet Length is 10 bytes 12:55:33:526 WSPDisconnect: 0A 00 0A 12 05 81 C1 D8 F5 73 s 12:55:33:526 WSPRasHangUp: NowSMS - Standard 19200 bps Modem which, if I read it correctly, means I have initiated a connection to the O2 MMSC (using the WAP gateway at 193.113.200.195), it redirects me to 193.113.200.151:49204. I ask it for the actual MMS (http://193.113.161.1:8002/...) and it says something about a "Transformation Applied" then HTTP/1.0 403 Forbidden and a (possibly unconnected) application/x-x968-user-cert This has me stumped. I did have the Gateway working with a T-mobile SIM, and this O2 SIM works fine in a phone. The MMS Receive "Test Connections" work (as I believe they just try the Redirect then stop). Any advice welcome. I expect I've done something stupid! :-) Cheers, Ian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1292 Registered: 10-2002 |
Ian, I believe I know exactly what's going wrong here. Unfortunately it looks like a bug, something that we are not handling correctly on a gateway redirect. We're going to have to get an update together, which hopefully we can do by the end of the week. In the meantime, you might be able to get around this problem by specifying 193.113.200.151 as the WAP Gateway IP address. Cheers! -bn | |||
| Ian Fitchet New member Username: Idf Post Number: 2 Registered: 12-2003 |
I believe I know exactly what's going wrong here. Unfortunately it looks like a bug, something that we are not handling correctly on a gateway redirect. A bug is good news! Well, it's not me anyway :-) In the meantime, you might be able to get around this problem by specifying 193.113.200.151 as the WAP Gateway IP address. I tried that and it worked a treat, thanks. I should say, as history to this, that I had had problems prior to this with the "Test Connection" (something to do with changing SIM and operator MMSC methinks). In that case the first gateway redirect was completely ignored. Despite the fact that it used to work with T-mobile (maybe they have changed some settings on their MMSC in the last month), I had seen another thread which referred to these redirects and I chanced my arm and changed my default gateway to the redirected IP addr and the "Test Connection" worked. I stopped using the redirected IP addr however as even at this stage I noticed that periodically it used a second redirect IP addr (simple load balancing for the operator MMSC?) and so this technique wouldn't work in the general case. I would have posted on that subject but leaving the system overnight then re-fiddling with the same parameters and it suddenly started reacting to the redirect leaving me in this situation. Cheers, Ian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1320 Registered: 10-2002 |
Ian, Yes, changing the WAP gateway setting was only a temporary work-around. I've uploaded an update to MMSWAP.DLL which will better handle the redirects. Please download it at http://www.nowsms.com/download/mmswap.zip. I believe this will fix your problem, but I haven't had a chance to test it with an O2 SIM yet, so let me know if you have any problems. | |||
| Ian Fitchet New member Username: Idf Post Number: 3 Registered: 12-2003 |
Bryce, Good of you to work so late! Alas, I get the same message (now tested with shorter content!  ) 17:24:29:469 GetCIDForAPN: Found CID=1 for APN wap.o2.co.uk 17:24:29:469 WSPRasDial: Before RasDial NowSMS - Standard 19200 bps Modem 17:24:38:047 WSPRasDial: RasDial connected to NowSMS - Standard 19200 bps Modem 17:24:38:063 WSPAddRoute: Routing 193.113.200.195 via 10.252.92.151 17:24:38:313 WSPConnect: Sending 44 byte request to 193.113.200.195 17:24:38:313 WSPConnect: Packet Length is 44 bytes 17:24:38:313 WSPConnect: 0A 00 01 12 01 10 0A 1A 04 80 8F F8 00 04 81 8F 17:24:38:313 WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G 17:24:38:313 WSPConnect: 61 74 65 77 61 79 20 76 35 2E 30 00 ateway v5.0 17:24:39:672 WSPConnect: Received 13 byte response from 193.113.200.195 17:24:39:672 WSPConnect: Packet Length is 13 bytes 17:24:39:672 WSPConnect: 12 80 01 03 40 C4 00 C0 30 C1 71 C8 98 @ 0 q 17:24:39:672 WSPAddRoute: Routing 193.113.200.152 via 10.252.92.151 17:24:39:719 WSPConnect: Sending 44 byte request to 193.113.200.195 17:24:39:719 WSPConnect: Packet Length is 44 bytes 17:24:39:719 WSPConnect: 0A 00 01 12 01 10 0A 1A 04 80 8F F8 00 04 81 8F 17:24:39:719 WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G 17:24:39:719 WSPConnect: 61 74 65 77 61 79 20 76 35 2E 30 00 ateway v5.0 17:24:41:094 WSPConnect: Received 159 byte response from 193.113.200.195 17:24:41:094 WSPConnect: Packet Length is 159 bytes 17:24:41:094 WSPConnect: 12 80 01 02 81 C4 F1 94 5E 0A 81 09 04 80 8F F8 ^ 17:24:41:094 WSPConnect: 00 04 81 8F F8 00 78 2D 75 70 2D 70 72 6F 78 79 x-up-proxy 17:24:41:094 WSPConnect: 2D 62 6F 6F 6B 6D 61 72 6B 00 68 74 74 70 3A 2F -bookmark http:/ 17:24:41:094 WSPConnect: 2F 66 6C 61 73 68 2E 6F 32 2E 63 6F 2E 75 6B 2F /flash.o2.co.uk/ 17:24:41:094 WSPConnect: 6D 61 72 6B 00 78 2D 75 70 2D 70 72 6F 78 79 2D mark x-up-proxy- 17:24:41:094 WSPConnect: 75 70 6C 69 6E 6B 2D 76 65 72 73 69 6F 6E 00 35 uplink-version 5 17:24:41:094 WSPConnect: 2E 31 2E 31 61 00 78 2D 75 70 2D 70 72 6F 78 79 .1.1a x-up-proxy 17:24:41:094 WSPConnect: 2D 68 6F 6D 65 2D 70 61 67 65 00 68 74 74 70 3A -home-page http: 17:24:41:094 WSPConnect: 2F 2F 66 6C 61 73 68 2E 6F 32 2E 63 6F 2E 75 6B //flash.o2.co.uk 17:24:41:094 WSPConnect: 2F 64 65 66 2F 77 61 70 72 65 64 69 72 78 00 /def/wapredirx 17:24:41:094 WSPConnect: Packet Length is 3 bytes 17:24:41:094 WSPConnect: 18 00 01 17:24:41:094 WSPConnect: Gateway redirect to 193.113.200.152:49200 17:24:41:094 WSPDisconnect: Packet Length is 10 bytes 17:24:41:094 WSPDisconnect: 0A 00 02 12 05 81 C4 F1 94 5E ^ 17:24:41:094 WSPRasDial: Connection to WAP gateway at 193.113.200.152:49200 OK! 17:24:42:094 WSPConnect: Sending 79 byte request to 193.113.200.152:49200 17:24:42:094 WSPConnect: Packet Length is 79 bytes 17:24:42:094 WSPConnect: 0A 00 03 12 01 10 0A 3D 04 80 8F F8 00 04 81 8F = 17:24:42:094 WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G 17:24:42:094 WSPConnect: 61 74 65 77 61 79 20 76 35 2E 30 00 80 83 80 61 ateway v5.0 a 17:24:42:094 WSPConnect: 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 pplication/vnd.w 17:24:42:094 WSPConnect: 61 70 2E 6D 6D 73 2D 6D 65 73 73 61 67 65 00 ap.mms-message 17:24:43:688 WSPConnect: Received 159 byte response from 193.113.200.152:49200 17:24:43:688 WSPConnect: Packet Length is 159 bytes 17:24:43:688 WSPConnect: 12 80 03 02 81 C4 F1 95 06 0A 81 09 04 80 8F F8 17:24:43:688 WSPConnect: 00 04 81 8F F8 00 78 2D 75 70 2D 70 72 6F 78 79 x-up-proxy 17:24:43:688 WSPConnect: 2D 62 6F 6F 6B 6D 61 72 6B 00 68 74 74 70 3A 2F -bookmark http:/ 17:24:43:688 WSPConnect: 2F 66 6C 61 73 68 2E 6F 32 2E 63 6F 2E 75 6B 2F /flash.o2.co.uk/ 17:24:43:688 WSPConnect: 6D 61 72 6B 00 78 2D 75 70 2D 70 72 6F 78 79 2D mark x-up-proxy- 17:24:43:688 WSPConnect: 75 70 6C 69 6E 6B 2D 76 65 72 73 69 6F 6E 00 35 uplink-version 5 17:24:43:688 WSPConnect: 2E 31 2E 31 61 00 78 2D 75 70 2D 70 72 6F 78 79 .1.1a x-up-proxy 17:24:43:688 WSPConnect: 2D 68 6F 6D 65 2D 70 61 67 65 00 68 74 74 70 3A -home-page http: 17:24:43:688 WSPConnect: 2F 2F 66 6C 61 73 68 2E 6F 32 2E 63 6F 2E 75 6B //flash.o2.co.uk 17:24:43:688 WSPConnect: 2F 64 65 66 2F 77 61 70 72 65 64 69 72 78 00 /def/wapredirx 17:24:43:688 WSPConnect: Packet Length is 3 bytes 17:24:43:688 WSPConnect: 18 00 03 17:24:43:688 WSPRequest: Content-length: 221 17:24:43:688 WSPRequest: Content-type: application/vnd.wap.mms-message 17:24:43:688 WSPRequest: Accept: application/vnd.wap.mms-message 17:24:43:688 WSPRequest: Cache-Control: No-Cache 17:24:43:688 WSPRequest: Œ€˜2BEFC6FE 17:24:43:688 WSPRequest: Sending 324 bytes to 193.113.200.152:49200 17:24:43:688 WSPRequest: Packet Length is 324 bytes 17:24:43:688 WSPRequest: 0A 00 04 12 60 1D 43 68 74 74 70 3A 2F 2F 6D 6D ` Chttp://mm 17:24:43:688 WSPRequest: 73 63 2E 6D 6D 73 2E 6F 32 2E 63 6F 2E 75 6B 3A sc.mms.o2.co.uk: 17:24:43:688 WSPRequest: 38 30 30 32 61 70 70 6C 69 63 61 74 69 6F 6E 2F 8002application/ 17:24:43:688 WSPRequest: 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D 65 73 73 vnd.wap.mms-mess 17:24:43:688 WSPRequest: 61 67 65 00 80 61 70 70 6C 69 63 61 74 69 6F 6E age application 17:24:43:688 WSPRequest: 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D 65 73 /vnd.wap.mms-mes 17:24:43:688 WSPRequest: 73 61 67 65 00 88 80 8C 80 98 32 42 45 46 43 36 sage 2BEFC6 17:24:43:688 WSPRequest: 46 45 00 8D 90 89 1A 80 6D 6F 62 69 74 61 73 74 FE mobitast 17:24:43:688 WSPRequest: 69 63 2E 63 6F 6D 2F 54 59 50 45 3D 50 4C 4D 4E ic.com/TYPE=PLMN 17:24:43:688 WSPRequest: 00 97 2B 34 34 37 39 34 34 39 39 32 33 33 34 2F +447944992334/ 17:24:43:688 WSPRequest: 54 59 50 45 3D 50 4C 4D 4E 00 96 74 65 73 74 69 TYPE=PLMN testi 17:24:43:688 WSPRequest: 6E 67 20 74 65 73 74 69 6E 67 00 86 81 84 A3 02 ng testing 17:24:43:688 WSPRequest: 20 15 83 C0 22 3C 33 46 44 34 42 33 43 31 2E 74 "<3FD4B3C1.t 17:24:43:688 WSPRequest: 78 74 3E 00 8E 33 46 44 34 42 33 43 31 2E 74 78 xt> 3FD4B3C1.tx 17:24:43:688 WSPRequest: 74 00 57 69 6C 6C 20 77 65 20 65 76 65 72 20 73 t Will we ever s 17:24:43:688 WSPRequest: 65 65 20 74 68 69 73 1A 31 9D C0 22 3C 61 72 72 ee this 1 "<arr 17:24:43:688 WSPRequest: 6F 77 2E 67 69 66 3E 00 8E 61 72 72 6F 77 2E 67 ow.gif> arrow.g 17:24:43:688 WSPRequest: 69 66 00 47 49 46 38 39 61 07 00 04 00 80 00 00 if GIF89a 17:24:43:688 WSPRequest: 00 00 00 FF FF FF 21 F9 04 01 00 00 01 00 2C 00 ! , 17:24:43:688 WSPRequest: 00 00 00 07 00 04 00 00 02 08 84 0F 81 19 6A 0D j 17:24:43:688 WSPRequest: 59 28 00 3B Y( ; 17:24:45:563 WSPRequest: Received 324 bytes from 193.113.200.152:49200 17:24:45:563 WSPRequest: Packet Length is 66 bytes 17:24:45:563 WSPRequest: 12 80 04 04 40 3C 00 AC 1F 38 8E 76 63 73 2D 66 @< 8 vcs-f 17:24:45:563 WSPRequest: 6D 61 67 64 69 73 70 33 31 35 2E 6C 6F 6E 64 6F magdisp315.londo 17:24:45:563 WSPRequest: 6E 2E 30 32 2E 6E 65 74 00 22 54 72 61 6E 73 66 n.02.net "Transf 17:24:45:563 WSPRequest: 6F 72 6D 61 74 69 6F 6E 20 41 70 70 6C 69 65 64 ormation Applied 17:24:45:563 WSPRequest: 22 00 " 17:24:45:563 WSPRequest: Sending 3 byte packet to 193.113.200.152:49200 17:24:45:563 WSPRequest: Packet Length is 3 bytes 17:24:45:563 WSPRequest: 18 00 04 17:24:45:563 WSPRequest: HTTP/1.0 400 Bad Request Content-type: application/x-x968-user-cert Content-length: 0 17:24:45:563 WSPDisconnect: Packet Length is 10 bytes 17:24:45:563 WSPDisconnect: 0A 00 05 12 05 81 C4 F1 95 06 17:24:45:579 WSPRasHangUp: NowSMS - Standard 19200 bps Modem I think the WSPAddRoute is new (so I'm using the new .dll) and there is some spurious output text on a WSPRequest line after cache-control -- for an older MMS the line looked related to the message contents which is hard to tell from those garbled characters. On a much larger MMS there were some Debug lines between packets. Untimately, though, it's still a status 400 and no obvious reason why. If I had gotton some basic APN/username/password details wrong they'd have shown up before sending any data? I get the impression that to be sending data I must have passed all the settings that I can enter in any of the NowSMS Gateway dialogs. (Just checking.) As a side road can you direct me at the specs for these messages so I can decode them? The WAP Forum name should be enough. Cheers, Ian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1343 Registered: 10-2002 |
Ian, Believe it or not, we're making progress. The error code changed. Change the MMS Server URL to: http://mmsc.mms.o2.co.uk:8002/ I think you have it right now without a slash. Which reminds me, one of the updates we still need to make is to automatically add this slash. (Some WAP gateways add it automatically, others respond with mysterious 400 series error codes.) So try changing that URL.
Normally, yes. The initial problem that you had was unusual because the O2 UK WAP gateway will accept anonymous connections over the internet. So this produced unusual results. Unfortunately, the one thing we can't validate in our test dialogs is the MMSC URL. Maybe we could try sending it a bogus MMS acknowledgement just to test to see if it responds.
WSP transactions (over WTP) are being exchanged with the WAP gateway. So those protocols are covered in the WSP and WTP documents. MMS message format uses a format defined in the MMS Encapsulation Specification (which also relies heavily on parts of the WSP specification). -bn | |||
| Ian Fitchet New member Username: Idf Post Number: 4 Registered: 12-2003 |
Always a good sign of progress!
Good spot! Here's the latest run, chopped down to the interesting bit: 23:06:24:725 WSPConnect: 18 00 03 23:06:24:725 WSPRequest: Content-length: 221 23:06:24:725 WSPRequest: Content-type: application/vnd.wap.mms-message 23:06:24:725 WSPRequest: Accept: application/vnd.wap.mms-message 23:06:24:725 WSPRequest: Cache-Control: No-Cache 23:06:24:725 WSPRequest: Œ€˜65AD1CD8 23:06:24:725 WSPRequest: Sending 325 bytes to 193.113.200.152:49205 23:06:24:725 WSPRequest: Packet Length is 325 bytes 23:06:24:725 WSPRequest: 0A 00 04 12 60 1E 43 68 74 74 70 3A 2F 2F 6D 6D ` Chttp://mm 23:06:24:725 WSPRequest: 73 63 2E 6D 6D 73 2E 6F 32 2E 63 6F 2E 75 6B 3A sc.mms.o2.co.uk: 23:06:24:725 WSPRequest: 38 30 30 32 2F 61 70 70 6C 69 63 61 74 69 6F 6E 8002/application 23:06:24:725 WSPRequest: 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D 65 73 /vnd.wap.mms-mes 23:06:24:725 WSPRequest: 73 61 67 65 00 80 61 70 70 6C 69 63 61 74 69 6F sage applicatio 23:06:24:725 WSPRequest: 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D 65 n/vnd.wap.mms-me 23:06:24:725 WSPRequest: 73 73 61 67 65 00 88 80 8C 80 98 36 35 41 44 31 ssage 65AD1 23:06:24:725 WSPRequest: 43 44 38 00 8D 90 89 1A 80 6D 6F 62 69 74 61 73 CD8 mobitas 23:06:24:725 WSPRequest: 74 69 63 2E 63 6F 6D 2F 54 59 50 45 3D 50 4C 4D tic.com/TYPE=PLM 23:06:24:725 WSPRequest: 4E 00 97 2B 34 34 37 39 34 34 39 39 32 33 33 34 N +447944992334 23:06:24:725 WSPRequest: 2F 54 59 50 45 3D 50 4C 4D 4E 00 96 74 65 73 74 /TYPE=PLMN test 23:06:24:725 WSPRequest: 69 6E 67 20 74 65 73 74 69 6E 67 00 86 81 84 A3 ing testing 23:06:24:725 WSPRequest: 02 20 15 83 C0 22 3C 33 46 44 34 42 33 43 31 2E "<3FD4B3C1. 23:06:24:725 WSPRequest: 74 78 74 3E 00 8E 33 46 44 34 42 33 43 31 2E 74 txt> 3FD4B3C1.t 23:06:24:725 WSPRequest: 78 74 00 57 69 6C 6C 20 77 65 20 65 76 65 72 20 xt Will we ever 23:06:24:725 WSPRequest: 73 65 65 20 74 68 69 73 1A 31 9D C0 22 3C 61 72 see this 1 "<ar 23:06:24:725 WSPRequest: 72 6F 77 2E 67 69 66 3E 00 8E 61 72 72 6F 77 2E row.gif> arrow. 23:06:24:725 WSPRequest: 67 69 66 00 47 49 46 38 39 61 07 00 04 00 80 00 gif GIF89a 23:06:24:725 WSPRequest: 00 00 00 00 FF FF FF 21 F9 04 01 00 00 01 00 2C ! , 23:06:24:725 WSPRequest: 00 00 00 00 07 00 04 00 00 02 08 84 0F 81 19 6A j 23:06:24:725 WSPRequest: 0D 59 28 00 3B Y( ; 23:06:26:069 WSPRequest: Received 325 bytes from 193.113.200.152:49205 23:06:26:069 WSPRequest: Packet Length is 66 bytes 23:06:26:069 WSPRequest: 12 80 04 04 43 3C 00 AC 1F 38 8E 76 63 73 2D 66 C< 8 vcs-f 23:06:26:069 WSPRequest: 6D 61 67 64 69 73 70 33 31 35 2E 6C 6F 6E 64 6F magdisp315.londo 23:06:26:069 WSPRequest: 6E 2E 30 32 2E 6E 65 74 00 22 54 72 61 6E 73 66 n.02.net "Transf 23:06:26:069 WSPRequest: 6F 72 6D 61 74 69 6F 6E 20 41 70 70 6C 69 65 64 ormation Applied 23:06:26:069 WSPRequest: 22 00 " 23:06:26:069 WSPRequest: Sending 3 byte packet to 193.113.200.152:49205 23:06:26:069 WSPRequest: Packet Length is 3 bytes 23:06:26:069 WSPRequest: 18 00 04 23:06:26:069 WSPRequest: HTTP/1.0 403 Forbidden Content-type: application/x-x968-user-cert Content-length: 0 But, following a recent foray into WAP Encoding and therefore trying to decifer the above, shouldn't there be a null then a header code after the MMSC URL and before the Content-Type/Accept MIME type string? As it stands, the two run into each other and you would naively think the URL was http://mmsc.mms.o2.co.uk:8002/application/vnd.wap.mms-message The second application/vnd.wap.mms-message is tagged with 0x80 (== Accept if I read Table 39 of WAP WSP correctly!) which means the first one is the content-type and should have a header of 0x8d. If the content-length (221) is being passed, shouldn't we also see an 0x91 0xdd somewhere in the soup, though since I don't quite understand it I guess the 221 could encapsulate the whole. As to decoding, I guess I've been reading the right document after all only I can't see the wood for the trees!  I guess I just need to find the section that tells me why there are three bytes at the start of each message! Cheers, Ian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1356 Registered: 10-2002 |
Ian, We'll get there yet. I might have made the wrong diagnosis on the initial 403 forbidden problem. Try this: Go to the "MMSC Routing" page. Highlight the route and press "Edit". Make sure that the "Default Sender Address" field is blank. Make sure that "Allow Sender Address Override" is NOT checked. Try again. (Also delete the current files from the VASPQ directory.) I think this will make a difference. We've had a bit of debate in this area. Typically an MMSC accepting messages over an MM1 via GPRS connection is not going to allow you to specify a sender address, and it is going to set the address to the phone's phone number. Most MMSCs ignore this field if it is set, and put in the phone's number ... but I suspect the O2 MMSC wants this left blank. Hopefully that will resolve the problem (and might explain a few other 403 errors that I've been seeing lately). A few comments on the encoding ... It's a bit confusing, but there's a length field that specifies how long the URL is. So it doesn't get null terminated.
Correct. That is an "Accept:" header, indicating that we accept "application/vnd.wap.mms-message" content in the response. The first instance is the content type for the post, but the PDU format has a fixed location for the content type field, so there is no header for it.
Well, it would actually get encoded slightly different from that, if it were included. The Content-Length parameter is encoded as an Integer-value, and since the value is larger than 127, it would be encoded as a Long-Integer. As it stands, then content length can be determined from the size of the PDU, so it is not actually included. We just make a note of it in our debug information.
It's the WTP header. Usually 4 bytes on an invoke, 3 bytes on a result (unless we get into larger messages with segmentation and reassembly where the WTP header can be variable sized). Thanks for your patience ... hopefully the above will sort the problem. -bn | |||
| Ian Fitchet New member Username: Idf Post Number: 6 Registered: 12-2003 |
That's the kiddie! Very subtle. Thank you. I've taken this long to reply as I was waiting on the outcome of sending an MMS back into the Gateway. I seem to have a problem there so I'll bring it up in a separate thread.
Hmm, back to WAP WSP 101 for me! :-)
Righto. More research required. Cheers, Ian | |||
| Gertjan de Back New member Username: Gdeback Post Number: 1 Registered: 01-2004 |
Hello, I use a different (custom built) setup but happen to get the same "Transformation Applied" responses from the exact same MMSC at O2. It is followed by Success (20) and "Message Delivered", but for some reason the operator sends an SMS instead of an MMS (though the phone is MMS capable and works fine when receiving multimedia messages from operators). Ethereal dump: Wireless Session Protocol PDU Type: Reply (0x04) Status: OK (0x20) Headers Length: 91 Content Type: application/vnd.wap.mms-message Headers Warning Warning Code: 14 Warning Agent: vcs-fmagdisp315.london.02.net Warning Text: "Transformation Applied" Data MMS Message Encapsulation Message-Type: m-send-conf (0x81) Transaction-ID: 1234 MMS-Version: 1.1 Response-Status: Ok (0x80) Response-Text: Message accepted Message-Id: QBpkVcFxoRQAABWHAAAABgAAqT4AAAAA 0000 45 00 00 bd 70 4e 00 00 fe 11 dd 56 c1 71 c8 e7 E...pN.....V.q.. 0010 0a 30 da 01 c0 33 04 43 00 a9 de e7 12 80 02 04 .0...3.C........ 0020 20 5b 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 6e [application/vn 0030 64 2e 77 61 70 2e 6d 6d 73 2d 6d 65 73 73 61 67 d.wap.mms-messag 0040 65 00 ac 1f 38 8e 76 63 73 2d 66 6d 61 67 64 69 e...8.vcs-fmagdi 0050 73 70 33 31 35 2e 6c 6f 6e 64 6f 6e 2e 30 32 2e sp315.london.02. 0060 6e 65 74 00 22 54 72 61 6e 73 66 6f 72 6d 61 74 net."Transformat 0070 69 6f 6e 20 41 70 70 6c 69 65 64 22 00 8c 81 98 ion Applied".... 0080 31 32 33 34 00 8d 91 92 80 93 4d 65 73 73 61 67 1234......Messag 0090 65 20 61 63 63 65 70 74 65 64 00 8b 51 42 70 6b e accepted..QBpk 00a0 56 63 46 78 6f 52 51 41 41 42 57 48 41 41 41 41 VcFxoRQAABWHAAAA 00b0 42 67 41 41 71 54 34 41 41 41 41 41 00 BgAAqT4AAAAA. Can anyone tell me what effect the "Default Sender Address" and "Allow Sender Address Override" settings is in the MMS message? I presume the first relates to the mmse.from field (0x89) but have no clue about the latter. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1766 Registered: 10-2002 |
The "Transformation applied" message is normal for responses from an Openwave WAP gateway (which is what O2 uses). It is not specific to MMS transactions, but seems to be present in other normal WAP transactions through the gateway. I guess it is a warning that the WAP gateway has to transform the content between WSP and HTTP (which is expected and normal). But I don't know why Openwave feels the need to include this in almost every response. In any event, I wouldn't worry about the "Transformation Applied".
Yes. "Default Sender Address" specifies the default value to be used for the sender address when NowSMS submits an MMS message through the specified interface. If NowSMS is processing an MMS message and needs to route it thorugh the specified interface, and there is no sender address included in the MMS message, the "Default Sender Address" will be inserted into the message. If "Allow Sender Address Override" is NOT checked, then this means that the "Default Sender Address" will ALWAYS be used. (Even if the sender address in the message is not blank.) Otherwise, if this box is checked, then the sender address in the submitted MMS will be used when submitting messages through this interface. When submitting via an MM1 interface over a GPRS modem, we recommend leaving the "Default Sender Address" field blank. And we recommand that "Allow Sender Address Override" NOT be checked. This means that we will submit messages without a sender address (setting the flags in the MMS encapsulation to tell the MMSC to insert the sender address). Now back to your core issue ...
What happens if you take the SIM out of the modem, and put the SIM into an MMS capable phone. If you send an MMS from that phone to the problem number through the O2 MMSC, is it also getting sent out as an SMS? I suspect that it will ... which takes the issue away from the examination of bits and bytes, and seems to point to some other configuration problem at one of the operators involved. It may be worth trying another O2 SIM to see if there is a pattern that all O2 MMS sends to that device go out as SMS messages ... indicating that for some reason O2 does not know that this is an MMS capable phone on one of the other UK operators. -bn | |||
