gpt4 book ai didi

sms - 在存在单独的接收器和收发器绑定(bind)的情况下,Kannel 中的 DLR 路由失败

转载 作者:行者123 更新时间:2023-12-04 20:19:40 29 4
gpt4 key购买 nike

我有一个带有多个 SMPP 绑定(bind)的 Kannel 网关(一个运算符(operator)需要单独的发送器和接收器绑定(bind),而另一个允许收发器绑定(bind))。收发器绑定(bind)不显示这个问题,所以我不会深入研究这些问题。

在单独的接收器/发送器绑定(bind)场景中,大多数(但不是全部)DLR 失败并显示“得到 DLR 但找不到消息或对它不感兴趣”,如下面的日志文件摘录所示:(已经完成了一些轻度匿名化)

2011-10-28 08:41:24 [6182] [9] DEBUG: SMPP[tx_bind]: Sending PDU:
2011-10-28 08:41:24 [6182] [9] DEBUG: SMPP PDU 0x12d76c0 dump:
2011-10-28 08:41:24 [6182] [9] DEBUG: type_name: submit_sm
2011-10-28 08:41:24 [6182] [9] DEBUG: command_id: 4 = 0x00000004
2011-10-28 08:41:24 [6182] [9] DEBUG: command_status: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: sequence_number: 108 = 0x0000006c
2011-10-28 08:41:24 [6182] [9] DEBUG: service_type: "SHORT_CODE_REMOVED"
2011-10-28 08:41:24 [6182] [9] DEBUG: source_addr_ton: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: source_addr_npi: 1 = 0x00000001
2011-10-28 08:41:24 [6182] [9] DEBUG: source_addr: "SHORT_CODE_REMOVED"
2011-10-28 08:41:24 [6182] [9] DEBUG: dest_addr_ton: 1 = 0x00000001
2011-10-28 08:41:24 [6182] [9] DEBUG: dest_addr_npi: 1 = 0x00000001
2011-10-28 08:41:24 [6182] [9] DEBUG: destination_addr: "PHONE_NUMBER_REMOVED"
2011-10-28 08:41:24 [6182] [9] DEBUG: esm_class: 3 = 0x00000003
2011-10-28 08:41:24 [6182] [9] DEBUG: protocol_id: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: priority_flag: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: schedule_delivery_time: NULL
2011-10-28 08:41:24 [6182] [9] DEBUG: validity_period: NULL
2011-10-28 08:41:24 [6182] [9] DEBUG: registered_delivery: 1 = 0x00000001
2011-10-28 08:41:24 [6182] [9] DEBUG: replace_if_present_flag: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: data_coding: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: sm_default_msg_id: 0 = 0x00000000
2011-10-28 08:41:24 [6182] [9] DEBUG: sm_length: 9 = 0x00000009
2011-10-28 08:41:24 [6182] [9] DEBUG: short_message: "test test"
2011-10-28 08:41:24 [6182] [9] DEBUG: SMPP PDU dump ends.
2011-10-28 08:41:26 [6182] [19] DEBUG: Dumping 47 messages to store
2011-10-28 08:41:28 [6182] [9] DEBUG: SMPP[tx_bind]: Got PDU:
2011-10-28 08:41:28 [6182] [9] DEBUG: SMPP PDU 0x12a6590 dump:
2011-10-28 08:41:28 [6182] [9] DEBUG: type_name: submit_sm_resp
2011-10-28 08:41:28 [6182] [9] DEBUG: command_id: 2147483652 = 0x80000004
2011-10-28 08:41:28 [6182] [9] DEBUG: command_status: 0 = 0x00000000
2011-10-28 08:41:28 [6182] [9] DEBUG: sequence_number: 108 = 0x0000006c
2011-10-28 08:41:28 [6182] [9] DEBUG: message_id: "1673716701"
2011-10-28 08:41:28 [6182] [9] DEBUG: SMPP PDU dump ends.
2011-10-28 08:41:28 [6182] [9] DEBUG: DLR[mysql]: Adding DLR smsc=tx_bind, ts=1673716701, src=SHORT_CODE_REMOVED, dst=PHONE_NUMBER_REMOVED, mask=1, boxc=
2011-10-28 08:41:28 [6182] [9] DEBUG: sql: INSERT INTO dlr (smsc, ts, source, destination, service, url, mask, boxc, status) VALUES ('tx_bind', '1673716701', 'SHORT_CODE_REMOVED', 'PHONE_NUMBER_REMOVED', 'SHORT_CODE_REMOVED', 'DLR_CALLBACK_URL_REMOVED', '1', '', '0');
2011-10-28 08:41:30 [6182] [19] DEBUG: Dumping 46 messages to store
2011-10-28 08:41:30 [6182] [6] DEBUG: SMPP[saf_7777]: Sending enquire link:
2011-10-28 08:41:33 [6182] [16] DEBUG: Optional parameter tag (0x001e)
2011-10-28 08:41:33 [6182] [16] DEBUG: Optional parameter length read as 11
2011-10-28 08:41:33 [6182] [16] DEBUG: Optional parameter tag (0x0427)
2011-10-28 08:41:33 [6182] [16] DEBUG: Optional parameter length read as 1
2011-10-28 08:41:33 [6182] [16] DEBUG: Optional parameter tag (0x1501)
2011-10-28 08:41:33 [6182] [16] DEBUG: Optional parameter length read as 13
2011-10-28 08:41:33 [6182] [16] WARNING: SMPP: Unknown TLV(0x1501,0x000d,32353437323235303036303900) for PDU type (deliver_sm) received!
2011-10-28 08:41:33 [6182] [16] DEBUG: SMPP[saf_receiver]: Got PDU:
2011-10-28 08:41:33 [6182] [16] DEBUG: SMPP PDU 0x1275cc0 dump:
2011-10-28 08:41:33 [6182] [16] DEBUG: type_name: deliver_sm
2011-10-28 08:41:33 [6182] [16] DEBUG: command_id: 5 = 0x00000005
2011-10-28 08:41:33 [6182] [16] DEBUG: command_status: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: sequence_number: 49 = 0x00000031
2011-10-28 08:41:33 [6182] [16] DEBUG: service_type: "SHORT_CODE_REMOVED"
2011-10-28 08:41:33 [6182] [16] DEBUG: source_addr_ton: 1 = 0x00000001
2011-10-28 08:41:33 [6182] [16] DEBUG: source_addr_npi: 1 = 0x00000001
2011-10-28 08:41:33 [6182] [16] DEBUG: source_addr: "PHONE_NUMBER_REMOVED"
2011-10-28 08:41:33 [6182] [16] DEBUG: dest_addr_ton: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: dest_addr_npi: 1 = 0x00000001
2011-10-28 08:41:33 [6182] [16] DEBUG: destination_addr: "SHORT_CODE_REMOVED"
2011-10-28 08:41:33 [6182] [16] DEBUG: esm_class: 4 = 0x00000004
2011-10-28 08:41:33 [6182] [16] DEBUG: protocol_id: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: priority_flag: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: schedule_delivery_time: NULL
2011-10-28 08:41:33 [6182] [16] DEBUG: validity_period: NULL
2011-10-28 08:41:33 [6182] [16] DEBUG: registered_delivery: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: replace_if_present_flag: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: data_coding: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: sm_default_msg_id: 0 = 0x00000000
2011-10-28 08:41:33 [6182] [16] DEBUG: sm_length: 111 = 0x0000006f
2011-10-28 08:41:33 [6182] [16] DEBUG: short_message:
2011-10-28 08:41:33 [6182] [16] DEBUG: Octet string at 0x12e2da0:
2011-10-28 08:41:33 [6182] [16] DEBUG: len: 111
2011-10-28 08:41:33 [6182] [16] DEBUG: size: 112
2011-10-28 08:41:33 [6182] [16] DEBUG: immutable: 0
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 69 64 3a 31 36 37 33 37 31 36 37 30 31 20 73 75 id:1673716701 su
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 62 3a 30 30 31 20 64 6c 76 72 64 3a 30 30 31 20 b:001 dlvrd:001
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 73 75 62 6d 69 74 20 64 61 74 65 3a 31 31 31 30 submit date:1110
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 32 38 30 38 34 31 20 64 6f 6e 65 20 64 61 74 65 280841 done date
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 3a 31 31 31 30 32 38 30 38 34 31 20 73 74 61 74 :1110280841 stat
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 3a 44 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 :DELIVRD err:000
2011-10-28 08:41:33 [6182] [16] DEBUG: data: 20 74 65 78 74 3a 74 65 73 74 20 74 65 73 74 text:test test
2011-10-28 08:41:33 [6182] [16] DEBUG: Octet string dump ends.
2011-10-28 08:41:33 [6182] [16] DEBUG: message_state: 2 = 0x00000002
2011-10-28 08:41:33 [6182] [16] DEBUG: receipted_message_id: "1673716701"
2011-10-28 08:41:33 [6182] [16] DEBUG: SMPP PDU dump ends.
2011-10-28 08:41:33 [6182] [16] DEBUG: SMPP[rx_bind] handle_pdu, got DLR
2011-10-28 08:41:33 [6182] [16] DEBUG: DLR[mysql]: Looking for DLR smsc=tx_bind, ts=1673716701, dst=PHONE_NUMBER_REMOVED, type=1
2011-10-28 08:41:33 [6182] [16] DEBUG: sql: SELECT mask, service, url, source, destination, boxc FROM dlr WHERE smsc='rx_bind' AND ts='1673716701';
2011-10-28 08:41:33 [6182] [16] DEBUG: no rows found
2011-10-28 08:41:33 [6182] [16] WARNING: DLR[mysql]: DLR from SMSC<rx_bind> for DST<PHONE_NUMBER_REMOVED> not found.
2011-10-28 08:41:33 [6182] [16] ERROR: SMPP[rx_bind]: got DLR but could not find message or was not interested in it id<1673716701> dst<PHONE_NUMBER_REMOVED>, type<1>

