Author: me, some time in the past.
Source: /~dexter/work/asterisk-chan-dongle/patch.patch.txt

Author: me, some time in the past.
Source: /~dexter/work/asterisk-chan-dongle/patch2.patch.txt

Author: me, some time in the past.
Source: /~dexter/work/asterisk-chan-dongle/patch3.patch.txt

Author: me, in August 2013.

Author: novaktmp, 2014-12-01 17:42:52
Source: https://forum.openwrt.org/viewtopic.php?id=54343

Slight adaptations by me.

Author: mio
Source: bg111#153

Not using full 3GPP version from https://code.google.com/p/
  asterisk-chan-dongle/issues/detail?id=140 because of the issues
described there.

This should simply fix that you don't get a truncated SMS because of an
@ sign.

USSD for E261 works now.

Source: https://code.google.com/p/asterisk-chan-dongle/issues/detail?id=17

Now do:

    ./configure --with-astversion=110102

if you have Asterisk version 11.1.2.

Thanks @bg111 for the review.

Also move the ASTERISK_VERSION_NUM to config.h.

As suggested by @arekm. Note that "010813" does not work, as gcc will treat
it as base 8.

According to the bug report by Marcelo Fernandes Vianna:
> Under some circumstances (if parsing the sms returns -1 in
> at_response.c), even if sms is disabled in dongle.conf,
> receiving a sms can still crash an ongoing call.

Thanks for the suggested patch. Refactored and merged.
Closes #7.

Declare AST_MODULE_SELF_SYM=__internal_$(module_name)_self.

Character conversion assumed UCS-2, which handles only the Basic
Multilingual Plane, but various parties will have switched to using
UTF-16 there.

Fix suggested by @fadasi. Reported and tested by @pjmichel. Thanks!
Closes #8.

@fadasi observed addresses with 0xD0 and 0xD1 (NPI is UNKNOWN or E164)
in the wild. Fix comparisons to only check the TON.

Closes #9.

Merge fixes from upstream bg111/asterisk-chan-dongle

Allow D0 and D1 for addresses

Tested by @fadasi. Thanks!

Now you can do this:

    ./configure --with-astversion=140000 \
        --with-asterisk=$HOME/src/asterisk-14/include
    make clean all

And:

    ./configure --with-astversion=10800 \
        --with-asterisk=$HOME/src/asterisk-1.8/include
    make clean all

Etc..

Fixes #15 but doesn't explain it yet.

Closes #15.

Inspired from http://a.dmin.pro/?p=2712 (presumably October 4, 2011 by arturius)
Also adds DongleSendUSSD and DongleSendSMS dialplan functions examples

For more visibility and traceability, the unmodified code style has not been changed

Adds a DongleSendUSSD function (Device, USSD) dialplan function

Thanks @fadasi!

Clarifies the "no makefile.am" problem from #18, but doesn't fix it.

Reported by @k008 in ghwdoekes/asterisk-chan-dongle issue #20.

This should clarify a few things.

Closes ghwdoekes/asterisk-chan-dongle issue #20.

    make check

to build and run tests.

Cleanups were required to even begin attempting to fix #28.

See bug #13. This creates stub tests. They're disabled, since it's
broken at the moment.

Most of this patch was taken from:
bg111#183
==>
bg111#214

Some changes were elided because:
- of uncertainty of their workings
- they did not improve the results of the available tests

----

From 2aba9dd Mon Sep 17 00:00:00 2001
From: Rodrigo Freire <[email protected]>
Date: Fri, 28 Aug 2015 16:10:20 -0300
Subject: [PATCH] Resolves bg111#183

From: HPS <[email protected]>
From: Shabbira <[email protected]>

Subject: Parses correctly multi-part SMS messages
Comitter: Rodrigo Freire <[email protected]>
Signed-off-by: Rodrigo Freire <[email protected]>

This patch was retrieved from
https://code.google.com/p/asterisk-chan-dongle/issues/detail?id=183
Now parses correctly multi-part SMS Messages. Verified on a Huawei
E303S.

----

Closes #13.

Closes #28.

Closes #24. Thanks Lynxie (@lnx13) for the report.

A better fix than the previous @ replacement in 897b27c.

Fixes #30 I think.

It appears there previously was a global round_robin struct that had to
be mutex protected, but it has been refactored to use locally scoped vars
instead.

Closes #19, reported by @vitasgul, @multijohn and Garrone Joseph
(@garronej).

Cause found through diligent bug reporting and testing by Garrone.

…trol

Add instructions for applying Jitter buffer and automatic gain control

Thanks @garronej!

Instead of disconnecting a standing call, we ignore the message.

Closes #35. Requested by @vitasgul.

Closes #36. Requested by @Andrik45719.

This fixes broken audio from asterisk toward the GSM network. Issue was
originally reported here: openwrt/telephony#7.
Github user @ljakob provided this patch and reports success:

(Sep 9, 2015)
> Hi, I've used the patch over the last month on my box and it works
> perfectly. Audio gain from my old x86 installation had to be copied but
> that was expected. There have been at least 100 calls without any
> problems.

Signed-off-by: Sebastian Kemper <[email protected]>
Code cleaned up by wdoekes.

Closes #42.

This reverts commit ab93953.

