oh - I get it : the UDH is already encoded correctly using the right DCS
before the call to at2_pdu_encode(), and then at2_pdu_encode() only
needs to translate the bitstream to hex strings, and in the length
computation it computes how many septets are in the already encoded bit
stream - right ?

Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]

--
Don't ever take a fence down until you know why it was put up.
        -- Robert Frost

-----Original Message-----
From: Andreas Fink [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 13, 2002 6:56 PM
To: Oded Arbel
Cc: [EMAIL PROTECTED]
Subject: Re: A question about PDU encoding in smsc_at2


>Hi list.
>
>I was wandering about this part from smsc_at2.c :
><snip>
>  if(octstr_len(msg->sms.udhdata)) {
>         if (msg->sms.coding == DC_8BIT || msg->sms.coding == DC_UCS2)
{
>             len += octstr_len(msg->sms.udhdata);
>         } else {
>             /* The reason we branch here is because UDH data length is
>determined
>                in septets if we are in GSM coding, otherwise it's in
>octets. Adding 6
>                will ensure that for an octet length of 0, we get
septet
>length 0,
>                and for octet length 1 we get septet length 2.*/
>             len += (((8*octstr_len(msg->sms.udhdata)) + 6)/7);       
>     }
>     }
></snip>
>
>if adds the length of the UDH differently for 7 bit then to 8 bit
>encoding (as per the message coding)
>
><snip>
>     /* udh */
>     if(octstr_len(msg->sms.udhdata)) {
>             pos += at2_encode8bituncompressed(msg->sms.udhdata,
>&pdu[pos]);
>     }
></snip>
>
>and then always code the UDH as 8 bit.. is that OK


The final data is always octets (8bit). If the source data is 7 bit, 
then its packet into octets of 8 bit. This means if you have 7 bit 
data you need 7/8 less the spac on the output.

Take a look at the corresponding ITU spec.

-- 

Andreas Fink
Fink-Consulting

------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729  Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail:  [EMAIL PROTECTED]  Homepage: http://www.finkconsulting.com
------------------------------------------------------------------
Something urgent? Try http://www.smsrelay.com/  Nickname afink

Reply via email to