ok... mo-recode should be the solution... 2010/8/16 Emanuele Carbone <[email protected]>
> Hi, > > i'll show you what i see: > kannel version: 1.4.3 > > received an emi packet: > > EMI2[4883883]: Got packet from the main socket > EMI2[4883883]: emi2 parsing packet: > <31/00134/O/52/4883883/3391234567////////////0000/160810090125////4/0160/0042005600320020003100200039002000310037///1/////// > *020108*///91> > EMI2[4883883]: emi2 sending packet: <31/00020/R/52/A///99> > > in my access log i see: > > Receive SMS [SMSC:4883883] [SVC:] [ACT:] [BINF:] [FID:] [from:3391234567] > [to:4883883] [flags:-1:2:-1:0:-1] > [msg:20:0042005600320020003100200039002000310037] [udh:0:] [spservice:] > [extension:] [spclass:-1] > > I expect to find text, not other. this is produce a call to my sms-service > > Starting to service <> from <3391234567> to <4883883> > Queue contains 0 pending requests. > DEBUG: Parsing URL ` > http://host/smsc.php?from=3391234567&to=4883883&text=%00B%00V%002%00+%001%00+%009%00+%001%007&smscid=4883883 > ': > DEBUG: Scheme: http:// > DEBUG: Host: host > DEBUG: Port: 80 > DEBUG: Username: (null) > DEBUG: Password: (null) > DEBUG: Path: /sms/smsc.php > DEBUG: Query: > from=3391234567&to=4883883&text=%00B%00V%002%00+%001%00+%009%00+%001%007&smscid=4883883 > DEBUG: Fragment: (null) > DEBUG: HTTP: Opening connection to `host:80' (fd=32). > DEBUG: Socket connecting > DEBUG: Get info about connecting socket > DEBUG: HTTP: Sending request: > ... > ... > > the syntax error is the response my script produce because it does not > know how to interpret the sequence 0042005600320020003100200039002000310037. > it expects only text. > > I hope that my situation is explained clearly. > > > regards > > 2010/8/16 Nikos Balkanas <[email protected]> > >> Hi, >> >> Hmmm... I wonder why. alt-charset means something else for the EMI driver. >> Assuming that you use a fairly recent Kannel version (>1.4.1) it should be >> converted to utf-8. Please post detailed smsbox logs showing the syntax >> error along with the corresponding bb logs. This time give a few lines >> context. >> >> >> BR, >> Nikos >> ----- Original Message ----- From: Emanuele Carbone >> To: Nikos Balkanas >> Cc: [email protected] >> Sent: Monday, August 16, 2010 12:49 PM >> Subject: Re: EMI XSer 02, GSM DCS information >> >> >> >> Hi Nikos, >> >> thanks for your reply. This is a dump from my bb logs: >> >> >> 67/00342/O/52/4894890/3311234567////////////0000/130810164028////4/0992/0041004E004F004E0020003300 >> >> 3300380036003900320036003500380032002000430068006500200065007400E1002000680061006900200069006E00200066006F0074006F003F0020005100750061006E0074006F002000730065006900200061006C0074 >> 0061003F00200052006900630063006100720064006F///1///////020108///49 >> >> you are right, this is a unicode message. The correct xser field is 020108 >> not 020100 (that indicate 7-bit message). >> >> Now, the problem is that kannel when receive this type of message pass it >> as is to my sms-service that response with syntax error. >> >> Can i resolve this issue with alt-charset on my smsc configuration? >> >> thanks in advance, >> >> regards >> >> >> 2010/8/16 Nikos Balkanas <[email protected]> >> >> Hi, >> >> Kannel flags indicate unicode, not even binary. Kannel supports 7-bit, but >> in this case you recive unicode. The Xser field comes also from the SMSc. I >> don't know what the fields of Xser mean, but you can see the actual SMS >> received from bb debug logs to decide for yourself if it is Unicode or >> 7-bit. It is probably Unicode. >> >> If that is the case contact your SMSc and ask them what value they are >> sending for the Xser field. Else post detailed bb logs with the MO >> reception. >> >> BR, >> Nikos >> ----- Original Message ----- From: Emanuele Carbone >> To: [email protected] >> Sent: Monday, August 16, 2010 11:03 AM >> Subject: EMI XSer 02, GSM DCS information >> >> >> >> Hi guys, >> >> i have an issue with EMI protocol for the MO scenario. Sometimes my >> gateway receive message with binary body. When received this type of >> message, i found >> >> flags:-1:2:-1:0:-1 , with coding set to UCS-2, and the XSer field with >> this information, 020100. >> >> In the emi specification 4.0, i found: >> >> Example encoding of XSer Type of service 02, GSM DCS information: >> >> 020100, meaning that the DCS value 00 (0000 0000 binary) is used. >> >> According to the GSM03.38 specification, this means 7-bit default >> alphabet, no >> compression, no message class meaning. >> >> Now, i dont understand if this type of message must be considered as >> 7-bit, and if so, kannel does not support this specification? >> >> >> thanks. >> > >
