验证SMPP连接 validate-smpp-connection
以下是一些检查，以确保您的SMPP连接正常。
上线前需要检查的事项 check-go-live
在上线之前，请使用以下检查列表确保SMPP设置正常。
检查外部帐户冲突 sms-external-accounts-check
检查您是否没有剩余的短信外部帐户。 删除测试帐户以消除潜在冲突。
检查是否有其他实例连接到外部帐户。 特别是，请确保预生产环境未连接到prod外部帐户。
如果您需要在同一Campaign实例上具有多个连接到同一提供商的帐户，请联系提供商以确保他们实际区分这些帐户之间的连接。 使用同一登录名拥有多个帐户需要额外的配置。
检查所有启用的短信外部帐户是否启用了专用进程设置。 您不能在同一实例上混用2种帐户（具有和不具有专用流程）。
进行实际测试 real-test
尝试在不同手机上发送一些短信。
发送包含各种字符的短信
如果您需要发送非GSM或非ASCII字符的短信，请尝试发送尽可能多种字符的消息。 如果设置自定义字符映射表，请为所有可能的data_coding值至少发送一个SMS。
检查SR是否正确处理
在投放日志中，短信应标记为已接收。 投放日志应该成功，并且应如下所示：“SR yourProvider stat=DELIVRD err=000|#MESSAGE#”。
检查是否正确设置了“SMSC实施名称”字段：在生产环境中，投放日志不得包含“SR Generic”。
检查是否已处理MO
为所有自动回复关键字发送几条短信，并检查回复是否快速（不超过几秒）。
检查MO是否已插入 nms：inSms 数据库。 如果您有自定义TLV，请确保它们也正确插入且格式正确。
在日志中检查Campaign是否成功回复了DELIVER_SM_RESP (command_status=0)。
执行负载测试
如果您发送大量消息或者如果您使用实时消息传送，这一点尤其重要。
执行至少在5秒内以100%加载连接的测试。 如果提供商无法连接到虚假帐户以进行测试，您将必须发送真实消息。 实现该目标的一种方式是，密切监控第一个足够大的投放，并启用详细的SMPP消息。
可以按如下方式计算要发送的最小消息数：
最大MT吞吐量发射器/收发器连接总数* 5*
投放完成后，请检查以下事项：
- 检查是否发送了所有消息（不一定接收）
- 命令状态不是0x00000000的PDU必须是绝对零的，除非提供程序明确指出这是正常操作
- 在整个传送过程中，连接必须保持绝对稳定（无BIND PDU）。
- 检查所有消息是否都具有SR并且它是否被正确处理（请参阅检查SR是否被正确处理）。 如果一小部分存在错误，请检查这些是否是实际的SR返回错误，而不是在Campaign端发送或处理期间返回错误。
- 如果您不确定性能，请检查延迟是否合理，尤其是在PDU与其对应的RESP之间，超过500毫秒的延迟可能是高吞吐量的问题。 使用该延迟检查发送窗口公式（有关更多详细信息，请参阅发送窗口设置）
检查PDU pdu
检查PDU的格式是否正确。
绑定
检查BIND_* PDU是否正确发送。 要检查的最重要事项是，提供程序始终返回成功的BIND_*_RESP PDU (command_status = 0)。
检查BIND_* PDU是否不多。 如果数量过多，则可能表示连接不稳定。 有关详细信息，请参阅下面的连接不稳定问题故障排除部分。
查询链接
检查连接空闲时是否定期交换INQUIRE_LINK PDU。
SUBMIT_SM / DELIVER_SM
发送消息，然后在日志中搜索其对应的SUBMIT_SM、SUBMIT_SM_RESP、DELIVER_SM和DELIVER_SM_RESP PDU。
使用SUBMIT_SM PDU：
- 检查data_coding是否正确（缺省为0）。
- 检查short_message是否正确编码：尝试使用支持多种编码的十六进制转换器对其进行解码（在线上有一些可用）。
- 如果将message_payload用于长消息，请检查该内容是否显示在可选字段中，而不是在short_message字段中。
使用SUBMIT_SM_RESP PDU：
- 检查是否成功(command_status = 0)。
- 检查其正文是否包含格式正确的ID，后跟“0”字节。
使用DELIVER_SM PDU：
- 对十六进制short_message字段进行解码（有相应的联机工具）。
- 使用正则表达式检查工具检查SR中ID的提取正则表达式中定义的正则表达式是否只返回一个捕获组，以及它是否捕获消息中的整个ID。
- 检查提取的ID是否与SUBMIT_SM_RESP中的ID匹配。
- 检查SR中状态的提取正则表达式中定义的正则表达式是否返回stat字段的内容。
- 检查SR中错误的提取正则表达式中定义的正则表达式是否返回错误字段的内容。
使用DELIVER_SM_RESP PDU：
- 检查在收到DELIVER_SM PDU（通常少于1秒）后是否快速发送了该数据包。
- 检查是否成功(command_status = 0)。
与提供商进行实时测试 sms-live-test
上线之前的最佳做法是与提供商进行实时测试，双方在执行期间查看日志。
禁用详细的SMPP跟踪 sms-disable-smpp
完成所有检查后，最后要执行的操作是禁用详细的SMPP跟踪，以便不会生成过多日志。
短信疑难解答 sms-troubleshooting
一般故障诊断过程 sms-general-troubleshooting
SMS连接器涉及3个实体：SMPP提供商、Adobe和您。
主要的SMS专家是SMPP提供商，因此他们应该参与解决所有SMS流量相关问题（连接问题、消息丢失、编码问题、国家/地区特定的规则……）。
启用专用进程 sms-dedicated-process
如果您遇到旧（基于MTA）的连接器问题（专用进程已禁用），应考虑迁移到专用进程连接器。 它表现更好，更稳定，并在日志中提供更好的反馈。
不同外部帐户之间的冲突 sms-conflict-external-accounts
如果实例具有多个SMS外部帐户，请检查问题是否不是由帐户之间的冲突引起的。
隔离外部帐户导致问题：
- 禁用所有外部帐户
- 启用一个外部帐户
- 尝试重现问题
- 如果该单个帐户未出现问题，请禁用该帐户，然后在下一个帐户上重新启动到步骤2。 分别检查每个帐户后，可能会出现以下两种情况：
问题出现在一个或多个帐户上
在这种情况下，您可以对每个帐户单独应用其他故障排除过程。 最好在诊断帐户时禁用其他帐户，以减少网络流量和日志量。
在任何时候只有一个帐户处于活动状态时，问题未出现
帐户之间存在冲突。 Adobe Campaign会单独处理帐户，但提供商可能会将它们视为单个帐户。
您在所有帐户之间使用不同的登录/密码组合
您将必须联系提供程序以诊断其一方的潜在冲突。
某些外部帐户共享相同的登录/密码组合
提供商无法辨别BIND PDU来自哪个外部帐户，因此他们将来自多个帐户的所有连接都视为一个连接，因此它们可能会在2个帐户上随机路由MO和SR，从而导致看似随机的问题。
如果提供程序支持同一登录/密码组合使用多个短代码，则必须询问他们将短代码放在BIND PDU中的什么位置。 请注意，此信息必须放在BIND PDU中，而不是SUBMIT_SM中，因为BIND PDU是唯一允许正确路由MO的位置。
请参阅上面各种PDU 部分中的信息，了解BIND PDU中哪些字段可用，通常您会将短代码放在 address_range 中，但这需要提供者的特殊支持。 联系他们，了解他们希望如何独立路由多个短代码。
Adobe Campaign支持在同一外部帐户上处理多个短代码，因此通常只需一个帐户处理所有流量即可正常使用。
外部帐户已停止工作 sms-external-account-not-working
通常，SMPP连接随着时间的推移往往非常稳定，一旦正确配置，它们应该继续工作。
- 调查连接器最近是否发生了更改 — 以及更改者（检查外部帐户作为组）。
- 调查系统是否已升级以及何时升级。
- 调查影响短信的任何包最近是否升级过。
如果这些检查都没有导致根本原因，请与提供商联系。 有时，当提供商更新其平台时，其连接器的行为会略有不同。 这可能会破坏经过微调的设置并引入回归。
建议与提供商保持联系，提供商通常会提前传达重大更改。
中间源问题（托管） sms-issue-hosted
- 如果问题发生在中间源环境中，请确保在中间源服务器上正确创建和更新投放和broadlog。 如果不是这种情况，则问题不是短信问题。
- 请确保mid运算符名称严格为小写，否则投放将保持待处理状态。
- 如果所有功能在中间服务器上都有效，并且短信发送正确，但营销实例未正确更新，则表明您存在中间同步问题。
连接到提供商时出现问题 sms-issue-connection
- 如果BIND PDU返回非零 command_status 代码（表示存在错误），或者如果没有BIND_RESP PDU，请询问提供程序为何发生这种情况。
- 检查网络是否已正确配置，以便能够与提供商建立TCP连接。
- 要求提供商检查他们是否正确允许了Adobe Campaign实例的IP地址（大多数提供商都需要此项）。
- 检查外部帐户设置。 如果对某些字段的值存在疑问，请咨询提供商。
- 如果连接成功但不稳定，请检查连接不稳定的问题。 部分。
- 如果连接问题难以诊断，则网络捕获将为您带来大量信息。 确保网络捕获在问题出现时同时运行，以便能够有效地进行分析。 您还应注意问题出现的确切时间，以便更容易在网络捕获中查找问题。
连接不稳定的问题 unstable-connections
如何诊断不稳定的连接：
如果出现以下任何一种情况，则认为连接不稳定：
- 连接持续不到1小时。
- 重新启动短信流程将暂时“修复”问题。 这可能意味着不稳定的连接会触发限制，重新启动短信进程会清除限制，然后会再次发生，直到找到根本原因为止。
- 提供程序发送UNBIND PDU。 在正常操作中，提供程序绝不应该发送UNBIND PDU。
- inquire_link在Campaign端或提供商端超时。 在这种情况下，您可能会看到INQUIRE_LINK_RESP，也可能不会看到带有非零错误代码。
- 有许多BIND PDU。 一天不应超过几个（具体取决于连接数）。 每小时和每个连接应发出超过1个BIND PDU警报。
如何修复连接稳定性问题：
- 不稳定的连接很少是根本原因，它通常是另一个问题以某种方式触发断开的结果。 首先要找出根本原因。
- 启用详细的SMPP跟踪。 您需要他们查看连接重新启动时发生的操作。
- 如果提供程序发送UNBIND PDU，则它们可能会执行错误。 询问他们发送UNBIND的原因，这可能会导致根本原因。
- 进行网络捕获有时是查看连接如何关闭的唯一方法。
- 如果提供商关闭连接（通过发送TCP FIN或TCP RST数据包），请询问他们这样做的原因。 这应该会告诉您问题的根本原因。
- 如果提供程序在发送干净错误（例如带有错误代码的DELIVER_SM_RESP）后关闭连接，则必须修复其连接器，因为这样可防止传输其他类型的消息，并触发MTA限制。 在收发器模式下，这一点尤其重要，因为关闭连接会同时影响MT和SR。
- 如果存在超时（BIND超时、SUBMIT_SM超时），则Campaign可能为该提供商发送消息的速度过快。 请尝试降低 最大MT吞吐量 设置，看看它是否解决了此问题。
发送MT（发送给最终用户的常规短信）时出现问题
- 检查连接是否稳定：SMPP连接应持续保持至少1小时。 请参阅上面的“连接不稳定问题”部分。
- 如果重新启动短信过程使发送MT在短时间内再次工作，则可能由于连接不稳定而遇到限制。 请参阅上面的“连接不稳定问题”部分。
- 检查广泛日志是否存在并且状态正确，日期正确。 如果不是，则不是短信问题，而是投放问题或投放准备问题（不属于本文档的范围）。
- 检查SMS连接器是否实际与提供商的设备绑定。 请向提供商征求反馈，以确保所有系统都可正常通信。 有关绑定过程的信息，请参见BIND_TRANSMITTER和BIND_TRANSCEIVER PDU。 您可能需要启用SMPP跟踪才能正确进行故障排除。
- 启用SMPP跟踪后，检查SUBMIT_SM PDU是否包含正确的信息（请参阅上面的文档）。
- 检查提供程序是否使用“OK”值（代码0）通过SUBMIT_SM_RESP PDU进行响应。 确保PDU以合理的延迟到达：超过1秒的任何时间都是可疑的，必须与提供商讨论，通常在100毫秒内到达。
- 如果所有这些步骤都有效，您可以确信问题出在提供商方面。 他们必须在平台上执行故障排除。
- 如果它可以工作，但吞吐量不一致，请尝试调整发送窗口并降低MT吞吐量。 您需要与提供商合作才能调整此设置。 Campaign可以快速发送消息，因此提供商的设备可能会出现性能问题。
MT重复（同一短信连续多次发送）
重复项通常由重试引起。 重试邮件时会出现重复项是正常的，因此您应该集中精力消除重试的根源。
- 如果您看到重复项发送时间刚好相隔60秒（或其他任何可疑的“正常”时段），则可能是提供商遇到的问题，他们发送SUBMIT_SM_RESP的速度不够快。
- 如果看到多个BIND/UNBIND，则表示连接不稳定：在尝试解决重复消息问题之前，请参阅连接不稳定问题部分以获取解决方案。
- 检查所有SUBMIT_SM PDU之后是否具有匹配的SUBMIT_SM_RESP。 如果它们不执行或SUBMIT_SM_RESP速度太慢，则问题出在提供商方面。
减少重试时的重复项数量：
- 降低发送窗口。 发送窗口应足够大，以覆盖SUBMIT_SM_RESP延迟，但不能太大。 其值表示在窗口已满时发生错误时可复制的最大消息数。
处理SR（交货收货）时发货
- 您需要启用SMPP跟踪才能进行任何类型的SR故障排除。
- 检查DELIVER_SM PDU是否来自提供商以及它的格式是否正确。
- 检查Campaign是否及时回复成功的DELIVER_SM_RESP PDU。 这可保证SR已插入providerMsgStatus表中，以便SMS进程延迟处理。
如果DELIVER_SM PDU未成功确认，则需要检查以下事项：
- 检查与外部帐户中ID提取和错误处理相关的正则表达式。 您可能需要根据DELIVER_SM PDU的内容来验证它们。
- 检查是否在broadLogMsg表中正确设置了错误（Campaign文档对此进行了详细说明）。
如果ACC扩展SMPP连接器已确认DELIVER_SM PDU，但broadLog未正确更新，请检查上面“匹配MT、SR和broadlog条目”部分中描述的ID协调过程。
如果您修复了所有问题，但某些无效SR仍在提供程序的缓冲区中，则可以使用“无效ID确认计数”选项跳过它们。 应谨慎使用此项，并在清除缓冲区后尽快将其重置为0。
如果SR处理缓慢，请尝试在BroadLogMsg表中限定最常见的状态消息。
如果只接收了一些SR，但并未接收全部，请检查是否有其他系统连接到提供商的帐户，如测试系统。 SR可以在任何连接上路由，因此其中一些可以路由到另一个系统。 提供商可能会帮助您查找连接到帐户的另一个系统的位置。
处理MO（和隔离/自动回复）时出现问题
- 在测试期间启用SMPP跟踪。 如果不启用TLS，在MO故障排除时最好进行网络捕获，以检查PDU是否包含正确的信息以及格式是否正确。
- 在捕获网络流量或分析SMPP跟踪时，请确保捕获与MO及其回复MT的整个对话（如果已配置回复）。
- 如果MO (DELIVER_SM PDU)未出现在跟踪中，您可以确信问题出在提供商方面。 他们必须在平台上执行故障排除。
- 如果出现DELIVER_SM PDU，请检查Campaign是否通过成功的DELIVER_SM_RESP PDU（代码0）确认它。 此RESP可保证所有处理逻辑均已由Campaign应用（自动回复和隔离）。 如果不是这种情况，请在短信进程日志中搜索错误消息。
- 如果启用了自动回复，请检查SUBMIT_SM是否已发送给提供商。 如果没有，则保证在短信进程日志中找到错误消息。
- 如果在跟踪中找到包含回复的SUBMIT_SM MT PDU，但手机未收到短信，则您必须联系提供商以获得故障排除方面的帮助，因为问题可能就在他们这边。
投放准备期间出现的问题未排除被隔离的收件人（被自动回复功能隔离）
- 检查隔离表和投放日志中的电话号码格式是否完全相同。 如果不适用，如果您遇到国际电话号码格式的加号前缀问题，请参阅上面的“发送完整电话号码”设置。
- 检查短代码：如果收件人的短代码与外部帐户中定义的短代码相同或为空（空=任何短代码），则会发生排除。 如果整个Campaign实例只使用一个短代码，则更容易将所有“短代码”字段留空。
编码问题 sms-encoding-issues
短信中经常出现编码问题。 以下是一些基本步骤。
步骤1：联系提供程序
提供商是了解短信工作原理的专家。 联系他们，看看哪里不对劲。 他们应该能够告诉您问题是属于他们的一方还是属于Campaign。 如果问题出在Campaign中，则他们应该能够准确地告知您哪个字段不正确，这非常有用。
步骤2：了解消息内容
你必须知道你所传达的讯息是什么。 这句话听起来可能很容易，但事实并非如此。 Unicode允许使用如此多的变体来表示相似字符，以至Campaign无法处理所有这些字符。
最常见的问题来自文字处理程序的复制粘贴，它将常用字符更改为正确排版版本：空格更改为不换行空格，双引号更改为开引号和闭引号，减号更改为各种连字符……
测试时不复制粘贴消息，始终在界面中直接键入消息。
不要被十六进制威胁。 十六进制看起来奇怪又不自然，但它有一个非常独特的性质：你可以分辨出相似字符之间的差异。 小写L、大写I、O、0，所有不同类型的引号、非拉丁语编码甚至不同类型的空格可能看起来都相同（甚至根本不会显示）。 十六进制显示所有内容，并有助于比较各种内容。
要将unicode转换为十六进制，您可以使用在线工具。
在打开有关编码问题的票证时，无论是在提供程序中还是在Campaign支持中，都包含您所键入内容和所看到内容的十六进制版本。
步骤3：了解应发送哪些内容
确定要使用的编码，并联机搜索其字符表。 检查您打算发送的字符是否确实在目标代码页中可用。 请检查data_coding字段是否正确，它是否与您和提供商期望的内容相匹配。
步骤4：了解您实际发送的内容
您需要连接器的调试输出，才能准确地查看您发送到提供程序的字节。 SUBMIT_SM PDU中出现编码问题，因此请务必捕获它们。 发送非常不同的消息，这些消息在日志中很容易找到。
测试时，请务必发送各种特殊字符。 例如，GSM7编码具有扩展字符，这些字符以十六进制形式非常不同，因此很容易被发现，因为它们未出现在任何其他编码中。
性能问题 sms-performance-issues
发送MT时出现性能问题
- 检查外部帐户的“吞吐量和延迟”部分中的所有设置是否正确，以及它们是否与提供商允许的设置相匹配。
- 检查是否不重试。
- 检查提供商的基础设施是否未饱和。 检查RESP PDU中是否存在RMSGQFUL或RTHROTTLED错误。
- 检查serverConf设置。 从默认值开始，缓慢逐个增加参数。
- 检查短信进程是否在加载时不会一直重新启动。 如果超过此值，您可能需要在serverConf文件中增加maxSMSMemoryMb、maxProcessMemoryAlertMb和maxProcessMemoryWarningMb。
接收SR时出现性能问题
如果提供商抱怨其缓冲区过载，这可能是因为Campaign接收SR的速度不够快。
- 检查实例数据库是否未过载。 SR处理非常依赖于数据库性能。
- 要求提供商增加其一侧DELIVER_SM的发送窗口。 理想情况下，它应该与serverConf中的 batchUpdateSize 设置一样大。
通信短信问题时要包含的元素
每当您寻求有关短信问题的帮助(无论是向Adobe Campaign打开支持票证，还是向短信提供商，或任何有关该问题的通信)时，您都需要至少包含以下信息以确保其符合条件。 适当的合格问题对于更快地解决问题至关重要，因此花更多的时间来尝试了解情况并提供有意义的信息将带来效率的巨大飞跃。
- 在问题出现期间启用详细的SMPP消息。 如果没有它，大多数短信问题几乎无法解决。
- 如果问题与短信流量相关，请首先与提供商联系。 他们知识最丰富，其平台通常适用于实时高效诊断短信流量问题。
- 包括对问题的简短但实事求是的描述。
- 包括预期结果的描述。
- 包括提供商的所有反馈。
- 包括相关日志和/或网络捕获。 执行捕获时，请确保在捕获期间重现问题，否则它将毫无用处。
- 如果您包括日志、跟踪或捕获，则会在问题出现时精确指出文件中确切的位置，以及工作示例的确切位置（如果有）。 捕获或跟踪可能会非常庞大，而且冗长，因此任何有助于在其中查找信息的内容都很有用。
- 如果您引用消息、PDU或日志，请清楚地声明其时间戳，以便其他人轻松查找。
- 尝试在测试环境中重现问题。 如果不确定设置，请在测试环境中尝试此设置，并使用SMPP跟踪检查结果。 报告在测试环境中复制的问题通常比直接报告生产环境中的问题要好。
- 包括平台上的任何更改或调整：即使是微小更改也会产生巨大影响。 此外，还包括提供商可能对他们所做的任何更改。
网络捕获何时有用？
网络捕获并不总是需要的。 通常，冗长的SMPP消息就足够了。 下面是一些准则，可帮助您确定网络捕获是否值得：
- 连接有问题，但详细消息未显示任何BIND_RESP PDU。
- 无法解释的断开连接没有错误信息（即连接器检测到低级协议错误时的行为）。
- 提供程序抱怨解除绑定/断开连接过程。
- 可选TLV字段中存在编码问题。
- 怀疑不同连接之间混合了流量。
在所有其他情况下，尝试先分析详细的SMPP消息，并且仅在详细日志中明确缺少信息时才请求网络捕获。
网络捕获何时毫无用处？
在某些情况下，捕获网络流量是无用的，或者只是浪费时间。 以下是最常见的情况：
- TLS已启用：根据定义，TLS流量会被加密，因此无法捕获该流量。
- 性能问题：日志包含跟踪性能问题所需的所有信息。
- 计时问题（重试计时、enquire_link时段、吞吐量上限……）
- SR解析和处理：详细日志可提供更多的上下文和更好的呈现。
- MO处理（自动回复、隔离）。
- 不涉及实际SMPP流量的错误：投放准备、消息中心API问题、工作流问题……