Re: Fix EMS + concat message, cleanup gnokii.c

[Pawel Kot]

On Sat, 8 Jun 2002, Pavel Machek wrote:

> Hi!
>
> > > > Bitmaps know NOTHING about UDH. Don't mess it.
> > >
> > > They have to. Whole bitmap is in the UDH. Yep, UDH is then 128+
> > > bytes. I do not want to encode whole bitmap inside EncodeUDH...
> >
> > No. Pavel, please DO read the specifications first. Bitmap is NOT
> > UserDataHeader.
>
> EMS guidelines:
>
> picture size is included in IEDL field, and that is in turn included
> in TP-UDL field. It seems to me like EMS pictures really are in
> UDH. (Or what's definition of "being in UDH"? Being included in TP-UDL
> seems reasonable definition...)

Again. Look at the SMS layout:

.... | A | .... | B | ... | C | D.... | E .... |
A is User Data Header Indicator. It's just one bit.
B is User Data Length. It contains the length of the User Data field.
There are following cases:
 - User Data is coded using Default Alphabet (7bit), then UDL is number of
the septets in the UserData plus User Data Header (including the
alignment)
 - User Data is coded 8bit, then UDH is number of the octets in the UD +
UDH
 - User Data is cuded using UCS2, then as 8bit.

Now, if A is set, C denotes User Data Header length, and D is User Data
Header (it may contain many parts). If A is not set, C and D are not
present.

D is User Data. I belive all picutres belong to User Data.

I can send you GSM spec 03.40 (AFAIR) describing this.

There's a common way (or few common ways) to encode the bitmap. There's
some boundary around some of them needed for some SMS schemas. What I
would like is to move image packing into the boundary into the gsm-sms.c,
not in the gsm-bitmaps.

pkot
-- 
mailto:address@hidden :: mailto:address@hidden
http://kt.linuxnews.pl/ :: Kernel Traffic po polsku