)
>
> Is this valid SMPP traffic? (to use separate encodings for each of the
> parts of a segmented message) I do notice that the GSM7 parts (2-4)
> while definitely encoded as GSM7 are only 73 characters long which
> seems suspicious. At the same time, it seems Kannel should be
> convert
is obviously
corrupt. (immediately below)
Is this valid SMPP traffic? (to use separate encodings for each of the
parts of a segmented message) I do notice that the GSM7 parts (2-4)
while definitely encoded as GSM7 are only 73 characters long which
seems suspicious. At the same time, it seems Kannel
Tolj
Sent: 06 April 2017 11:18
Cc: devel@kannel.org
Subject: Re: Encodings
Am 02.04.17 21:57, schrieb Davor Spasoski:
> Dear kannel users,
Hi Davor,
please don't cross-post into several mailing list, we consider this spaming.
Your questions is more related to internals, so devel@ sho
, that's latin1. Depending on the SMSC type there are different
upstream encodings used as default.
I.e. for SMPP the default encoding (aka data coding scheme, DCS 0x00) is
GSM 03.38.
But then we have alt-dcs and alt-addr-charset that are supposed to
enable GSM-7 alphabet between SMSC
Dear kannel users,
Can someone give precise information what happens encoding wise from smsbox to
SMSC. I understand that as of 1.4.1:
Smsbox i expecting utf-8 by default
Communication smsbox <> bearerbox is only via utf-8
Bearerbox <> SMSC is supposed to be ISO-8859-1
But then we have