Apparently there was too much byteswapping (on big-endian machines)
going on with both ab93953 and 53e83a4. Reverting ab93953 appears to
work for @Infactum.

Closes #44.

This should probably fix call drop issues with E3131A modem (same as
E303).

I cannot quickly find documentation about what the timeout "should" be,
but using 3 timeout classes with short/medium/long makes more sense to
me than having the classes defined by the duration.

Please report any issues that arise from this change.

Suggested-by: @mthqwork
Closes: #50

Previously ./configure would continue after not finding DESTDIR for the
module and then fail at 'make install'. Now it requires you to set
DESTDIR if autodetection fails. Also added lib64 in the default paths to
try.

Reported-by: @alaa2003
Closes: #49

gcc apparently groks "/* fall through */" as well as __attribute__
((fallthrough)) which probably is not supported on all compilers.

After looking at specs from
http://www.3gpp.org/ftp//Specs/archive/23_series/23.038/ it looks like
it should allow more than we did.

Closes #41 (I think).

Closes #53, reported by @standardgbg.

See: http://www.3gpp.org/ftp//Specs/archive/23_series/23.040/23040-e00.zip

Huawei E3531 works fine with firmware 21.318.29.00.769, voice and sms, except USSD.
Adding it to seven_bit_modems[] solves issue. (#56)

The AT+COPS command has been observed to return similar but different
provider names. Sometimes with a trailing illegal character, or a
trailing @.

Dongle make/model E1550 (patched for voice support), identified by Linux
as "Huawei Technologies Co., Ltd. E161/E169/E620/E800 HSDPA Modem".

Example output:

    AT+COPS?
    +COPS: 0,2,"25020",2

    AT+COPS=?
    +COPS: (2,"TELE2 RU","TELE2 RU","25020",2),
           (1,"MTS-RUS","MTS","25001",2),
           (1,"Beeline","Beeline","25099",2),
           (1,"MegaFon)

    AT+COPS=?
    +COPS: (2,"TELE2 RU","TELE2 RU","25020",2),
           (1,"MegaFon RUS","MegaFon","25002",2),
           (1,"Beeline","Beeline","25099",2),
           (1,)

    AT+COPS=?
    +COPS: (2,"Tele2@","Tele2�","25020",2),
           (1,"MTS-RUS","MTS","25001",2),
           (1,"Beeline","Beeline","25099",2),
           (1,"MegaFon RUS)

(that replacement character (U+FFFD) is probably something else; likely a
single octet in the >=128 range)

A dongle change (same make/model) did not help. A simcard change did not
help. Likely culprit for now seems to be the provider (Russian Tele2?).

This changeset drops trailing "@" and trailing non-printables from the
provider name. It would still switch from "TELE2 RU" to "Tele2", but not
to something with unreadable characters.

Closes #39.

This also fixes this error:

    json.c:607 ast_json_vpack: Error building JSON from '{s: s, s: s}':
      Invalid UTF-8 string.

Generated at:

    for (idx = 0; idx < ITEMS_OF(dev_vars); ++idx) {
        # dev_vars[1] == { "DONGLEPROVIDER", pvt->provider_name }
        pbx_builtin_setvar_helper(channel, dev_vars[idx].name,
                                  dev_vars[idx].value);
    }

Because newer Asterisken use JSON to publish these messages, and that
character (which isn't U+FFFD) is illegal UTF-8.

Closes #69.

Thanks go to sergio (@532910) for debugging and testing this issue.

Add --with-iconv option to specify a different path

It's old, and conflicts with #75

Concatenated SMS support; Complete locking and single shift tables.

Thanks Max von Buelow!

The casting of functions taking fewer parameters than were given
probably did work on most platforms with common calling conventions. But
the calling convention is not defined by us. And the C-style cast
removes all other sanity checks as well.

"[ignore] AT+CNUM errors [returned by] E3531s-2"

Thanks @magcks!

Closes #74, reported by @ruijorgesilva1.

It has been observed that CMTI notifications can stop when the internal
memory of the E1750 dongle is full. Instead an SMMEMFULL indication is received.

This patch includes multiple fixes:
- Always poll SMS messages during startup.
- Only poll one SMS message at a time, by keeping a bitmap of polled messages.
- Only delete message after successful reception.

Assume that no more than 256 SMS's will be stored by the external SIM card.

Signed-off-by: Hans Petter Selasky <[email protected]>

Try to use length field at beginning of TP-DA, instead of assuming fixed length.

[dongle0] Error parsing incoming message '+CMGR: 0,,24
06917429000102068E0A917419778290023020020200400230200202004000' at position 70:
Good report, but delivery failed

Signed-off-by: Hans Petter Selasky <[email protected]>

Thanks @hselasky.

…oding and UCS-2 decoding; Implemented delivery reports; Fixed USSD generating

Reworked PDU parsing; Delivery reports

Fixed issue #85

… incoming_sms.

Signed-off-by: Hans Petter Selasky <[email protected]>

Signed-off-by: Hans Petter Selasky <[email protected]>

Signed-off-by: Hans Petter Selasky <[email protected]>

Signed-off-by: Hans Petter Selasky <[email protected]>

Signed-off-by: Hans Petter Selasky <[email protected]>