各自的绑定(bind)是:
# The sender
group=smsc
smsc=smpp
smsc-id=tx_bind
allowed-smsc-id=tx_bind
preferred-smsc-id=SHORT_CODE_REMOVED
interface-version=34
host=SMSC_HOST_REMOVED
port=SMSC_PORT_REMOVED
system-id=SHORT_CODE_REMOVED
system-type=
service-type=SHORT_CODE_REMOVED
source-addr-ton=0
source-addr-npi=1
dest-addr-ton=1
dest-addr-npi=1
smsc-username=USERNAME_REMOVED
smsc-password=PASSWORD_REMOVED
log-level=0

# The receiver
group=smsc
smsc=smpp
smsc-id=rx_bind
interface-version=34
host=HOST_REMOVED
receive-port=PORT_REMOVED
system-type=
smsc-username=USERNAME_REMOVED
smsc-password=PASSWORD_REMOVED
log-level=0

我的背景研究提出了这些邮件列表消息:
- http://www.kannel.org/pipermail/users/2011-July/016183.html
- http://old.nabble.com/Responsibility-for-inversion-of-source-and-destination-address-for-DLR-td32165725.html

似乎 Kannel 在 submit_sm 之后立即保存 DLR,并将 smsc_id 设置为 tx_bind [发件人的 SMSC id]。然后,当收到此操作符的deliver_sm [,它通常会通过rx_bind [接收器绑定(bind)] 进来,它会尝试使用该smsc_id 来查找它。

有谁知道这个的解决方法?

最佳答案

正如我从日志和配置文件中看到的,您使用不同的 短信发射器和接收器连接部分。

因此,当 Kannel 尝试查找原始消息时,它使用 短信消息 ID 参数。在你的情况下短信 上会有不同的值提交_sm 交付_sm 加工。

要解决它,只需设置单个 短信组:

  • 两个端口 接收端口 里面
  • 收发器模式 = 0 参数(平均发射器/接收器模式)

  • 注意:此端口可能相同,并且在 SMSC 上通常相同。

    示例(配置的一部分):
    group=smsc
    smsc=smpp
    smsc-id=rx_tx_bind
    interface-version=34
    transceiver-mode = 0
    host=smsc.host.was.here
    port=TX_PORT
    receive-port=RX_PORT
    # other parameters here

    关于sms - 在存在单独的接收器和收发器绑定(bind)的情况下,Kannel 中的 DLR 路由失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7937676/

    29 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com