osmo-msc/openbsc/src/libmsc/smpp_smsc.h

167 lines
4.0 KiB
C
Raw Normal View History

#ifndef _SMPP_SMSC_H
#define _SMPP_SMSC_H
#include <sys/socket.h>
#include <netinet/in.h>
#include <osmocom/core/utils.h>
#include <osmocom/core/msgb.h>
#include <osmocom/core/write_queue.h>
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
#include <osmocom/core/timer.h>
#include <smpp34.h>
#include <smpp34_structs.h>
#include <smpp34_params.h>
#define SMPP_SYS_ID_LEN 16
#define SMPP_PASSWD_LEN 16
#define MODE_7BIT 7
#define MODE_8BIT 8
enum esme_read_state {
READ_ST_IN_LEN = 0,
READ_ST_IN_MSG = 1,
};
struct osmo_smpp_acl;
struct osmo_smpp_addr {
uint8_t ton;
uint8_t npi;
char addr[21+1];
};
struct osmo_esme {
struct llist_head list;
struct smsc *smsc;
struct osmo_smpp_acl *acl;
int use;
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
struct llist_head smpp_cmd_list;
uint32_t own_seq_nr;
struct osmo_wqueue wqueue;
struct sockaddr_storage sa;
socklen_t sa_len;
enum esme_read_state read_state;
uint32_t read_len;
uint32_t read_idx;
struct msgb *read_msg;
uint8_t smpp_version;
char system_id[SMPP_SYS_ID_LEN+1];
uint8_t bind_flags;
};
struct osmo_smpp_acl {
struct llist_head list;
struct smsc *smsc;
struct osmo_esme *esme;
char *description;
char system_id[SMPP_SYS_ID_LEN+1];
char passwd[SMPP_PASSWD_LEN+1];
int default_route;
int deliver_src_imsi;
int osmocom_ext;
int dcs_transparent;
struct llist_head route_list;
};
enum osmo_smpp_rtype {
SMPP_ROUTE_NONE,
SMPP_ROUTE_PREFIX,
};
struct osmo_smpp_route {
struct llist_head list; /*!< in acl.route_list */
struct llist_head global_list; /*!< in smsc->route_list */
struct osmo_smpp_acl *acl;
enum osmo_smpp_rtype type;
union {
struct osmo_smpp_addr prefix;
} u;
};
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
struct osmo_smpp_cmd {
struct llist_head list;
struct gsm_subscriber *subscr;
struct gsm_sms *sms;
uint32_t sequence_nr;
struct osmo_timer_list response_timer;
};
struct osmo_smpp_cmd *smpp_cmd_find_by_seqnum(struct osmo_esme *esme,
uint32_t sequence_number);
void smpp_cmd_ack(struct osmo_smpp_cmd *cmd);
void smpp_cmd_err(struct osmo_smpp_cmd *cmd, uint32_t status);
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
void smpp_cmd_flush_pending(struct osmo_esme *esme);
struct smsc {
struct osmo_fd listen_ofd;
struct llist_head esme_list;
struct llist_head acl_list;
struct llist_head route_list;
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
const char *bind_addr;
uint16_t listen_port;
char system_id[SMPP_SYS_ID_LEN+1];
int accept_all;
int smpp_first;
struct osmo_smpp_acl *def_route;
void *priv;
};
int smpp_addr_eq(const struct osmo_smpp_addr *a,
const struct osmo_smpp_addr *b);
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
struct smsc *smpp_smsc_alloc_init(void *ctx);
int smpp_smsc_conf(struct smsc *smsc, const char *bind_addr, uint16_t port);
int smpp_smsc_start(struct smsc *smsc, const char *bind_addr, uint16_t port);
int smpp_smsc_restart(struct smsc *smsc, const char *bind_addr, uint16_t port);
void smpp_smsc_stop(struct smsc *smsc);
void smpp_esme_get(struct osmo_esme *esme);
void smpp_esme_put(struct osmo_esme *esme);
struct osmo_esme *
smpp_route(const struct smsc *smsc, const struct osmo_smpp_addr *dest);
struct osmo_smpp_acl *smpp_acl_alloc(struct smsc *smsc, const char *sys_id);
struct osmo_smpp_acl *smpp_acl_by_system_id(struct smsc *smsc,
const char *sys_id);
void smpp_acl_delete(struct osmo_smpp_acl *acl);
int smpp_tx_submit_r(struct osmo_esme *esme, uint32_t sequence_nr,
uint32_t command_status, char *msg_id);
int smpp_tx_alert(struct osmo_esme *esme, uint8_t ton, uint8_t npi,
const char *addr, uint8_t avail_status);
int smpp_tx_deliver(struct osmo_esme *esme, struct deliver_sm_t *deliver);
int handle_smpp_submit(struct osmo_esme *esme, struct submit_sm_t *submit,
struct submit_sm_resp_t *submit_r);
int smpp_route_pfx_add(struct osmo_smpp_acl *acl,
const struct osmo_smpp_addr *pfx);
int smpp_route_pfx_del(struct osmo_smpp_acl *acl,
const struct osmo_smpp_addr *pfx);
int smpp_vty_init(void);
int smpp_determine_scheme(uint8_t dcs, uint8_t *data_coding, int *mode);
struct gsm_sms;
struct gsm_subscriber_connection;
int smpp_route_smpp_first(struct gsm_sms *sms,
struct gsm_subscriber_connection *conn);
int smpp_try_deliver(struct gsm_sms *sms,
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
struct gsm_subscriber_connection *conn, bool *deferred);
#endif