I, also, haven't come across any SMSC's using packed GSM03.38 encoding, only 7 bit GSM03.38 transported in 8 bit octets.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00099.html On Friday, 2003-12-26 at 10:40:39 PM, Ian Cass scribbled: > Rafael 'Dido' Sevilla wrote: > > > The SMPP SMSC made by ZTE (http://www.zte.com.cn) apparently sends and > > expects to receive GSM SMS text packed in that way, oddly enough. Does > > SMPP 3.3/3.4 say that it should be received unpacked or packed? Don't > > have the specs on hand... > > Well, section 4.4 submit_sm says that a short_message is field type Octet > String. Section 2.11 defines this as "Octet String A series of octets, not > necessarily NULL terminated". 7bit characters are not octets, they are > septets. However, you could argue that by packing them, you are transferring > them as octets thereby fulfilling the spec. > > Having said that, SMPP does not define any method to tell you that the data > is in fact packed. Section 5.2.19 data_coding *is not* the GSM DCS field > even though most SMSC's use it as such. SMPP uses data_coding merely as a > character set indicator & breaks other functions of GSM03.38 DCS out into > other fields. SMPP data_coding does not allow for indication of packed data > & there is no other field available to indicate that the data is packed. Are > ZTE treating the data_coding field as GSM DCS & setting the packing bit? > > Strictly speaking, packed text is not allowed in SMPP. I don't know of any > other SMPP SMSC that does this by default. > > -- > Ian Cass > -- Benjamin Lee Melbourne, Australia "Always real." http://www.realthought.net/ __________________________________________________________________________ I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this. -- Emo Phillips
