| Bugs? |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through July 28, 2006 ⬆ |
◄ ► |
| Author | Message | ||||
| Nambu New member Username: Nambu Post Number: 32 Registered: 08-2004 |
Hi Bryce, I am very glad for a new version released. I using Now SMS/MMS Gateway v2006.03.01 with Trial license from today. Ahead, I reported on the bug found first. However, when I see again now, the report cannot be displayed because of the error. I report on bugs found today as follows. It include the first bug. I want you to release the patch as soon as possible. 1. [MMSC] tab's window is too short. The MMSC tab is displayed. The height of the window doesn't suffice, and the last item is not displayed. There might be a difference of OS. I use WindowsXP (Japanese) SP2. The image is appended to make sure.  2. Send EMS Message (Text format) I sent text formatting EMS messages from Web Interface to my SMSC. And, I noticed that UDH that NowSMS had made was not correct. Octet 4 of Text formatting IE ,in a word, Octet 2 of IED is text formatting length. In UDH that NowSMS made, text formatting length of all IE is 0x00. In Web Interface, I input the following for instance texts. <b>01234567890123456789789</b> 3. "Send long message without segmentation" and EMS I usually check "Send long message without segmentaion". Only the first UDH reaches SMSC when long EMS (UDH is different in each divided message) is sent from Web Interface by this setting. 4. "Submitted" Web Interface displays wrong message count For instance, the message of 160 characters is transmitted with Send Text SMS of Web Interface. The message count displayed under the input field is correct by one. But 2 message ID are displayed on the screen after Submit button is pushed. 5. NowSMS uses only 134octet by 1 message. I unchecked "Send long message without segmentation". I sent SMSC long messages with Web Interface. Any message is delimited by 134 octets. Why do you waste it by as many as six octets? 6. The binary data of BMP cannot be used. I input the binary data directly with Send EMS Picture Message. Then, I push the Submit button, my browser puts out the error "Cannot connect to server." I tried ten times or more. 7. "Send WAP Push Message" displays wrong error message I input a bad value to SI ID and SI Create of "Send WAP Push Message" and the Submit button is pushed. Web interface pop up error of SI Expires. 8. The upper bound value of "Message Waiting Count" is not checked I input 300 to "Message Waiting Count" by "Send Voice Mail Notification". The values of Number of waiting messages are from 0 to 255 in Spec. The value 255 means that 255 or more messages are waiting. I expected the message that the last octet of UDH becomes 0xFF to reach my SMSC. However, the end of UDH that NowSMS had made was 0x12C. The following items are my questions and demands. 9. "Send Voice Mail Notification" made UD Two bytes, 0x80 0x00 exist in UD when the message is sent by using "Send Voice Mail Notification" of Web Interface. What is this data? 10. There is no "Video" in "Send Voice Mail Notification". "Video message waiting" exists in Spec(TS-23.040 Rel6). I want you to add it to Web Interface. Thank you. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5573 Registered: 10-2002 |
1.) That is strange. I guess it has to do with the dialog font used in Japanese Windows being larger. We can make the dialog a little bigger in a patch. But in the meantime, if you need to set these settings, they can be set in the MMSC.INI file under the [MMSC] header by setting NotifyRetryAttempts=## and NotifyRetryDelay=##. 2.) I believe what the way we are encoding it is legal. TS 23.040 says:
So essentially what we are doing is that each time there is a font change, we are declaring that this font becomes the default font beginning at a specified point of the message. Let's take your example: <b>01234567890123456789789</b> We'd indicate that bold becomes the default font starting at offset 0. Then we would indicate that non-bold becomes the default font starting at offset 20 (even though no text actually follows). That said, you may have a point ... in that I'm looking at Rel 5 and Rel 6. This 0 length option was not defined in Rel 4. I'm not sure if we need to be concerned with Rel 4. This is probably an issue that we need more feedback on. 3.) Hmm. I'm not sure how to resolve this issue, as the proper behaviour for this type of "Send Long Message without Segmentation" HTTP connection is somewhat ambiguous. Currently, what we are doing is that if there is UDH, we are keeping the message in binary format, and ignoring UDH from all but the first message part. I agree that it is not correct to ingore UDH from the later message parts. But I am concerned that by treating the long EMS text message as a binary message, we risk corrupting it during this recombination process ... whether the UDH is ignored or not. That is because the 7-bit encoding that is used for the message text is dependent on the length of the UDH. So if we strip the segmentation information from the UDH, the 7-bit encoding is no longer valid unless the HTTP SMSC re-inserts it. Do you understand what I mean? My concern here is that sending EMS via an HTTP SMSC connection where "Send Long Message without segmentation" is checked will not work, even if we were to include the missing UDH. I believe the only solution is to keep the text as text. Then we could strip the segmentation info from the UDH, maintain the full UDH from all segements, all without corrupting the message text. This would require that an HTTP SMSC that expects us to "Send Long Message without Segmentation" support UDH with text. Would that work with your HTTP SMSC interface? 4.) I would need to see the exact text that you are submitting. I just sent the following: 12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 The web form says "160 characters, 1 SMS message(s)" ... and only one message was sent. We use some simple JavaScript in the "Send Text Message" web form to indicate how many messages will be required, so maybe you are using a character that is not being handled correctly by the JavaScript. 5.) UDH overhead. Segementation UDH takes up 6 bytes. 6.) That's a definite bug. The text input "hex string" format is not working for "Send EMS Picture Message". 7.) I do not understand. The "SI ID" field is not validated, so whatever value you input is submitted. If either the "SI Created" or "SI Expired" field is specified, it is validated. The text says "Invalid date field. Date values for the SI Created and SI Expires fields must be expressed in a date/time format expressed in Universal Time (UTC)." Perhaps it is just a language issue, but the text is intended to indicate that invalid data is present in a "date field", which is either "SI Created" or "SI Expires". 8.) Ok. 9.) Some GSM modems (and other SMSCs) have a bug where if a message does not contain any user data, they won't send the message. So we encode a space character in the text of the user data. But in further consideration, also considering item #10, I think we could stop doing this if we always include the MWI UDH. Currently, we only include the MWI UDH if the message waiting count is specified. But I see no reason why we should not include it always. 10.) Related to #9, we could easily add this. I've uploaded a patch to http://www.nowsms.com/download/patch2006.zip which addresses #1, #6, #8, #9, #10. Summary of status of other items: #2 - Technique is compatible with Rel 5 and Rel 6, but not with Rel 4. May be re-evaluated with further input. #3 - May not be possible to resolve in a generic manner when using "Send Long Messages without Segmentation" option for an HTTP SMSC. May re-evaluate with further input. #4 - Need example to recreate problem. #5 - No bug. Normal behaviour. #7 - No bug. Normal behaviour. | ||||
| Nambu New member Username: Nambu Post Number: 33 Registered: 08-2004 |
2.) I was looking at Rel4 as you said. I saw Rel6 in your point. And, I still think that text formatting length should not be adjusted to 0. Because it is described that the format becomes default if Text formatting length is 0. I made the message including various formats with Web Interface. NowSMS set all Text formatting length to 0. I think it is strange in the existence of many defaults. 3.) I understand what you said. This problem is difficult. I comment later. 4.) I examined what caused the problem. As a result, I found the condition of inputting Enter to Text. In addition, URL of the HTTP request transmitted to SMSC uses Binary Template at this time. When I input the following data to Text; [quote]1111111111111111111 2222222222222222222 3333333333333333333 4444444444444444444 5555555555555555555 6666666666666666666 7777777777777777777 8888888888888888888[/quote] URL that NowSMS outputs is; [quote] /?PhoneNumber=1234596&Binary=1&Data=62B1582C168BC562B1582C168BC562B158432193C964 32994C2693C96432994C2693C91A8AD96C369BCD66B3D96C369BCD66B3D96CD650D068341A8D46A3 D168341A8D46A3D168B486A256ABD56AB55AAD56ABD56AB55AAD56AB3514369BCD66B3D96C369BCD 66B3D96C369BADA1B8DD6EB7DBED76BBDD6EB7DBED76BBDD6E0D050E87C3E170&UDH=0500035C020 1&pid=0&dcs=0 /?PhoneNumber=1234596&Binary=1&Data=70381C0E87C3E170381C0E07&UDH=0500035C0202&pi d=0&dcs=0 [/quote] The problem doesn't occur when Enter is replaced with space. There was no problem though even NowSMS 5.51b input Enter. Then, Enter was counted as two characters (CR+LF). It is counted as one character in NowSMS2006. Additionally, the display update when the character is input to Text has slowed because of this version. I am doubting the cause the count processing. I want you to change to the same operation as NowSMSv5.51. 5.) You are correct. I was misunderstanding it. 7.) I was misunderstanding. I'm sorry. 9.) I understood. Thank you for the replay. Thank you for the patch. I immediately use it today. I forgot to write one. 11.) It is displayed in [Serial #] tab of Trial Version as follows. Licensed for 30 mesages per minutes. However, NowSMS actually transmits the message to SMSC every 30 seconds. Why do? Thank you. | ||||
| Nambu New member Username: Nambu Post Number: 34 Registered: 08-2004 |
Hi Bryce, The error of Windows goes out when smsgw.exe is doubly started. I want you to mend. | ||||
| Nambu New member Username: Nambu Post Number: 35 Registered: 08-2004 |
Hi Bryce, I used the patch (2006.03.03 release) for today. I post the result. 1.) I was not found the beneficial change. The last item is hidden. 6.) I input directly hex data of BMP to Web Interface, and was able to submit with WAP Push. Thank you. 8.) NowSMS operated correctly. :-) 9.) UD is empty. ;-) 10.) Thank you! In addition, I found the following problems that had not been post yet. 13.) This problem occurred by two PC only immediately after installing NowSMS 2006. I checked "Activate MMSC Service" of the MMSC tab. However, "MMSC Service" of the Service tab was not checked. Then, I checked "MMSC Service". The error message was displayed.
NowSMS moves without trouble now by quite the same setting. 14.) I tried to select various picture files with Send Picture Message, and to submit by EMS. Some files were able to be submitted normally. Other files became "Picture conversion failed" error. The file format (BMP, GIF or JPG) seemed to be unrelated. What is bad? 15.) I selected the JPEG file (1,748 bytes), and submitted a picture message by EMS. All of three messages that NowSMS output do not use maximum size(140octet). URL that NowSMS output is appended as follows.
Why are not 140 bytes used? Thank you. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5596 Registered: 10-2002 |
#1 - This is strange. Windows should adjust the size dynamically. All we can do is try to make the window larger again by inserting more blank space. #2 - Still under review. #4 - It always adds 2 characters to the counter when I press enter in the web form. I just compared the changes in the HTML template for this web page, and there were only two minor changes between v5.51 and NowSMS 2006 ... fixes for the "£" and "¥" characters not being counted properly. I cannot explain why you would see different behaviour. #9 - It depends on how you define "user data". But you are correct, we did make a change here. The specs define "user data" like this:
So I was referring to "user data" as being inclusive of any "user data header". Previously, we always encoded a space character in the message text of the "user data". However, upon review, we found that some handsets will display this blank message when receiving the MWI message. So, we are now always generating UDH to indicate MWI. The video message indicator requires that UDH be used. Previously, we only generated UDH when the "message count" was indicated. So now we are always generating the UDH, which means the "user data" (inclusive of UDH) is non-null. It is still possible to include text in the notification, but you can only do this via URL parameters. Basically, you have to append "&Text=" to the URL. However, it should be noted that we are setting the DCS value to indicate that the text should be discarded. So there is not really any point in including any. All that said ... we have had previous requests from people who wanted to send MWI with text, and wanted us to use the DCS values for storing the text instead of discard it. So we could make some more changes here. We will add an optional "Text" field to the "Send Voice Message Notification" web form. If this field is non-blank, we will use the DCS for "Message Waiting Indication Group: Store Message" instead of "Message Waiting Indication Group: Discard Message". In either case, the MWI UDH will always be present. And by adding the "Text" parameter to the web form, this will allow people to test other DCS settings for notifications. #11 - I'd have to see your SMSDEBUG.LOG. If you are using an HTTP SMSC, it sounds like there is something wrong with the HTTP response which is causing the delay. #12 -
I don't understand this. I don't have any problem if SMSGW.EXE is opened multiple times. (But it can be confusing when this happens. We could make a change to find the previous open window and switch to it.) #13 - I cannot recreate. It sounds like a timing issue. #14 - I would have to see the images to understand. The most common issue is that the width (in pixels) of the image must be a multiple of 8. But that should display a different error message. #15 - The rules of EMS picture encoding when using UPI (user prompt indicator) to span multiple messages are rather complex. The image is split into multiple images that are stitched together by the receiver. The image must be split on a row boundary. See the following thread for a detailed example: http://support.nowsms.com/discus/messages/1/1758.html Changes for #1, #9 and #12 are currently pending. I will post a follow-up when available. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5597 Registered: 10-2002 |
Regarding #2, we're going to make changes to make it compatible with Rel 4, and avoid the use of the "default" length parameter. We are also optimising the UDH header generation so that less UDH is generated for attribute changes. The update is at the same URL as before: http://www.nowsms.com/download/patch2006.zip As we do not have Japanese version of Windows, we need verification that #1 is fixed. Summary of changes: 2006-03-06: * "Retry MMS Delivery Notifications" options were cut-off on the "MMSC" configuration dialog when running on Japanese versions of Windows. Dialog window was too small for Japanese fonts. (Updated SMSGW.EXE) * If NowSMS configuration program is already active, don't load a second copy if it is run again. (Updated SMSGW.EXE) * Modify "Send EMS Text" handling to generate UDH that is compatible with EMS Release 4. (No longer use the text formatting length = 0 to keep changing the "default" font at the current offset. Also further optimisations to reduce the amount of UDH generated for attribute changes.) (Updated SMSGWS.EXE) * Add "Text" parameter to "Send Voice Mail Notification" option to allow a text message to be included with an update to any of the supported message waiting indicators (MWI). When a text parameter is present, NowSMS will use a DCS value for "Message Waiting Indication Group: Store Message" instead of "Message Waiting Indication Group: Discard Message". (Updated SMSGWS.EXE and Send Voice Mail Notification.htm) 2006-03-03: * "Send EMS Picture Message" did not work with "Text input (hex string format)". (Updated SMSGWS.EXE) * Bounds check on "Message Waiting Count" for "Send Voice Mail Notification". If the value is larger than 255, it is set to 255. (Updated SMSGWS.EXE.) * Add support for "VoiceMail=VideoOn" and "VoiceMail=VideoOff" parameters to turn on and off the video message waiting indicator. (Updated SMSGWS.EXE and Send Voice Mail Notification.htm) | ||||
| Nambu New member Username: Nambu Post Number: 36 Registered: 08-2004 |
Hi Bryce, I cannot test the operation of the released patch because I should go out today. However, I confirmed only the #1 in a hurry. The problem was solved. Thank you so quickly reply. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5606 Registered: 10-2002 |
Hi Nambu, I have more information regarding #14. This problem basically occurs if the image is too large. We don't do any scaling down of the image. We could ... but because so many people use NowSMS for device testing ... we thought it would be helpful if you could use NowSMS to send larger images via these functions. That said, there were situations where NowSMS should have returned the error "Picture is too large for selected output format", but instead it was simply saying "Picture Conversion Failed". So I suspect that the issue with the images that you tried was that they were simply too large. Both EMS and Nokia Smart Messaging were not really designed for handling larger images, which is what led to a more capable protocol for multimedia, MMS. Larger pictures can be sent by setting MaxRingToneFragmentCount=## under the [SMSGW] header of SMSGW.INI. The default value of this setting is 6. This setting applies to both the "EMS Send Ring Tone" and "EMS Send Picture Message" functionality. An image or ring tone that would require more than this number of SMS messages to be sent is rejected with an error. In reviewing this situation, we did make a minor change to NowSMS. (There is another updated http://www.nowsms.com/download/patch2006.zip.) Basically, internal changes have been made in this version to better support larger values for this MaxRingToneFragmentCount setting. Increasing the value of this setting is only recommended for specialised environments and testing labs. -bn | ||||
| Nambu New member Username: Nambu Post Number: 37 Registered: 08-2004 |
Hi Bryce, Of course, I know the error "Picture is too large" is displayed by using large image. As for "Picture Conversion Failed" that I say, the sentence is displayed. I want to send you the image to which this error is displayed. However, I cannot judge which image is good because there are a lot of numbers of image files. I want you to teach what image how to send you. | ||||
| Nambu New member Username: Nambu Post Number: 38 Registered: 08-2004 |
Hi Bryce, I'm sorry. The width of the images that I had prepared was not a multiple of 8. I understand that "Picture conversion failed" was displayed because it had used these images. Is it correct? | ||||
| Nambu New member Username: Nambu Post Number: 39 Registered: 08-2004 |
Hi Bryce, I might have hit on the cause of #13. Another application uses port 80 in my environment. Therefore, I do the following at the first setting after installation. 1. I change "HTTP Port Number" in [MMSC] tab. 2. I check "Activate MMSC Service". 3. I check "SMS Gateway Service" in [Service] tab. 4. I check "MMSC Service". 5. I push [OK] button. I expect that NowSMS2006 begins in port 80 the MMSC service of #5, and does the setting change of the MMSC tab afterwards. Did NowSMS v5.51 change the setting by #2 and begin the MMSC service? Then, in NowSMS v5.51, I did not have to do #4, when I do #2. | ||||
| Nambu New member Username: Nambu Post Number: 40 Registered: 08-2004 |
I put SMSDEBUG.LOG for #11. I want you to verify the problem of #4 by this log. NowSMS v5.51 transmits messages to same SMSC in per second. I do not think that the response of SMSC is bad. This is a problem of NowSMS2006.
| ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5608 Registered: 10-2002 |
Regarding #11 - 1 message every 30 seconds. There is a problem that occurs when NowSMS 2006 is installed "fresh" (not over an existing NowSMS installation). Create a subdirectory named "HELP" under the NowSMS program directory (e.g., c:\program files\nowsms\help), and this will resolve the problem. NowSMS keeps an old statistics counter in that directory (it has nothing to do with licensing), and if it cannot access the statistics counter it waits for 30 seconds. The install program used to create this directory for older versions of NowSMS. However, the new install does not create this directory. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5609 Registered: 10-2002 |
#14 - In the error that is returned, it should say "Picture images must have a width size that is a multiple of 8 (example: 8, 16, 24, 32, 40, etc.)" I believe that condition was always returning the correct error message. But we did find problems with a generic error message being returned when a message was going to be too large. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5610 Registered: 10-2002 |
#4 - I don't understand. The only message submission I see in that log is for: example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. And that is clearly enough text for 3 SMS messages. I truncated it to: example.example.example.example. example.example.example.example. example.example.example.example. example.example.example.example. example.example.example. The web interface reported 160 characters (1 message), and only one SMS message was generated. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5611 Registered: 10-2002 |
#13 - The "HTTP Port Number" setting is not saved until you press "Ok" or "Apply". Similarly, "Activate MMSC Service" does not activate the MMSC service until you press "Ok" or "Apply". So, when you start the service, the service is being started with the old settings. Previously, the "MMSC" page of the configuration had special handling. If you made any changes on that page, and then switched away from it, we would ask if you wanted to save the changes. This behaviour was inconsistent with other pages in the configuration dialog. It is confusing that you have to press "Apply" to save configuration changes. But we improved things in this version so that if you press the "Escape" key or "Cancel" button, and there are unsaved configuration changes, we ask if you want to save them. I guess we could perform the same check when you press a button to start the service ... if there are unsaved configuration changes, we could ask if you want to save them before starting the service. | ||||
| Nambu New member Username: Nambu Post Number: 41 Registered: 08-2004 |
Hi Bryce, I caught a cold and took a rest yesterday. You also take care. Regarding #11 - I believe that you will release the installer that makes "HELP" folder in a few days. I recognized that the bug of the installer. #14 - I have never seen the error that you say. I say that the file size is not a problem many times. This error is displayed by an image that is smaller than the succeeding image. For instance, "Picture conversion failed" is displayed by using the following image. *file size : 92 bytes *image size : Widht 18 pix, Height 12 pix *format : gif #4 - As you say, it is a log that I appended that sends three Text messages from Web Interface. Did not you notice URL output to SMSC was Binary though it was Text? I say that it is a problem. #13 - Humm... I thought that two checks on the Service tab was strange while using the previous version. MMSC Service is checked by the automatic if I set in MMSC tab, however, it is necessary to check another one in Service tab. Judging from reading your answer, I think that "Activate MMSC Service" of the MMSC tab should not exist. And, services should begin by using the setting displayed in GUI. Otherwise, the user cannot confirm by what kind of setting service operates. It is a problem. Thank you. | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5630 Registered: 10-2002 |
Hi Nambu, I hope you are feeling better. #11 - We have produced a new installer (and we also modified NowSMS to create this directory if necessary, to avoid future installer dependencies). You can either download the complete installer from the "Free Trial Version" link, or just the updated software from http://www.nowsms.com/download/patch2006.zip as before. #14 - Could you post one of the images that you are having a problem with. (Also, give the new version a try to see if it makes a difference.) I've tried a variety of random images, and haven't seen a problem that was not size related, so I must be missing something. Just click on "Upload Attachment". #4 - When the HTTP SMSC interface is used, if a text message includes UDH (such as segmentation for long messages), we encode the message in 7-bit text format. This is because HTTP interfaces that we have previously dealt with get confused if a text message includes UDH ... they do not know how to encode it properly. If necessary, we would consider a configuration option for an HTTP SMSC definition to not use 7-bit packed encoding whenever UDH is present. (We have similar issues in the SMPP world, where some systems expect the text to use 7-bit packed encoding, and others do not. So there is a configuration option for SMPP ... as well as UCP.) #13 - I agree, the "Activate MMSC Service" checkbox should not exist, as it only causes confusion. Unfortunately, it does exist. I think we should look at removing this in the future (it can make room for another future configuration option  ). -bn | ||||
| Nambu New member Username: Nambu Post Number: 43 Registered: 08-2004 |
Hi Bryce, #11 - Thank you for quickly reply. I downloaded new installer. #14 - The situation did not change by 2006.03.09 build, then, I attach image file.  #4 - I understood as follows; The operation of NowSMS changes by setting "Send long message without segmentation" if a long message is submitted from Web Interface. When I check it, NowSMS doesn't do 7- bit packing and use Text Template. If I do not check it, NowSMS does 7- bit packing and uses Binary Template. As you say, my SMSC calculates the number of fill bit from UDH Length, and 7-bit packing. I hear the option that you say very well. However, I do not think it to be indispensable because I only have to check "Send long message without segmentation". But,,, #3 - In HTTP interface of my SMSC, the maximum of UDH is limited to 140octet. My SMSC has inserted same UDH (excluding Concatenated IE) as TP-UD of all messages to compose long message. This specification is improper in EMS. The developer of my SMSC also is recognizing it. It is necessary to remove the check on "Send long message without segmentation" so that SMSC may receive all of EMS message. However, SMSC recognizes long message as two or more messages. Moreover, SMSC cannot recognize 7-bit packed data as 7-bit text. I think that your proposal is very good. The developer should seriously think how it does. #13 - I see. ;-) I am guiding the usage of NowSMS to our customers. Until you remove it, I will till our customers as follows; - I teach set-up steps that walk around a problem to the customer who wants to use a new version. - I teach the customer who doesn't want to change set-up steps to keep using an old version. When you release new build, I will tell it to them. Thank you for a lot! | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5635 Registered: 10-2002 |
Hi Nambu, #14 - I see we still have not fixed the error message. The error message should be "Picture images must have a width size that is a multiple of 8 (example: 8, 16, 24, 32, 40, etc.)", but it is showing as "Picture conversion failed". The image that you attached has a width of 18 and a height of 12. If it had a width of 16 or 24 it would go through. #3 & # 4 - We'll see if we can add an option for HTTP SMSC connections where text is submitted in text format (instead of 7-bit format) if UDH is present. -bn | ||||
| Nambu New member Username: Nambu Post Number: 44 Registered: 08-2004 |
Hi Bryce, #14 - Because you say that the error message is different, I am trying. The kind error message (it points out that width is not a multiple of eight) that you say is not displayed to me at all. I want to display the message of the understanding of the cause of the error from "Picture conversion failed". I attach screen shot and SMSDEBUG.LOG.  
| ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5650 Registered: 10-2002 |
Hi Nambu, Sorry, my explanation was not clear. The error message should say "Picture images must have a width size that is a multiple of 8 (example: 8, 16, 24, 32, 40, etc.)". However, a problem remains. And instead of this error message being displayed, the error message returned is "Picture conversion failed". This is only a problem that the wrong error message is displayed. -bn | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6120 Registered: 10-2002 |
Belated follow-up to #3 and #4 ... An update for NowSMS 2006 has been posted at http://www.nowsms.com/download/patch2006.zip It contains a configuration option to configure an HTTP SMSC so that text messages which contain UDH (such as long text messages or EMS messages) can be sent to the HTTP SMSC with the text in standard text format instead of 7-bit packed. For details, see http://support.nowsms.com/discus/messages/53/15129.html. | ||||
