Re: GSM 03.38 packed data in SMPP messages

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