| DSC and PID not working |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through January 23, 2007 ⬆ |
◄ ► |
| Author | Message | |||
| Gambia New member Username: Nowmessage Post Number: 1 Registered: 09-2004 |
Hello Bryce, I would like to thank you for your contiunous support. I downloaded latest version of nowsms and I have 2 questions: UNICODE FLASH SMS: English Flash SMS works fine, but Unicode no. It arrives as normal message even i set the DSC value to 18, http://127.0.0.1:8800/?PhoneNumber=phonenumber&text=this+is+a+test+message&DCS=1 8 REPLACEMENT TYPE: I tried to set the PID in the URL to any value from 41- 47. but the message does not arrvive as well tried to use default nowsms webadmin to send the message, but the same. http://127.0.0.1:8800/?phonenumber=1234567890&text=Hello&PID=41 The log shows: INVALID SOURCE ADDRESS TON Ton adress is set to 0.. i change it to 1 but nothing happened. Please advice. Kind regards, | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6750 Registered: 10-2002 |
Hi, 1.) Unicode Flash SMS will not work via an SMPP connection. Unfortunately, this is a limitation of SMPP 3.4 specification, where it is not possible to specify the GSM message class (Class 0 for Flash SMS) in combination with any settings that specify the character set to be used. So you can either specify message class 0 or indicate that the character set of the message is Unicode, but not both. As a result, with an SMPP connection, you can only send plain GSM text messages as a flash SMS. I am not aware of any alternatives for specifying within an SMPP submission allow a message to be sent as Flash SMS Unicode. The little-implemented SMPP v5.0 specfication does not appear to address this either. Both specifications talk about using an optional dest_addr_subunit parameter instead of encoding GSM message class control in the DCS (data_coding) parameter. However, the dest_addr_subunit parameter does not support the class for flash SMS. You may want to ask your provider if they have any special way of supporting this. 2.) There are no limitations on the PID values. PID values are encoded directly into the SMPP "protocol_id" variable. Unfortunately, it would appear that your SMPP provider does not support these "protocol_id" settings ... causing them to reject the message with an unrelated error. You may want to ask your provider why messages are rejected with this error code when you try these "protocol_id" values. I understand that it can be a challenge to be put in contact with anyone technical enough to answer this question, but unlike the first issue, there is no technical ambiguity with regard to this setting ... your provider would need to explain why the message is being rejected. -bn | |||
