Invalid DCS on sending SMS to Agilent 8960 | Search |
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through January 17, 2005 ⬆ |
◄ ► |
Author | Message | |||
Anonymous |
Hi, I'm having a problem when sending SMS to the Agilent 8960 from a phone simulator. The Agilent responded back to NowSMS with the following message: "HTTP/1.0 400 Invalid characters in DCS parameter" The following URL Template Text and Binary were used: /sms/send/?PHONENUMBER=@@PhoneNumber@@&TEXT=@@TEXT@@&PID=@@PID@@&DCS=@@DCS@@&SEN DER=@@SENDER@@ /sms/send/?PHONENUMBER=@@PhoneNumber@@&DATA=@@DATA@@&UDH=@@UDH@@&PID=@@PID@@&DCS =@@DCS@@&SENDER=@@SENDER@@ The DCS field sent to Agilent was having a 'F5' value in it, which is Class 1 type (ME Specific). Is this a problem? I've removed the UDHI field from the template because the Agilent was complaining about the UDHI field, which was empty when sent to Agilent. HELP...HELP... Thanks. | |||
Dono Unregistered guest |
Just want to add what I've posted earlier. I was sending an MMS message from a phone simulator to a phone connected to Agilent 8960 Series 10 running GSM/GPRS Lab Application rev. D thru SMSC/MMSC (NowSMS). As a result, NowSMS sent an HTTP GET to Agilent 8960 which contained the format specified in the settings (see URL Template) and the Agilent responded back (after an Ack) indicating "Invalid characters in DCS parameter". | |||
Dono Unregistered guest |
Never mind, I've found the problem.... Thanks. | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3198 Registered: 10-2002 |
Hi Dono, If you happen to pop back into the forum, I'd love to know how you resolved the problem. We have a number of customers using Agilent equipment, but I'm not familiar with the details of the setup. -bn | |||
Dono Unregistered guest |
Hi Bryce, the problem turned out to be a settings related. As shown in my 1st posting, the URL template for both Text and Binary have DCS=@@DCS@@ format which I copied and pasted from Agilent's SMS settings. It turned out the Agilent won't accept any Hex value for DCS (and PID too)... So the fix should be very easy, changed the format to DCSDECIMAL=@@DCSdecimal@@ By the way, as I evaluating NowSMS version 5.50 looks like there is a bug (or perhaps unsupported feature) in sending M-Delivery.ind. I've a setup where there was a phone simulator (running on PC) and a phone connected to Agilent. If the phone simulator was the sender of an MMS message, the M-Delivery.ind was not sent back to the phone simulator (after delivery), instead it was sent to the receiver (in this case the phone connected to Agilent). On the other hand, if the phone (Agilent) was the sender, the M-Delivery.ind was sent back to the phone (Agilent). So, I added another phone simulator to the setup (on different PC), sent a MMS message to another simulator and still M-Delivery.ind was sent back to the phone (Agilent) which was not the sender and receiver. Is this a known issue in NowSMS 5.50? | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3212 Registered: 10-2002 |
Hi Dono, Thanks. Hopefully that info will help others using Agilent kit. I'm not aware of any issues with M-delivery.ind being sent to the wrong device. I suspect the issue is related to the MMS Server URL that you are using. In this type of configuration, the sender identity is included in this URL. The delivery indication is going to go back to the address that we think to be the sender. -bn | |||
Dono Unregistered guest |
Hi Bryce, now I've another question regarding this DCS thingy. How would NowSMS determine the DCS value when sending a SMS over HTTP? Can we control that? As mentioned earlier in my first message, the DCS was 'F5', and after changing to decimal value, the DCS was '4'. Is this a correct translation from hex to decimal in DCS? Thank you. | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3285 Registered: 10-2002 |
This explanation is going to ramble a bit, but hopefully this will help you ... When generating WAP push or MMS messages, most versions of NowSMS use a hard-coded DCS value of F5 (hex value). In v5.50, we changed the default to 4. In patch releases since v5.50, we have changed the default back to F5 again. Basically, either value is fine for these types of messages. The default value used by NowSMS can be overridden with a setting in SMSGW.INI, under the [SMSGW] header, you can specify: BinaryDCS=xx We originally used F5 because that is the binary DCS value that is used in most Nokia Smart Messaging examples ... and WAP push over SMS uses the concept of encoding port numbers which originated in Nokia Smart Messaging. However, F5 is a GSM specific value. And we have found that some customers in North America and the Carribean have had to use a value of 4 instead, as their SMSCs would not properly route messages with the F5 setting. Since we were telling some customers to manually set BinaryDCS=4 in their SMSGW.INI, in v5.50, we decided to change the default setting to 4. However, that change caused problems for others. Most specifically, this DCS value does not seem to get routed properly for messages sent via GSM modems on Vodafone UK, at least one of the major operators in Singapore, and some other locations as well. Therefore, in post-v5.50 patches, we have changed the default back to F5. It really doesn't make any difference. We have observed various operator MMSCs around the world, some using F5 as the DCS when sending out MMS notifications, some using 4. As you noted earlier in this thread, DCS=F5 means Class 1 (ME specific), binary content. DCS=4 indicates binary content, but does not specify the message class. The message class setting is not important. What is important is the indicator that the message content is binary. -bn | |||
Jamie Allan New member Username: Jamie Post Number: 1 Registered: 10-2004 |
Hi Dono, The Agilent 8960 does actually support hex values for both DCS and PID. However, when configuring the 8960 as an SMSC in the Now SMS gateway, you need to enter these parameters in the template text/binary URLs as DCSHEX=@@DCS@@ or PIDHEX=@@PID@@. The problem you encountered was due to asking the gateway to generate a hex value for the data coding scheme (i.e. the @@DCS@@ tag) but assigning this value to the integer DCS parameter the 8960 uses. Unfortunately, the solution you outlined of sending a DCSDECIMAL=@@DCS@@ parameter in the request will not work. The "DCSDECIMAL" parameter is not supported by the 8960 (instead, for decimal entry, the 8960 accepts a "DCS" parameter like the one you were originally trying to use). The 8960 will just ignore any unsupported parameters received in a request, it does this to avoid problems with mandatory parameters being sent in requests that are of no relevance to the 8960 (such as the @@Phonenumber@@ parameter sent by the NowSMS gateway). As a consequence, although the 8960 is now accepting the requests and you are not getting an error, the DCS value will not be explicitly set for the SMS message sent to the phone, the default of 0 will be used instead for every message you send. If you are sending anything other than simple text messages I would expect this to result in problems when the phone receives the message. Regarding the UDHI value, the 8960 does not need this to be included in a request but if it is not present, the UDHI will instead be automatically determined based on the length of the UDH value in the request. if the UDH parameter is included in a request and its value is anything other than an empty string, the UDHI will be set to 1 for the message when it is forwarded to the phone. The UDHI is instead set to 0 if no UDH parameter is found in the request or the UDH value found is an empty string. To try and simplify things a bit, if you are using an 8960 in conjunction with the Now SMS gateway then the following strings should be used when you are configuring the gateway: Template Text URL: /sms/send/?TEXT=@@Text@@&PID=@@PIDdecimal@@&DCS=@@DCSdecimal@@&SENDER=@@Sender@@ &garbage=@@phonenumber@@ Template Binary URL: /sms/send/?DATA=@@Data@@&PID=@@PIDdecimal@@&DCS=@@DCSdecimal@@&SENDER=@@Sender@@ &UDH=@@UDH@@&garbage=@@phonenumber@@ There are other variants of these strings that would also work but would have exactly the same effect so I won't go into detail here. Hope this was useful, Regards, Jamie Allan, Agilent Technologies. | |||
Jamie Allan New member Username: Jamie Post Number: 2 Registered: 10-2004 |
Apologies, there are some rougue <space> characters being entered into the strings I listed above whenever I post them on this forum. Be sure to remove the <space> characters immediately after the SENDER=@@Sender@@ parts of the strings above before entering them in the gateway. Sorry for any confusion, Regards, Jamie | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3607 Registered: 10-2002 |
Jamie, I'm not sure about Dono, but I found your explanation very helpful, and I'm sure that I will reference people to it frequently! -bn | |||
bishu thomas New member Username: Bishu Post Number: 8 Registered: 10-2004 |
Jamie I am trying this configuration where the agilent can be configured as a SMSC and then the WAP gateway and the NowSMS MMSC. Would like to discuss with you the details. Please respond to bishu@sasken.com if you are ok with it. expecting your response. bishu |