| Why the mm1 and mm4 auth error |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through July 28, 2006 ⬆ |
◄ ► |
| Author | Message | |||||||
| russell New member Username: Flosed Post Number: 11 Registered: 05-2005 |
I want to send mms by vasp to the /mm1 or /mm4 interface . but I always get HTTP/1.0 500 Internal Error the mmscdebug show "Unknow request : content type is unknown" but I could find from mmscdegug: "POST /mm1 HTTP/1.1 User-Agent:Jakarta Commons-HttpClient/3.0-rc4 Host: 192.168.10.131 Content-Length: 16152 Content-Type: application/vnd.wap.mms.message" what's wrong with it it seem it does't authenticate the request and treat it as a normal request . Of course could not find any resource for the request. Could any one help me ? Thanks | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5205 Registered: 10-2002 |
Hi Russell, You are not including any authentication in your request. Either include an "Authorization:" header that includes basic authentication credentials for an "MMSC VASP" account, or include the "MMSC VASP" credentials in the URL request (/mm1/vaspname=password). Posting to "/mm4" won't work ... MM4 is SMTP based, not HTTP based. MM7 is HTTP based. -bn | |||||||
| russell New member Username: Flosed Post Number: 12 Registered: 05-2005 |
thank you ,Bryce I modify my program as the second method you advised: 10:05:35:678 [9] ThreadProcessConnection: 50 4F 53 54 20 2F 6D 6D 31 2F 67 73 6D 6D 3D 67 POST /mm1/gsmm=g 10:05:35:678 [9] ThreadProcessConnection: 73 6D 6D 20 48 54 54 50 2F 31 2E 31 0D 0A 55 73 smm HTTP/1.1 Us 10:05:35:678 [9] ThreadProcessConnection: 65 72 2D 41 67 65 6E 74 3A 20 4A 61 6B 61 72 74 er-Agent: Jakart 10:05:35:678 [9] ThreadProcessConnection: 61 20 43 6F 6D 6D 6F 6E 73 2D 48 74 74 70 43 6C a Commons-HttpCl 10:05:35:678 [9] ThreadProcessConnection: 69 65 6E 74 2F 33 2E 30 2D 72 63 34 0D 0A 48 6F ient/3.0-rc4 Ho 10:05:35:678 [9] ThreadProcessConnection: 73 74 3A 20 31 39 32 2E 31 36 38 2E 31 30 2E 31 st: 192.168.10.1 10:05:35:678 [9] ThreadProcessConnection: 33 31 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 31 Content-Leng 10:05:35:678 [9] ThreadProcessConnection: 74 68 3A 20 31 36 31 35 32 0D 0A 43 6F 6E 74 65 th: 16152 Conte 10:05:35:678 [9] ThreadProcessConnection: 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 61 nt-Type: applica 10:05:35:678 [9] ThreadProcessConnection: 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 tion/vnd.wap.mms 10:05:35:678 [9] ThreadProcessConnection: 2E 6D 65 73 73 61 67 65 0D 0A 0D 0A 8C 84 98 36 .message 6 but I could get 10:05:35:748 [9] SendCommand: HTTP/1.0 500 Internal Error 10:05:35:748 [9] SendCommand: Content-Type: text/html 10:05:35:748 [9] SendCommand: Connection: close 10:05:35:748 [9] SendCommand: Date: Mon, 07 Nov 2005 02:05:35 GMT 10:05:35:748 [9] SendCommand: Expires: Mon, 07 Nov 2005 02:05:35 GMT 10:05:35:748 [9] SendCommand: 10:05:35:748 [9] SendCommand: <HTML><HEAD><TITLE> 10:05:35:748 [9] SendCommand: Unknown Request 10:05:35:748 [9] SendCommand: </TITLE></HEAD><BODY><H1> 10:05:35:748 [9] SendCommand: Unknown request: content type is unknown 10:05:35:748 [9] SendCommand: </H1></BODY></HTML> 10:05:35:748 [9] ThreadProcessConnection: Processing Complete as usual , BTW: my credential program works well in the mm7 interface. And I use the mm4 interface as indicatied in the guide. But I could find nothing in the debug . as the mail info have never come in. | |||||||
| russell New member Username: Flosed Post Number: 13 Registered: 05-2005 |
first of all , the mm4 interface works. But I got a unwanted subject ended with <nowsms.smil> in my siemens S65 cell phone even after I disable the notification subjecgt in the mmsc.ini uncoded from the mm1 file ,I find the content-type in the head field is "application/vnd.wap.mms.message Type = application/smil Start=<nowsms.smil>" I believe it's the additional "Type = application/smil Start=<nowsms.smil>" cause the problem .How could I remove them? Please ! {another suggestion : could you add the function the author can modify his post. I have to append another post in order to discribe the new progress which will mess the post } | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5221 Registered: 10-2002 |
Hi Russell, Regarding the MM1 problem, you're posting to the wrong server. You need to post to the HTTP port of the MMSC. Not the "Web port" of the SMS gateway. Regarding the MM4 interface and extra parts of the subject line, I need more information. I need to see exactly what the data is that is being sent to the server. -bn P.S. - Sorry, the bulletin board system here is a bit fragile. If you have sensitive information that needs to be deleted from a prior post, advise, and we will delete. In general for troubleshooting purposes, we find it helpful to go back and view the earlier information. | |||||||
| russell New member Username: Flosed Post Number: 14 Registered: 05-2005 |
Hi Bryce: I am sure I use the mmsc web port: [MMSC] WebPort=80 SMTPPort=25 My code below( apache httpclient 3.0rc4) PostMethod httppost = new PostMethod("http://*.80.*.10:80/mm1/gsm=gsm"); The debug info I found from the mmscdebug.log I don't know why .I try to access the mm1 and mm7 realm in the IE explorer. I could get nothing when I access mm1,but get credential pop-up when access mm7. As to the mm4
Please help .It don't work in nokia 7650 too. And could you be kind to help the another two session http://support.nowsms.com/discus/messages/485/11955.html http://support.nowsms.com/discus/messages/485/11285.html Thank you very much | |||||||
| russell New member Username: Flosed Post Number: 15 Registered: 05-2005 |
hi , Bryce: now I know what's wrong with mm4 It works after I change the format of mail from html to normal text. Thanks And many other questions:  1 I can not remove the subject even add the MMSNotificationNoSubject=Yes in the MMSC.ini 2 how many recipients could the be included in the mm1/mm4/mm7 request 3 I have tried the mmscomp , It seem the encoding setting does not work , If the text file is not saved as utf-8 format, text will not display correctly in my cell phone even after add the -cutf-8 parameter.does that means the -cutf-8 para just indicate the format of text file . Never convert the original text format to the utf-8 format? | |||||||
| russell New member Username: Flosed Post Number: 16 Registered: 05-2005 |
hi Bryce, Please help,Thanks !!!! | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5232 Registered: 10-2002 |
Hi Russell, For the MM1 and MM7 problems, I can't help you without an MMSCDEBUG.LOG. In order to answer your question, I need to see exactly what data is being presented to the server. For the other questions: 1.) This setting only controls whether or not the subject is included in the MMS Notification message that is sent out over SMS/WAP Push. The subject will still be present in the MMS message itself. 2.) We've only tested to 10,000. Larger values are supported, but timeout errors are more likely to occur in your application when sending to larger numbers of recipients. If submitting to a large number of recipients, use relaxed timeout settings for awaiting an HTTP response of confirmation. I would not suggest using the MM1 interface for submitting to large numbers of recipients in a single submission. Use MM4 or MM7. 3.) The -cUTF-8 parameter does not cause any conversion to be performed. It only forces the character set header in the message to indicate UTF-8. -bn | |||||||
| russell New member Username: Flosed Post Number: 17 Registered: 05-2005 |
hi Bryce, Thank you here is the info in the mmscdebuga below it test in opera 8.5,input http://127.0.0.1:80/mm7 ,(80 is port of mmsc service) the first time I access mm7: 10:51:07:457 [9] ThreadProcessConnection: Processing connection from 127.0.0.1... 10:51:07:457 [9] ThreadProcessConnection: Packet Length is 424 bytes 10:51:07:457 [9] ThreadProcessConnection: 47 45 54 20 2F 6D 6D 37 20 48 54 54 50 2F 31 2E GET /mm7 HTTP/1. 10:51:07:457 [9] ThreadProcessConnection: 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 1 User-Agent: M 10:51:07:457 [9] ThreadProcessConnection: 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 ozilla/4.0 (comp 10:51:07:467 [9] ThreadProcessConnection: 61 74 69 62 6C 65 3B 20 4D 53 49 45 20 36 2E 30 atible; MSIE 6.0 ......... 10:51:07:467 [9] ThreadProcessConnection: 64 69 6E 67 3A 20 64 65 66 6C 61 74 65 2C 20 67 ding: deflate, g 10:51:07:467 [9] ThreadProcessConnection: 7A 69 70 2C 20 78 2D 67 7A 69 70 2C 20 69 64 65 zip, x-gzip, ide 10:51:07:467 [9] ThreadProcessConnection: 6E 74 69 74 79 2C 20 2A 3B 71 3D 30 0D 0A 43 6F ntity, *;q=0 Co 10:51:07:467 [9] ThreadProcessConnection: 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 nnection: Keep-A 10:51:07:467 [9] ThreadProcessConnection: 6C 69 76 65 0D 0A 0D 0A live 10:51:07:507 [9] ProcessMM7Request: Requesting authorisation credentials 10:51:07:507 [9] SendCommand: HTTP/1.0 401 Auth Required 10:51:07:507 [9] SendCommand: WWW-Authenticate: Basic realm=MM7 10:51:07:507 [9] SendCommand: 10:51:07:507 [9] ThreadProcessConnection: Processing Complete after inputing right password in the popup: 10:53:24:083 [9] ThreadProcessConnection: Processing connection from 127.0.0.1... 10:53:24:103 [9] ThreadProcessConnection: Packet Length is 511 bytes 10:53:24:103 [9] ThreadProcessConnection: 47 45 54 20 2F 6D 6D 37 20 48 54 54 50 2F 31 2E GET /mm7 HTTP/1. 10:53:24:113 [9] ThreadProcessConnection: 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 1 User-Agent: M 10:53:24:113 [9] ThreadProcessConnection: 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 ozilla/4.0 (comp 10:53:24:113 [9] ThreadProcessConnection: 61 74 69 62 6C 65 3B 20 4D 53 49 45 20 36 2E 30 atible; MSIE 6.0 ............ 10:53:24:113 [9] ThreadProcessConnection: 30 2E 31 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F 0.1 Accept-Enco 10:53:24:113 [9] ThreadProcessConnection: 64 69 6E 67 3A 20 64 65 66 6C 61 74 65 2C 20 67 ding: deflate, g 10:53:24:113 [9] ThreadProcessConnection: 7A 69 70 2C 20 78 2D 67 7A 69 70 2C 20 69 64 65 zip, x-gzip, ide 10:53:24:113 [9] ThreadProcessConnection: 6E 74 69 74 79 2C 20 2A 3B 71 3D 30 0D 0A 41 75 ntity, *;q=0 Au 10:53:24:113 [9] ThreadProcessConnection: 74 68 6F 72 69 7A 61 74 69 6F 6E 3A 20 42 61 73 thorization: Bas 10:53:24:113 [9] ThreadProcessConnection: 69 63 20 5A 33 4E 74 62 54 70 6E 63 32 31 74 0D ic Z3NtbTpnc21t 10:53:24:113 [9] ThreadProcessConnection: 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 Connection: Kee 10:53:24:113 [9] ThreadProcessConnection: 70 2D 41 6C 69 76 65 2C 20 54 45 0D 0A 54 45 3A p-Alive, TE TE: 10:53:24:113 [9] ThreadProcessConnection: 20 64 65 66 6C 61 74 65 2C 20 67 7A 69 70 2C 20 deflate, gzip, 10:53:24:113 [9] ThreadProcessConnection: 63 68 75 6E 6B 65 64 2C 20 69 64 65 6E 74 69 74 chunked, identit 10:53:24:113 [9] ThreadProcessConnection: 79 2C 20 74 72 61 69 6C 65 72 73 0D 0A 0D 0A y, trailers 10:53:24:123 [9] ProcessMM7Request: HTTP/1.0 200 OK Content-Length: 695 Content-Type: text/xml Connection: close 10:53:24:123 [9] ProcessMM7Request: <?xml version="1.0" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2" env:mustUnderstand="1">unknown </mm7:TransactionID> </env:Header> <env:Body> <RSErrorRsp xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"> <MM7Version>5.3.0</MM7Version> <Status> <StatusCode>4003</StatusCode> <StatusText>Unsupported Operation</StatusText> <Details>HTTP GET not supported on MM7 interface</Details> </Status> </RSErrorRsp> </env:Body> </env:Envelope> 10:53:24:183 [9] ThreadProcessConnection: Processing Complete We can see it pass the auth ,the mm7 service don't response the illigal http get request . That's correct. But everytime I acccess the mm1: input http://127.0.0.1:80/mm1 ,(80 is port of mmsc service) 10:55:50:013 [9] ThreadProcessConnection: Processing connection from 127.0.0.1... 10:55:50:013 [9] ThreadProcessConnection: Packet Length is 511 bytes 10:55:50:013 [9] ThreadProcessConnection: 47 45 54 20 2F 6D 6D 31 20 48 54 54 50 2F 31 2E GET /mm1 HTTP/1. 10:55:50:013 [9] ThreadProcessConnection: 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 1 User-Agent: M 10:55:50:013 [9] ThreadProcessConnection: 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 ozilla/4.0 (comp 10:55:50:013 [9] ThreadProcessConnection: 61 74 69 62 6C 65 3B 20 4D 53 49 45 20 36 2E 30 atible; MSIE 6.0 .......... 10:55:50:023 [9] ThreadProcessConnection: 64 69 6E 67 3A 20 64 65 66 6C 61 74 65 2C 20 67 ding: deflate, g 10:55:50:023 [9] ThreadProcessConnection: 7A 69 70 2C 20 78 2D 67 7A 69 70 2C 20 69 64 65 zip, x-gzip, ide 10:55:50:023 [9] ThreadProcessConnection: 6E 74 69 74 79 2C 20 2A 3B 71 3D 30 0D 0A 41 75 ntity, *;q=0 Au 10:55:50:023 [9] ThreadProcessConnection: 74 68 6F 72 69 7A 61 74 69 6F 6E 3A 20 42 61 73 thorization: Bas 10:55:50:023 [9] ThreadProcessConnection: 69 63 20 5A 33 4E 74 62 54 70 6E 63 32 31 74 0D ic Z3NtbTpnc21t 10:55:50:023 [9] ThreadProcessConnection: 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 Connection: Kee 10:55:50:023 [9] ThreadProcessConnection: 70 2D 41 6C 69 76 65 2C 20 54 45 0D 0A 54 45 3A p-Alive, TE TE: 10:55:50:023 [9] ThreadProcessConnection: 20 64 65 66 6C 61 74 65 2C 20 67 7A 69 70 2C 20 deflate, gzip, 10:55:50:023 [9] ThreadProcessConnection: 63 68 75 6E 6B 65 64 2C 20 69 64 65 6E 74 69 74 chunked, identit 10:55:50:023 [9] ThreadProcessConnection: 79 2C 20 74 72 61 69 6C 65 72 73 0D 0A 0D 0A y, trailers 10:55:50:023 [9] ThreadProcessConnection: HTTP/1.1 404 Not Found Content-Length: 0 Connection: Keep-Alive 10:55:51:074 [9] ProcessRead: Winsock:ioctlsocket reports end of socket 10:55:51:074 [9] ThreadProcessConnection: Processing Complete socket connection is broken by the server. below is result of my program (httpclient from apache ) connecting to the mm1 or mm1/user=pass at 80 port 11:58:17:441 [9] ThreadProcessConnection: Processing connection from 192.168.10.131... 11:58:17:441 [9] ThreadProcessConnection: Packet Length is 8242 bytes 11:58:17:441 [9] ThreadProcessConnection: 50 4F 53 54 20 2F 6D 6D 31 2F 20 48 54 54 50 2F POST /mm1/ HTTP/ 11:58:17:441 [9] ThreadProcessConnection: 31 2E 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 1.1 User-Agent: 11:58:17:441 [9] ThreadProcessConnection: 20 4A 61 6B 61 72 74 61 20 43 6F 6D 6D 6F 6E 73 Jakarta Commons 11:58:17:441 [9] ThreadProcessConnection: 2D 48 74 74 70 43 6C 69 65 6E 74 2F 33 2E 30 2D -HttpClient/3.0- 11:58:17:441 [9] ThreadProcessConnection: 72 63 34 0D 0A 48 6F 73 74 3A 20 31 39 32 2E 31 rc4 Host: 192.1 11:58:17:441 [9] ThreadProcessConnection: 36 38 2E 31 30 2E 31 33 31 0D 0A 43 6F 6E 74 65 68.10.131 Conte 11:58:17:441 [9] ThreadProcessConnection: 6E 74 2D 4C 65 6E 67 74 68 3A 20 38 30 38 30 0D nt-Length: 8080 11:58:17:441 [9] ThreadProcessConnection: 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 61 Content-Type: a 11:58:17:441 [9] ThreadProcessConnection: 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 pplication/vnd.w 11:58:17:441 [9] ThreadProcessConnection: 61 70 2E 6D 6D 73 2E 6D 65 73 73 61 67 65 0D 0A ap.mms.message 11:58:17:441 [9] ThreadProcessConnection: 0D 0A 8C 84 98 37 33 37 39 30 34 33 42 00 8D 90 7379043B 11:58:17:441 [9] ThreadProcessConnection: 8B 32 30 30 35 31 31 30 37 2F 31 33 2F 37 33 37 20051107/13/737 ............... 11:58:17:471 [9] ThreadProcessConnection: FF D9 11:58:17:471 [9] SendCommand: HTTP/1.0 500 Internal Error 11:58:17:481 [9] SendCommand: Content-Type: text/html 11:58:17:481 [9] SendCommand: Connection: close 11:58:17:481 [9] SendCommand: Date: Thu, 10 Nov 2005 03:58:17 GMT 11:58:17:481 [9] SendCommand: Expires: Thu, 10 Nov 2005 03:58:17 GMT 11:58:17:481 [9] SendCommand: 11:58:17:481 [9] SendCommand: <HTML><HEAD><TITLE> 11:58:17:481 [9] SendCommand: Unknown Request 11:58:17:481 [9] SendCommand: </TITLE></HEAD><BODY><H1> 11:58:17:481 [9] SendCommand: Unknown request: content type is unknown 11:58:17:481 [9] SendCommand: </H1></BODY></HTML> 11:58:17:481 [9] ThreadProcessConnection: Processing Complete no auth is needed when I access the mm1 and it identify the content-type as the text/xml not the "application/vnd.wap.mms.message" I indicate in the http head And another question: with the mm4 interface , the mms always encapsulated as a related mms with a smil file . is there any approach to get a mixed mms? According to popular apprehension ,phones supporting smil mms are less than phones support mixed mms. We'd better give the subscribers the mixed format once we don't know the type of their cell phone . Am I right? And could you be kind to help the another two session http://support.nowsms.com/discus/messages/485/11955 .html http://support.nowsms.com/discus/messages/485/11285 .html Thank you very much | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5245 Registered: 10-2002 |
Hi Russell, I don't understand why you are issuing GET requests against /MM1 and /MM7. I guess it's just for testing. But there are no valid operations you can do to either of these URLs with an HTTP GET, so it doesn't matter whether you get auth requested or a 404 error in response. Regarding the actual MM1 error, the problem is that you are not using the correct content type for MMS. The content type is "application/vnd.wap.mms-message", not "application/vnd.wap.mms.message". That is why we are complaining that the content type is unknown ... I'm sorry that I didn't spot that sooner, but that is the problem. I'm doing my best to get caught up on other message postings out here, so hopefully I will get to your other questions soon. -bn | |||||||
| russell New member Username: Flosed Post Number: 18 Registered: 05-2005 |
Hi Bryce: Regarding mm1 issue: I have changed the content-type .But I got : 13:56:10:300 [10] ThreadProcessConnection: FF D9 13:56:10:300 [10] ThreadProcessConnection: Got application/vnd.wap.mms-message 13:56:10:300 [10] ThreadProcessConnection: Got m-retrieve-conf 13:56:10:300 [10] ThreadProcessConnection: HTTP/1.1 200 OK Connection: Keep-Alive Content-Type: */* Content-Length: 0 13:56:10:781 [10] ProcessRead: Winsock:ioctlsocket reports end of socket 13:56:10:781 [10] ThreadProcessConnection: Processing Complete what's wrong now ? Regarding mm4 issue: can I use the mixed mms format without smil file instead of related mms format when I submit message using mm4 interface. Thank you!!! | |||||||
| John Carter Unregistered guest |
Bryce, I've tried using jmeter and the content-type that you suggested "application/vnd.wap.mms-message" and still get the same problem as russell. Looking at ethereal dumps it looks like an MM1 retreive request does not need to have Content-type set. If I telnet to port 80 and set type in the GET request I get a correct response. Unfortunately I can't find a way to turn Content-type off using jmeter and I have to set it to some value. Any other suggestions as to a valid Content-Type? | |||||||
| John Carter Unregistered guest |
Bryce, to follow up my previous posting. Here is a dump of the HTTP session and the error message: GET /20051117/14/8208FB5E.mms HTTP/1.1 Connection: keep-alive User-Agent: LG/U8120/v1.0 Accept: */*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 msisdn: 61400123456 x-wap-profile: "http://fr.lge.com/gsm/LG-U8110.xml" Content-type: application/vnd.wap.mms-message Host: 192.168.2.48 returns ------ HTTP/1.0 500 Internal Error Content-Type: text/html Connection: close Date: Thu, 17 Nov 2005 10:26:51 GMT Expires: Thu, 17 Nov 2005 10:26:51 GMT <HTML><HEAD><TITLE> Unknown Request </TITLE></HEAD><BODY><H1> Unknown request: content type is unknown </H1></BODY></HTML> | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5252 Registered: 10-2002 |
Russell, You are attempting to submit an MM1 message that is in "m-retrieve.conf" format. "m-retrieve.conf" format is the format of an MMS message that is being received from an MMSC. (And essentially, the MMSC is ignoring it.) For submitting a message to an MMSC using MM1 you must use "m-send.req" format. -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5253 Registered: 10-2002 |
John, I don't think your problem is related. An HTTP GET request should not include a "Content-type:" header. Including a "Content-type:" header signals that you are including content with your request. The MMSC is getting confused because it thinks you are trying to submit "application/vnd.wap.mms-message" content, but the content is missing. Anyway, there is an update to NowSMS which ignores "Content-type:" headers in HTTP GET requests, because we have encountered this elsewhere. You can download the latest update for NowSMS v5.51 at the following link: http://www.nowsms.com/download/latestpatch.zip -bn | |||||||
| John Carter Unregistered guest |
Thank Bryce, that's fixed the content-type problem. I'm now getting "MSISDN does not match message recipient" when I attempt to retreive the MMS using jmeter (or a web browser). I think I have set the correct msisdn header in jmeter. SUBMIT --------------------------- 12:44:56:633 [7] Processing connection from 192.168.2.51... 12:44:56:649 [7] Packet Length is 31215 bytes 12:44:56:649 [7] 50 4F 53 54 20 2F 74 65 73 74 3D 74 65 73 74 20 POST /test=test 12:44:56:649 [7] 48 54 54 50 2F 31 2E 31 0D 0A 43 6F 6E 74 65 6E HTTP/1.1 Conten 12:44:56:649 [7] 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 61 74 t-Type: applicat 12:44:56:649 [7] 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D ion/vnd.wap.mms- 12:44:56:649 [7] 6D 65 73 73 61 67 65 0D 0A 43 6F 6E 74 65 6E 74 message Content 12:44:56:649 [7] 2D 4C 65 6E 67 74 68 3A 20 33 30 39 37 39 0D 0A -Length: 30979 12:44:56:649 [7] 55 73 65 72 2D 41 67 65 6E 74 3A 20 4A 61 76 61 User-Agent: Java 12:44:56:649 [7] 2F 31 2E 34 2E 32 5F 30 35 0D 0A 48 6F 73 74 3A /1.4.2_05 Host: 12:44:56:649 [7] 20 31 39 32 2E 31 36 38 2E 32 2E 32 37 3A 38 30 192.168.2.27:80 12:44:56:649 [7] 38 30 0D 0A 41 63 63 65 70 74 3A 20 74 65 78 74 80 Accept: text 12:44:56:649 [7] 2F 68 74 6D 6C 2C 20 69 6D 61 67 65 2F 67 69 66 /html, image/gif 12:44:56:649 [7] 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C 20 2A 3B , image/jpeg, *; 12:44:56:649 [7] 20 71 3D 2E 32 2C 20 2A 2F 2A 3B 20 71 3D 2E 32 q=.2, */*; q=.2 12:44:56:649 [7] 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 Connection: ke 12:44:56:649 [7] 65 70 2D 61 6C 69 76 65 0D 0A 0D 0A 8C 80 8D 90 ep-alive 12:44:56:649 [7] 85 04 43 7E 83 72 89 17 80 36 31 34 31 36 39 30 C~ r 6141690 12:44:56:649 [7] 37 31 39 30 2F 54 59 50 45 3D 50 4C 4D 4E 00 97 7190/TYPE=PLMN 12:44:56:649 [7] 36 31 34 31 36 31 35 35 35 37 38 2F 54 59 50 45 61416155578/TYPE 12:44:56:649 [7] 3D 50 4C 4D 4E 00 96 54 68 69 73 20 69 73 20 61 =PLMN This is a 12:44:56:649 [7] 20 6E 69 63 65 20 6D 65 73 73 61 67 65 21 21 00 nice message!! RETRIEVE -------------------------------------- 12:47:57:960 [7] Processing connection from 192.168.2.27... 12:47:57:960 [7] Packet Length is 370 bytes 12:47:57:960 [7] 47 45 54 20 2F 32 30 30 35 31 31 31 39 2F 31 32 GET /20051119/12 12:47:57:960 [7] 2F 39 43 39 33 42 36 37 43 2E 4D 4D 53 20 48 54 /9C93B67C.MMS HT 12:47:57:960 [7] 54 50 2F 31 2E 31 0D 0A 43 6F 6E 6E 65 63 74 69 TP/1.1 Connecti 12:47:57:960 [7] 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A on: keep-alive 12:47:57:960 [7] 55 73 65 72 2D 41 67 65 6E 74 3A 20 4C 47 2F 55 User-Agent: LG/U 12:47:57:960 [7] 38 31 32 30 2F 76 31 2E 30 0D 0A 41 63 63 65 70 8120/v1.0 Accep 12:47:57:960 [7] 74 3A 20 2A 2F 2A 3B 71 3D 30 2E 35 0D 0A 41 63 t: */*;q=0.5 Ac 12:47:57:960 [7] 63 65 70 74 2D 4C 61 6E 67 75 61 67 65 3A 20 65 cept-Language: e 12:47:57:960 [7] 6E 2D 75 73 2C 65 6E 3B 71 3D 30 2E 35 0D 0A 41 n-us,en;q=0.5 A 12:47:57:960 [7] 63 63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 ccept-Encoding: 12:47:57:960 [7] 67 7A 69 70 2C 64 65 66 6C 61 74 65 0D 0A 41 63 gzip,deflate Ac 12:47:57:960 [7] 63 65 70 74 2D 43 68 61 72 73 65 74 3A 20 49 53 cept-Charset: IS 12:47:57:960 [7] 4F 2D 38 38 35 39 2D 31 2C 75 74 66 2D 38 3B 71 O-8859-1,utf-8;q 12:47:57:960 [7] 3D 30 2E 37 2C 2A 3B 71 3D 30 2E 37 0D 0A 6D 73 =0.7,*;q=0.7 ms 12:47:57:960 [7] 69 73 64 6E 3A 20 36 31 34 31 36 31 35 35 35 37 isdn: 6141615557 12:47:57:960 [7] 38 0D 0A 78 2D 77 61 70 2D 70 72 6F 66 69 6C 65 8 x-wap-profile 12:47:57:960 [7] 3A 20 22 68 74 74 70 3A 2F 2F 66 72 2E 6C 67 65 : "http://fr.lge 12:47:57:960 [7] 2E 63 6F 6D 2F 67 73 6D 2F 4C 47 2D 55 38 31 31 .com/gsm/LG-U811 12:47:57:960 [7] 30 2E 78 6D 6C 22 0D 0A 43 6F 6E 74 65 6E 74 2D 0.xml" Content- 12:47:57:960 [7] 74 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F type: applicatio 12:47:57:960 [7] 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D 65 n/vnd.wap.mms-me 12:47:57:960 [7] 73 73 61 67 65 0D 0A 48 6F 73 74 3A 20 31 39 32 ssage Host: 192 12:47:57:960 [7] 2E 31 36 38 2E 32 2E 32 37 3A 38 30 38 30 0D 0A .168.2.27:8080 12:47:57:960 [7] 0D 0A 12:47:57:960 [7] C:\PROGRA~1\NowSMS\MMSCDATA\20051119/12/9C93B67C.INI 12:47:57:960 [7] MSISDN does not match message recipient 12:48:02:948 [7] HTTP/1.1 404 Not Found Content-Length: 0 Connection: Keep-Alive } | |||||||
| russell New member Username: Flosed Post Number: 19 Registered: 05-2005 |
Thank you Bryce: Let's continue mm4 issue: can I use the mixed mms format without smil file instead of related mms format when I submit message using mm4 interface？ And I find another bugs: sending multi message through mm7 interface . 1 when I submit a 20 character non-english subject (each character cost 2-3 bytes in unicode)mms using utf-8 encoding,the subject will be abnomal but It works fine when I shorten the subject to 16 character . And the 20 size subject works fine when submit 3 recipients but corruupt in 4 recipients submit. here is the mms and ini file
2 when I sumbit 100 or more recipient in one submit . Nowsms seem to mess up my recipients info such as 501533140=Pending 501533175=Pending 501533203= =Pending 501533078=Pending 501533107=Pending 501532= 467=Pending 501533348=Pending 501533346=Pending 501= 533386=Pending mmscdebug log : 14:26:02:745 [10] MMSRoutingCallback: 501533203= /TYPE=PLMN 14:26:02:745 [10] MMSRoutingCallback: 501533203= /TYPE=PLMN 14:26:02:745 [10] MMSRoutingCallback: 501533078/TYPE=PLMN 14:26:02:745 [10] MMSRoutingCallback: 501533078/TYPE=PLMN 14:26:02:745 [10] MMSRoutingCallback: 501533107/TYPE=PLMN 14:26:02:745 [10] MMSRoutingCallback: 501533107/TYPE=PLMN 14:26:02:745 [10] MMSRoutingCallback: 501532= 467/TYPE=PLMN 14:26:02:755 [10] MMSRoutingCallback: 501532= 467/TYPE=PLMN 14:26:02:755 [10] MMSRoutingCallback: 501533348/TYPE=PLMN 14:26:02:755 [10] MMSRoutingCallback: 501533348/TYPE=PLMN 14:26:02:755 [10] MMSRoutingCallback: 501533346/TYPE=PLMN 14:26:02:755 [10] MMSRoutingCallback: 501533346/TYPE=PLMN 14:26:02:755 [10] MMSRoutingCallback: 501= 533386/TYPE=PLMN It seems Nowsms cut the 9 digit number randomly.Please help me . | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5275 Registered: 10-2002 |
John, That is a security check, intended just to help reduce the possibility of sniffing valid message URLs. It looks like you are trying to retrieve the message by building your own URL based upon the retrieved message id ... instead of using the URL that is sent out in the actual MMS notification. You can disable this particular check by editing MMSC.INI, and under the [MMSC] header, add MSISDNMatchRequiredForReceive=No. -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5276 Registered: 10-2002 |
Russell, Please include MMSCDEBUG.LOGs when you submit any of these problem reports. And I'd prefer them to be complete logs. Otherwise, it takes me far too long to understand what you are asking. Regarding your questions:
Yes. If there is a SMIL file included, we will automatically convert the message to multipart/related and reference the included SMIL. If there is not a SMIL file included, we will automatically generate one, and convert to multipart/related referencing the auto-generated SMIL. (SMIL auto-generation is only performed via the MM4 interface, so that the interface can also accept generic SMTP messages.)
Another? I'll give you the benefit of the doubt until I read the rest of your message. But I will point out that so far, you have not found any bugs. The problems so far have been errors in your submission attempts, not bugs on our end.
I need to see an MMSCDEBUG.LOG so that I can see the exact data that you are submitting in your request.
There is not a 100 recipient limit. But again, I would need to see an MMSCDEBUG.LOG so that I can see exactly what data you are submitting in your request. I see some strange placement of "=" signs and line breaks in the information that you have included above. But because this discussion board software does some text reformatting, I'm not sure if those entries were present in your logs or not. I'm guessing that maybe the data being submitted used quoted printable encoding. We support quoted printable and base64 encoding on the content of an MM7 submission. However, we do not support any alternative encoding on the XML portion of the submission. It would help me to see the MMSCDEBUG.LOG portion that shows the exact data being submitted, because otherwise I can only guess. -bn | |||||||
| russell New member Username: Flosed Post Number: 20 Registered: 05-2005 |
sorry  Bryce: I found what's wrong with the last two questions.It is the openwave mms sdk 's encoding that could mess up once the recipients are more than 4. Thank you for your patient response and fogive my arbitrary judgement. Regarding to mm4 issue: I notice that nowsms will add corresponding smil file once there are only image and text attachement in email.What I want to know is that is there possibility that nowsms compose a mixed mms instead of composing a related mms when using mm4 interface. | |||||||
| russell New member Username: Flosed Post Number: 21 Registered: 05-2005 |
And another question related to mm1,please I have change the setting according to the post below: http://support.nowsms.com/discus/messages/485/5890.html [MMSWAP] SarWindowsSize=8 but I still find that : "11:58:32:842 [CCC] WSPRequest: 6D 7F 10 A2 DC 46 18 8F 06 A5 18 1F m F 11:58:32:842 [CCC] Debug: Before sendto 11:58:32:963 [CCC] Debug: After sendto 11:58:32:963 [CCC] WSPRequest: Debug: 10.0.0.172: requestOffset = 16800, requestLength = 21021 11:58:33:063 [CCC] WSPRestoreRoute: Modem: Ericsson T68 Cable Modem 11:58:33:063 [CCC] WSPRequest: Sending 1404 byte segmented request to 10.0.0.172 11:58:33:063 [CCC] WSPRequest: Packet Length is 1404 bytes 11:58:33:063 [CCC] WSPRequest: 2C 00 04 0D 93 66 D3 1C C4 A2 0B 41 14 58 3E AA , f A X> " It seem that the window size for WAP transfers is 1400 ,not 8*1400=11200 bytes .any suggestion ? It's the mmswapdebug file :
Thanks | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5357 Registered: 10-2002 |
Hi Russell, Sorry for the delay getting back to you again. I'm glad that you were able to find the cause of the recipient encoding problem. To stop NowSMS from automatically generating SMIL (leaves it as "multipart/mixed"), edit MMSC.INI, and under the [MMSC] header, add EMailAutoSmil=No. For the SarWindowSize question, make sure that this setting is included in an MMSWAP.INI file (this is an INI file that is not created by default). It looks like your configuration is using the default setting, which is a segment size of 1400 bytes, and a window size of 3. This means that we transmit 3 segments of 1400 bytes before requiring an acknowledgment. That is what I seem to be seeing in your log. If you do set the window size to 8, it is possible that NowSMS may automatically downgrade this setting (if it receives too many NACKs, or if it specifically receives a response from the gateway indicating that it must use a smaller window size). But I don't see any evidence of that in your log. Your log looks like the default settings are being applied. So make sure you create a new file, MMSWAP.INI for this setting. -bn | |||||||
corrupted mm1 file
