This isn't Kannel's decision to make; this is data set by the
end user's
telephone, which may have requirements neither you nor I are
(or could
be) aware of. The analogy to a case-insensitive filesystem
namespace is
quite fitting if you think about it carefully.
I did look at
Citando Paul Keogh [EMAIL PROTECTED]:
This isn't Kannel's decision to make; this is data set by the
end user's
telephone, which may have requirements neither you nor I are
(or could
be) aware of. The analogy to a case-insensitive filesystem
namespace is
quite fitting if
If it's DCS is really broken up in MO SMPP, then please re-send the
patch. Use [PATCH] in the mail subject line.
And try to explain in the mail what the problem was and what you patch
does to fix it. Thanks in advance.
I'm definetly willing to review it and vote.
At least we can offer you that
Stipe Tolj wrote:
If it's DCS is really broken up in MO SMPP, then please re-send the
patch. Use [PATCH] in the mail subject line.
The SMPP patch just fixes the following issues:
*) Kannel coding param is overwritten with wrong values by pdu_to_msg
(e.g. a Nokia business card, which is 8-bit
Citando Stipe Tolj [EMAIL PROTECTED]:
If it's DCS is really broken up in MO SMPP, then please re-send the
patch. Use [PATCH] in the mail subject line.
And try to explain in the mail what the problem was and what you patch
does to fix it. Thanks in advance.
I'm definetly willing to review
Citando Dave White [EMAIL PROTECTED]:
Say we have a binary (8-bit) message without compression, but with
message class 1. These are pretty common; Nokia phones use these for
most Smart Messaging MO's.
There are two valid representations of this as a DCS octet:
(WARNING -- try a
Citando Dave White [EMAIL PROTECTED]:
Say we have a binary (8-bit) message without compression, but with
message class 1. These are pretty common; Nokia phones use these for
most Smart Messaging MO's.
There are two valid representations of this as a DCS octet:
(WARNING -- try a
Bruno Rodrigues wrote:
Kannel should decide for the 0x0x spelling unless you pass alt-dcs field,
which will select the 0xFx spelling.
This isn't Kannel's decision to make; this is data set by the end user's
telephone, which may have requirements neither you nor I are (or could
be) aware of.
Citando Dave White [EMAIL PROTECTED]:
Bruno Rodrigues wrote:
Kannel should decide for the 0x0x spelling unless you pass alt-dcs
field,
which will select the 0xFx spelling.
This isn't Kannel's decision to make; this is data set by the end user's
telephone, which may have
Bruno Rodrigues wrote:
It's not a Kannel decision, it's a kannel option
did you understand the you can generate every valid dcs ?
did you understand that third parties, which might not have a clue about
dcs and
like to just say mclass=1 for flash or coding=3text= for unicode
accented
chars?
Citando Dave White [EMAIL PROTECTED]:
The GSM data coding scheme (DCS) is broken up by Kannel into various
seperate fields, as I've seen. The protocol id, however, is passed
through as an opaque octet.
Why is that? PID could concievably be treated the same way as DCS, and
broken up into
11 matches
Mail list logo
