* remove $config->{sms}{smsc} selection as
there is no such thing as smsc in ngcp_panel.conf
* remove charset from the send_sms query form as charset
is now set in the smsc peer group and taken from the template
Change-Id: I12ac8b74d2923a54194685c3f5e28a37f8df1902
* smsc_peer preference is mandatory for NGCP::Utils::SMS::send_sms()
and contains a handle of one of the avilable group=smsc id
* sms_journal is extended to also store smsc_peer
Change-Id: I1a368b55c263bb5ea2acda004bbaf463d6431413
* moved sms_journal record creation into a new
NGCP::Utils::SMS::add_journal_record()
* 'cli' is used when sending sms to store
user_cli or cli subscriber preference.
that is useful for calls where caller is a
remote number
Change-Id: I80bc31da294a56b302e154133525eea187ab6aff
* billing is split into 2 parts:
- init_prepaid_billing (reserves billing/creates session)
- perform_prepaid_billing (commits or cancels the session)
* when sms fails to be sent the billing session is canceled
(was committed before, regardless)
* NGCP::Panel::Entities::post
- do not do $self->return_representation_post() if
api_error_message is present, therefore, the actual
error is returned
* sms_journal item is now created also in case of an error
* improved errors indication
Change-Id: I454b8c6a1c04d743ee82e03f8621c7cc4c7c4f98
Also take into account latin1 characters when calculating number
of parts for billing, because SMS uses some special derivation of
latin-1 and can therefore encode certain chars without the use of
UTF-8.
Change-Id: Ia7f02a3cf96040e5ad23da9037d05422beecea74
Except for greek characters, which are available in the
GSM 03.38 encoding but not in latin-1, all other latin-1
characters can be sent with coding 0 (7bit).
We neither support the € sign available in the GSM extended
encoding, but for unknown reasons the rest of the extended
char sets (which are part of ascii anways) do work.
So, no € and no greek chars inside coding=0.
Change-Id: Ia87e337772e126b6a0a95b53acba0a369b71e660
In GSM encoding for ascii-only messages, we can have 160 chars in
a single message, or 153 chars each for multi-part messages.
In UTF8, it's 70 and 67, respectively.
Change-Id: I50d95f9d0335b42457238234a4fd552401c8fb26
we store it as is. but in order to preserve all information on callforwards,
we send those messages with the same coding as we receive them.
Change-Id: I3f72db4e19291aa2fb54d7aac000f88ad1874295
Kirill Solomko
Richard Fuchs
Andreas Granig
Gerhard Jungwirth