| EMS Encoding |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through March 09, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
I've tried to send an EMS icon using NowSMS gateway. However, it does not display properly on the handset. UDH=1283000420380FF01C64300C269440022982800141928001497940029E0D0000B0074002E0034002C001800180013E7C80017C3E80017C3E8001399C80010180800083C1000073CE0000381C00002C340000381C00006D560000FABF0001EFF7800262A64004D00B2019881198630420C69203C04BE2000047840000234C0000223800001C DATA=00 PID=0 DCS=0 Is there anything which I've missed ? Note: The same coding works on another SMPP gateway. | |||
| Bryce Norwood - NowSMS Support (Bryce) |
That UDH simply does not look right. The first byte of a UDH specifies the length of the UDH. In your example, this is "12" (or 18 in decimal) ... yet there are far more than 18 characters in the UDH that you present. I took a guess that the length was missing from the UDH, and inserted it in (85) at the start of the UDH ... and I get a nice skull and crossbones image on my phone when sending this message to my T68i. -bn | |||
| Anonymous |
Thank you for your speedy response. I've tried to resend the UDH with the length included and I get a modem error response. ERROR - Modem Response (2): +CMS ERROR: 38 ,Binary=1;UDH=851283000420380FF01C64300C269440022982800141928001497940029E0D0000B0074002E0034002C001800180013E7C80017C3E80017C3E8001399C80010180800083C1000073CE0000381C00002C340000381C00006D560000FABF0001EFF7800262A64004D00B2019881198630420C69203C04BE2000047840000 Any idea what could be the problem ? Also, where can I get a list of the error codes ? Thxs again. | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Sorry, I forgot to mention one other thing ... When I first tried submitting your message with the length in the UDH, I noticed that when I cut and paste that into the web form that all of the data was not being pasted into the web form (you can see in the log entry that you pasted above that some of the data is missing). So I issued the URL manually to send the message out. The web menu form limits the size of the UDH field to 260 characters. If you edit "Send Binary Message Other.htm" in the HTML subdirectory, search for: MAXLENGTH="260" ... and you can change that to MAXLENGTH="280". As to the error codes ... generally we return the error code from the underlying transport, in this case the GSM modem interface. The "+CMS ERROR" codes are returned by the modem directly. The error code that I see most frequently is "500", which is the ever helpful "unknown error". In your case, "38" is "Network out of order", which is typically cryptic and not necessarily an accurate response. Here's a list of all of the "+CMS ERROR" codes for the GSM modem interface ... they can be found defined in the ETSI GSM specs. I figure it is worth posting as they are split between the GSM 07.05, GSM 03.40 and GSM 04.11 specs. CMS ERROR code list (GSM Modem error codes): 1 - "Unassigned (unallocated) number" This cause indicates that the destination requested by the Mobile Station cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated). 8 - "Operator determined barring" This cause indicates that the MS has tried to send a mobile originating short message when the MS's network operator or service provider has forbidden such transactions. 10 - "Call barred" This cause indicates that the outgoing call barred service applies to the short message service for the called destination. 21 - "Short message transfer rejected" This cause indicates that the equipment sending this cause does not wish to accept this short message, although it could have accepted the short message since the equipment sending this cause is neither busy nor incompatible. 27 - "Destination out of service" This cause indicates that the destination indicated by the Mobile Station cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signalling message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure at the remote user, user equipment off-line, etc. 28 - "Unidentified subscriber" This cause indicates that the subscriber is not registered in the PLMN (i.e. IMSI not known). 29 - "Facility rejected" This cause indicates that the facility requested by the Mobile Station is not supported by the PLMN. 30 - "Unknown subscriber" This cause indicates that the subscriber is not registered in the HLR (i.e. IMSI or directory number is not allocated to a subscriber). 38 - "Network out of order" This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; e.g., immediately reattempting the short message transfer is not likely to be successful. 41 - "Temporary failure" This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the Mobile Station may wish to try another short message transfer attempt almost immediately. 42 - "Congestion" This cause indicates that the short message service cannot be serviced because of high traffic. 47 - "Resources unavailable, unspecified" This cause is used to report a resource unavailable event only when no other cause applies. 50 - "Requested facility not subscribed" This cause indicates that the requested short message service could not be provided by the network because the user has not completed the necessary administrative arrangements with its supporting networks. 69 - "Requested facility not implemented" This cause indicates that the network is unable to provide the requested short message service. 81 - "Invalid short message transfer reference value" This cause indicates that the equipment sending this cause has received a message with a short message reference which is not currently in use on the MS-network interface. 95 - "Invalid message, unspecified" This cause is used to report an invalid message event only when no other cause in the invalid message class applies. 96 - "Invalid mandatory information" This cause indicates that the equipment sending this cause has received a message where a mandatory information element is missing and/or has a content error (the two cases are indistinguishable). 97 - "Message type non-existent or not implemented" This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined or defined but not implemented by the equipment sending this cause. 98 - "Message not compatible with short message protocol state" This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the short message transfer state. 99 - "Information element non-existent or not implemented" This cause indicates that the equipment sending this cause has received a message which includes information elements not recognized because the information element identifier is not defined or it is defined but not implemented by the equipment sending the cause. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message. 111 - "Protocol error, unspecified" This cause is used to report a protocol error event only when no other cause applies. 127 - "Interworking, unspecified" This cause indicates that there has been interworking with a network which does not provide causes for actions it takes; thus, the precise cause for a message which is being send cannot be ascertained. 0...127 - Other values in this range are reserved, defined by GSM 04.11 Annex E-2 values 128 - Telematic interworking not supported x 129 - Short message Type 0 not supported x x 130 - Cannot replace short message x x 143 - Unspecified TP-PID error x x 144 - Data coding scheme (alphabet) not supported x 145 - Message class not supported x 159 - Unspecified TP-DCS error x x 160 - Command cannot be actioned x 161 - Command unsupported x 175 - Unspecified TP-Command error x 176 - TPDU not supported x x 192 - SC busy x 193 - No SC subscription x 194 - SC system failure x 195 - Invalid SME address x 196 - Destination SME barred x 197 - SM Rejected-Duplicate SM x 198 - TP-VPF not supported X 199 - TP-VP not supported X 208 - SIM SMS storage full x 209 - No SMS storage capability in SIM x 210 - Error in MS x 211 - Memory Capacity Exceeded X 212 - SIM Application Toolkit Busy x x 255 - Unspecified error cause 128...255 - Other values in this range are reserved, defined by GSM 03.40 subclause 9.2.3.22 values 300 - ME failure 301 - SMS service of ME reserved 302 - operation not allowed 303 - operation not supported 304 - invalid PDU mode parameter 305 - invalid text mode parameter 310 - SIM not inserted 311 - SIM PIN required 312 - PH-SIM PIN required 313 - SIM failure 314 - SIM busy 315 - SIM wrong 316 - SIM PUK required 317 - SIM PIN2 required 318 - SIM PUK2 required 320 - memory failure 321 - invalid memory index 322 - memory full 330 - SMSC address unknown 331 - no network service 332 - network timeout 340 - no +CNMA acknowledgement expected 500 - unknown error 256...511 - Other values in this range are reserved 512... - manufacturer specific | |||
| Anonymous |
Hi, I've done the changes as advised. I can see that the Web Interface can now accept up to 280 characters. However, when I submit the UDH, I still get the Modem Error CMS 166 ERROR - Modem Response (2): +CMS ERROR: 166 ,Binary=1;UDH=851283000420380FF01C64300C269440022982800141928001497940029E0D0000B0074002E0034002C001800180013E7C80017C3E80017C3E8001399C80010180800083C1000073CE0000381C00002C340000381C00006D560000FABF0001EFF7800262A64004D00B2019881198630420C69203C04BE2000047840000;Data=00 The log shows that the UDH is still restricted to 250 characters. Pls advise. | |||
| Bryce Norwood - NowSMS Support (Bryce) |
You're right. I must have sent my message out over SMPP instead of a GSM modem. Send me an e-mail at nowsms@now.co.uk, and I'll send a fix to you. -bn | |||
| mcongosto |
Bryce we are really stuck in this UDP thing. We spent a week just searching for a utility to convert from file to hex, yesterday i saw yours. But still getting inverted truncated pictures, if i get anythinh at all. We already know PDU specifications by hart from reading them too much, either EMS and Nokia. For example, in this message i get the skull in my t8i but that udh doesn't seem to be right. UDHL: 85 <- ok IEI: 12 <- weird, EMS 12 is for variable size pictures but this is 32x32 IEL: 83 <- ok 00: <- according to EMS UPD specs, this should be the widht in pixels divided by 8 (it is not, obviously) 04 <- and this should be the height I am so in the darkness here- we havent even gone trough smart messaging nor ringtones yet, do you know if i should get rid of the first bytes of the file? what kind of file should it be? im using wbpm. Believe it or not theren not too much info on this on the web. Theres no decent UDP tool. This could be a drawback for your gateway, because theres no use to the bynary sending capabilities. please help- | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Hi Manuel, We haven't focused much attention on EMS, mainly because of more interest in the color handsets, and less interest in monochrome images. That said, we'd like to do some more work on EMS, because there are quite a few handsets out there that support it, and very little EMS content. The way I read this particular example ... this looks to be encoded as a variable picture (IED 12). The IEDL (length) is 83. Then comes the position in the message at which the message is displayed (00). Then horizontal dimension (# pixels divided by 8), which is 04. Then vertical dimension, 20 (or 32 in decimal). So it is a 32x32 picture, encoded as a variable picture instead of as a fixed 32x32 picture. As for how to encode the actual picture data ... you can't use a WBMP file directly. But I think you could convert a WBMP somewhat simply. You need a simple black and white WBMP, and the WBMP would have to have a horizontal dimension that is divisible by 8 in order to be supported in EMS. The first two bytes of a simple WBMP should be 00. Then you get the horizontal width, followed by the vertical ... then the data. To encode that as an EMS, you'd compute the IEDL, add a 00 byte for the offset in the message, divide the WBMP horizontal dimension by 8 for the next byte, then the vertical dimension and then the message data. Let me know how you get on. It's an interesting idea here. We could probably write a utility to convert WBMP into EMS format relatively easy. The challenge is that in order to be supported by EMS the horizontal width of the image must be a multiple of 8. -bn | |||
| Petr |
I have similar problem with EMS, but maybe it is on GSM modem side. When I try send a small EMS message (from WEB interface; Binary message other, DCS=00 & PID=00) I get this error on GSM modem: 2003-09-17 16:18:21,3F61CA37.req,81.30.228.92,+420608111111,ERROR - Modem Response (2): +CMS ERROR: 500 -- Ericsson T39 Cable Modem,Binary=1;UDH=080B0200010D020001 But when I send this EMS via another GSM modem, it is OK: 2003-09-17 16:16:50,3F61CA36.req,81.30.228.92,+420608111111,OK -- Motorola Serial GPRS 56K,Binary=1;UDH=080B0200010D020001 Binary and text messages are OK on both modems, but EMS aren't. Why? | |||
| Petr |
Problem solved: Some GSM modem needs data part in PDU! EMS doesn't need strictly data part, because use UDH for sending information and data part is only used for text. But if there isn't data part in PDU some GSM modem (exp. T39) refuses this message. In this case (empty data part) is necessary to set data part to 00. | |||
| Bryce Norwood - NowSMS Support |
Hi Petr, That's a good tip. I've seen that behaviour as well, and have usually tried to include "00" in my examples for that reason ... but rather than just using that in examples, it is good to mention that this is a problem. I have a question for you ... I see from your log snippet that you are using a Motorola device as your modem. Can you tell me what Motorola device it is? (The reason that I ask is that we seem to have a number of Motorola employees wanting to try out our product, and they usually find that the phones that they regularly use do not have the necessary support for sending/receiving SMS via AT commands ... so I'm wondering if I can point them to a particular model that is known to work.) -bn | |||
| Petr |
Hi Bryce, the GSM modem which we use is based on Motorola g18 GSM/GPRS embedded module. One firm (which I know, but I think that isn't alone) combines this g18 module and USB interface together and produces this USB/GSM modem. And we use this GSM modem with Motorola Serial GPRS 56K driver (found on internet). USB interface is comfortable - you don't need external power supply. | |||
| Petr |
I wrote > Problem solved: Some GSM modem needs data part in PDU! But the problem is bigger than I saw. Because - NowSMS doesn't send EMS correctly! EMS is text SMS with UDH, text (optionaly) and DCS=00. There is only one way to send EMS in NowSMS - as binary message with DCS=00 and UDH (When I want to send EMS as text SMS with UDH - NowSMS convert automaticaly SMS as binary message and here is another big problem. Message is routed to another GSM interface than I want: not by prefix but to default route. There must be a bug!) On some GSM modems empty data part is a big problem. I thought that I solve this problem with setting data part to 00. But this works fine only for one look - because 00 is character @ in IA5 charset. It can cause that in received EMS is character @ in text part. Data part is added as text (it is possible to add text in this case, but you must write text as hex values of characters). Problem is that I don't want to add this necessary characters to EMS part. Maybe I can set data part to 32 (32=space) to see nothing but it isn't correct way. What with this? And with second problem - routing. | |||
| Petr |
Some new information for EMS encoding: There isn't correct to add character to data part in hex and use DCS=00. Mobile phone use UDH and DCS=00 means that message is default coded. Phone decodes characters from data part and this decoding may give some unexpected result. I found only one almost correct way to send EMS with text (or EMS with space in case with GSM modem problem): DCS=19 and text in UCS2 (space=0020). It's a pity that NowSMS doesn't support EMS correctly... | |||
| Bryce Norwood - NowSMS Support |
Petr, It's not our fault that the modem requires something in the "data" of the message separate from the UDH (unless I'm missing something ... if you are using an older version, I do remember that at one time we had a requirement that there be something in the data separate from the UDH, but we changed that because of EMS). Why not use DCS=0 and DATA=20 (20 being the hex encoding for the space character)? | |||
| Bryce Norwood - NowSMS Support |
Oh, and also, I would love some suggestions on how we could better support EMS. | |||
| Petr |
As I wrote - it isn't possible to send DCS=0 and DATA=20 in EMS message as binary message without problems, because text part for EMS with DCS=0 must be converted (as in normal SMS with default alphabet) from IA5 septets to octets. If you combine binary UDH and binary data (=20) it will depend on length of UDH if you will receive space or greek delta (it is space shifted one bit right).It depends on conversion length in octects and septets. I wrote too, that one possible way in this version of NowSMS is DCS 19 and data=0020, because in this case you can use UCS2 characters. And about support EMS - your software must be able correctly combine binary UDH with text part (as normal SMS with DCS=00), because EMS is a normal text SMS. It isn't correct to substitute sending EMS by binary SMS (specially if you set DCS=00 - default alphabet). I dont't know if I explain it right. I know that sending EMS is complicated problem - correctly to combine binary and text data and length of PDU. But maybe is a small bug in routing, as I wrote. When I want to send text SMS with UDH from HTTP request - NowSMS converts this message to binary SMS, but sends this message to default route not to preferred route (by prefix). I don't know if it depends on conversion or on unsupported action (text SMS with UDH). | |||
| Bryce Norwood - NowSMS Support |
Petr, Thanks, I understand now. I think I have trouble comprehending this thread because for some reason it is formatted very wide, and I keep having to horizontally scroll, which does not seem normal. The idea about mixing a text message with a binary UDH is a good idea. I can see where that would be extremely useful for EMS. On the routing issue, I don't observe any differences here. The routing checks don't have any dependencies on whether a message is text or binary. How about enabling the debug log on your gateway. Manually edit SMSGW.INI, and add Debug=Yes under the [SMSGW] section header. Restart the gateway service. Repeat your message sending attempt where a message gets sent out via the wrong SMSC connection. E-mail me the SMSDEBUG.LOG and SMSGW.INI files (to nowsms@now.co.uk), and I'll take a closer look to determine why the message would be directed to the wrong preferred SMSC. | |||
| Anonymous |
Hi, i'm from Mexico and i'm developing a software to send sms messages from a pc to any device and my modem send me the error +CMS ERROR: 512 if 1 of you can help me how can i fix this error i'm using Hyperterminal and Visual Basic. Hope some of you can help me otherwise i can lose muy job tnx to all  | |||
| Bryce Norwood - NowSMS Support |
You can find a list of CMS error codes here: http://support.nowsms.com/discus/messages/1/829.html Unfortunately, CMS Error 512 is a manufacturer specific error, which means it is specific to your device/modem manufacturer. | |||
| Anonymous |
Hi, how can i represent TP-UDHI,TP-PID,TP-DCS,UDL in SMS as a content provider for EMS}. Plz help me. i m somehow confused. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1108 Registered: 10-2002 |
Well, I'm not sure what the context of your request is, but since is the support forum for the Now SMS/MMS Gateway, I will answer in the context of how you submit these parameters through NowSMS. (If you are not using NowSMS, and are asking how to construct the PDU, then please refer to the ETSI GSM 03.40 specifcation which documents the SMS PDU format. It is available for download from http://www.etsi.org.) The UDH of the message is submitted in the UDH parameter. The first byte of the UDH should be the length of the UDH (UDHL). NowSMS automatically sets the TP-UDHI flag when the UDH parameter is present. The TP-PID is specified in the PID parameter as a hex character string value. The TP-DCS is specified in the DCS parameter as a hex character string value (e.g., F5). UDL is calculated automatically by NowSMS. If I want to send the simple iMelody ring tone described in thread http://support.nowsms.com/discus/messages/1/218.html then I would submit the message to NowSMS with the following parameters: /?PhoneNumber=recip&UDH=820C8000424547494E3A494D454C4F44590D0A56455253494F4E3A31 2E320D0A464F524D41543A434C415353312E300D0A4D454C4F44593A2A3366336633663323633123 64332364332364336331723366336633663323633323663323663323663366332A34236333236333 2363332A332361310D0A454E443A494D454C4F44590D0A&DCS=08&Data=0020 Note that in this example, I included some data beyond the UDH ... because some GSM modem devices cannot accept a message that includes UDH only. To avoid confusion, I'm sending a space character (character code 0x20 or 32 decimal), but I'm sending it in Unicode format (DCS=08) to avoid 7-bit packing problems. So the resulting message has the iMelody and a space character. | |||
| Anonymous |
Actually i wanted to know About the TP-UDHI,TP-DCS,TP-PID,TP-UDL. Has any option to set these in SMSC. Or is it necessary to mention the Parameters to NOW SMS Gateway? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1193 Registered: 10-2002 |
The TP-UDHI is a flag that indicates whether or not UDH is present in the data. It is set automatically by NowSMS if you include UDH in the submitted message. TP-DCS and TP-PID are described in my previous reply. TP-UDL is also described in my previous reply. I guess that I am not understanding your question. Perhaps I do not understand the context in which you are asking it ... e.g., what specifically you are trying to do. | |||
| Anonymous |
i want to construct an EMS message that consist of a varible picture.And it will be used in push pull service.Now here is a problem,if we don't use a gateway as like NowSMSGateway,how can we mention the indicators( eg. TP-UDHI,TP-DCS) in the message. | |||
| Anonymous |
hi, Where can i get ETSI 07.05 Specification...  | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1287 Registered: 10-2002 |
http://www.etsi.org | |||
| Anonymous |
I need more details location to get the Specification. i did a lot but i didn't get the specification. Plz Send the Exact Location | |||
| Fabricio New member Username: Fabri Post Number: 4 Registered: 11-2003 |
http://www.3gpp.org/ftp/Specs/archive/07_series/07.05/0705-701.zip | |||
| Anonymous |
hi, When the data was null i.e. no input of data(userdata)but user data header exist and it was in well formed.. then the SMS was not delivered to mobile end. Wht's the problem of it??? Plz help | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1446 Registered: 10-2002 |
Some GSM modems do not like it when there is no user data (only a user data header). (It might be possible that some SMS service providers have similar problems.) We've found that what generally works best is to include some "dummy" data. The safest dummy user data to send is the Unicode encoding for a space character, 0020. Set the DCS to 8 to indicate unicode encoding, and include 0020 as the user data. -bn | |||
