| Regarding Class 0 Unicode message |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through August 22, 2012 ⬆ |
◄ ► |
| Author | Message | |||
| Johnny New member Username: Johny Post Number: 30 Registered: 02-2009 |
Hi I use NowSMS v2011.07.05 in KOREA In the Text Mssage, I written KOREAN language at the Text and I select Class 0(Flash) and send message to mobile phone. The message is received to the mobile phone, but message is not flash type. The message is stored to the mobile phone. When I input alphabets and numbers such as apple, 1234, select class 0 and send message , the mobile phone receive the message to the flash type and not stored. the message type is not Class 0(flash), when I use KOREAN language and select class 0 ? Please let me know the reason. Thanks  | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4030 Registered: 08-2008 |
Hi Johnny, Are you using SMPP? There is a limitation in the SMPP specification with how the GSM DCS (data coding scheme) is mapped to the SMPP daya_coding value. So when sending Unicode messages with flash encoding, in SMPP, it's usually not possible. In raw GSM, the DCS value for flash unicode is 0x18. However, the data_coding value of 0x18 is not valid in SMPP. Some SMPP servers might support this value anyway, but most do not. Because a value of 0x18 is not valid in SMPP, NowSMS changes 0x18 to 0x08 (unicode, no flash) when transmitting to SMPP. It is possible to disable this behaviour in NowSMS by setting RemapMessageClassDCS=No under an [SMPP] header in SMSGW.INI. (Note: This is a section header of [SMPP], not [SMPP - server:port].) This setting will stop NowSMS from changing the DCS. There is a small chance that this setting may work with your SMPP provider, but it is more likely that this setting will result in garbled messages because the SMPP provider doesn't understand the data_coding value. -- Des NowSMS Support | |||
| Johnny New member Username: Johny Post Number: 31 Registered: 02-2009 |
Thank you for your support I solve this problem. I have a question You said that It is possible to disable this behaviour in NowSMS by setting RemapMessageClassDCS=No under an [SMPP] header in SMSGW.INI. (Note: This is a section header of [SMPP], not [SMPP - server:port].) I can't SMPP header in the SMSGW.ini so I input above parmeters under [SMPP - server:port]. And then I can be received Unicode flash type message. Is it correct to input values under [SMPP - server:port] When I input this parameter, does the parameter influence other services such as send MMS, WAP Multimedia and so on? Thanks -------------------------------------------------------------- [SMSGW] Modem1=SMPP - 203.xxx.xxx.xx:xxxx WebAuth=No WebMenu=Yes WebPort=8800 ReceiveSMS=No ReceiveMMS=No Debug=Yes ReceiveSMSCharset=utf-8 ConfigurationUpdateTriggerRestart=20111107161457 SeparateUserQueues=Yes AlertEMailSender=nowsmsxxxx@test.com AlertEMailQueueSize=50 AlertEMailSMTPUser=xxxx@xxxx.com AlertEMailSMTPPass=xxxx PHPEnable=No PHPAllowRemote=No AlertEMailSMTPServer=xxxx.xxx.xxx AlertEMailSMTPPort=25 AlertEMailRecip=xxxx@xxxx.com AlertEMailSendInfo=No [Inbound SMS Routing] [SMPP - 203.xxx.xxx.xx:xxxx] GSMPackLongSMSWithMessageClass=Yes SMPPVersion=v3.4 UserName=xxxx Password=xxxxx SenderAddress=+8210xxxxxxxx SenderAddressOverride=Yes Receive=No ReceiveMMS=No UseSSL=No LongSMSAlt=Yes KeepAlive=58 RemapMessageClassDCS=No <------ Input this parameter | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4031 Registered: 08-2008 |
Hi Johnny, If this setting is applied in an [SMPP - server:port] section, it applies to that connection only. If the setting is applied in the [SMPP] section (which might not exist until you create it), it applies to all SMPP connections. By default, NowSMS avoids using any SMS data coding values that are not supported by the SMPP 3.4 specification. The SMS message class is encoding as part of the SMS DCS (SMPP data_coding) variable value. By default, NowSMS performs the following changes to avoid illegal SMPP values: 0x10 => 0xF0 0x11 => 0xF1 0x12 => 0xF2 0x13 => 0xF3 0x18 => 0x08 0x19 => 0x08 0x1A => 0x08 0x1B => 0x08 The first four conversions should be OK in all scenarios, as the different values have the exact same meanings. However, the last four conversions apply to Unicode messages, and cause the SMS message class to be lost. This is necessary because to strictly follow the SMPP specification, it is not possible to create a data_coding value that specifies both Unicode and message class. Some SMPP providers may map the SMPP data_coding value directly to the GSM SMS DCS value, even if the value is not valid per the SMPP specification. The RemapMessageClassDCS=No setting tells NowSMS not to make these changes and to allow these values that are not valid in a strict SMPP implementation. -- Des NowSMS Support | |||
