C.2 SMS 通道操作原理

SMS 通道是一种多线程通道，它将已排队的电子邮件消息转换成 SMS 消息，然后将其提交以传送至 SMSC。

本节包含以下通道操作主题：

• C.2.1 将电子邮件定向到通道

• C.2.2 电子邮件到 SMS 的转换过程

• C.2.3 SMS 消息提交过程

• C.2.4 站点定义的地址有效性检查和转换

• C.2.5 站点定义的文本转换

C.2.1 将电子邮件定向到通道

按照C.3 SMS 通道配置配置 SMS 通道时，一个或多个主机名将与该通道关联。为便于讨论，我们假定主机名 sms.siroe.com 就是一个与该通道相关联的主机名。在这种情况下，将用以下形式的地址将电子邮件定向到通道：

local-part@sms.siroe.com

其中 local-part 可以是 SMS 目标地址（例如，无线电话号码、寻呼机 ID 等），也可以是以下格式的属性-值对列表：

/attribute1=value1/attribute2=value2/.../@sms.siroe.com

表 C–1 提供了可识别的属性名称及其用法。这些属性允许按收件人控制某些通道选项。

下面是一些地址示例：

123456@sms.siroe.com
/id=123456/@sms.siroe.com
/id=123456/maxlen=100/@sms.siroe.com
/id=123456/maxpages=1/@sms.siroe.com

有关在电子邮件地址的 SMS 目标地址部分中执行转换、有效性检查和其他操作的信息，请参见C.2.4 站点定义的地址有效性检查和转换。

C.2.2 电子邮件到 SMS 的转换过程

为了将电子邮件发送到远程站点，必须将电子邮件转换成能被远程 SMSC 所理解的 SMS 消息。本节说明将 SMS 通道中排队的电子邮件消息转换成一个或多个 SMS 消息的过程。如下文所述，选项可以控制生成的 SMS 消息的最大数目、这些 SMS 消息的最大总长度和任意一条 SMS 消息的最大大小。只有电子邮件消息的文本部分（即，MIME 文本内容类型）会被使用，并且还可以控制已转换部分的最大数目。

电子邮件消息的标题行和文本部分中所使用的字符集均将被转换成 Unicode，然后再转换成相应的 SMS 字符集。

如果没有 SMS_TEXT 映射表（请参见C.2.5 站点定义的文本转换），已排入 SMS 通道的电子邮件消息将按图 C–2 中的说明进行处理。

图 C–2 SMS 通道的电子邮件处理

图 C–3 SMS 通道电子邮件处理（续）

以下步骤与图 C–2 中的编号框相对应：

1. 启动一个空输出缓冲区。该缓冲区所使用的字符集是统一字符编码。

2. 电子邮件消息的创始者地址来自以下五个源之一，这些源按首选项的降序显示：

   1. Resent-from: 2. From: 3. Resent-sender: 4. Sender: 5. Envelope From:

   如果创始者地址是空字符串，FROM_NONE 通道选项的值将会附加到缓冲区。

   但是，如果创始者地址是一个非空字符串，则 FROM_FORMAT 通道选项的处理结果和 LINE_STOP 通道选项的值均会附加到输出缓冲区。

   请注意，只有 USE_HEADER_RESENT 选项值为 1 时，才考虑 Resent-from: 和 Resent-sender: 标题行。否则，将忽略 Resent- 标题行。

3. 如果 Subject: 标题行不存在或为空，则 SUBJECT_NONE 选项的值会附加到输出缓冲区。

   否则，SUBJECT_FORMAT 选项的处理结果和 LINE_STOP 通道选项的值均会附加到输出缓冲区。

4. 如果没有文本消息部分，则 NO_MESSAGE 通道选项的值会附加到输出缓冲区。

   若有文本消息部分，则 CONTENT_PREFIX 通道选项的值就会附加到输出缓冲区。

   非文本消息部分则被放弃。

5. 对于每个文本部分，如果未达到 MAX_MESSAGE_PARTS 限制，则该文本部分就会被解码为 Unicode，并连同 LINE_STOP 通道选项的值一起附加到缓冲区。

6. 然后，输出缓冲区的结果将从 Unicode 转换成 SMSC 的默认字符集或 UCS2 (UTF-16)。SMSC 的默认字符集是通过 SMSC_DEFAULT_CHARSET 选项来指定的。

7. 转换完毕后，所得到的结果将被截断，以使之不超过 MAX_MESSAGE_SIZE 中设置的字节数。

8. 然后，在C.2.2 电子邮件到 SMS 的转换过程中转换而得到的字符串将被分割成一条或多条 SMS 消息，其中任何一条 SMS 消息都不会长于 MAX_PAGE_SIZE 中设置的字节数。最多将生成数量与 MAX_PAGES_PER_MESSAGE 中所设置数量相同的 SMS 消息。

   ---

   注 –

   由于一条电子邮件消息可能会有多个收件人，因此，可能需要对每个收件人地址都执行步骤 6 至步骤 8，这样将可以使用第 4 页的“将电子邮件定向到通道”中所述的 MAXLEN、MAXPAGES 或 PAGELEN 属性。

   ---

C.2.2.1 电子邮件消息处理样例

例如，使用通道的默认设置的电子邮件消息：

From: John Doe 
To: 1234567@sms.siroe.com
Subject: Today’s meeting
Date: Fri, 26 March 2001 08:17

The staff meeting is at 14:30 today in the big conference room.

将转换成 SMS 消息：

jdoe@siroe.com (Today’s meeting) The staff meeting is at 14:30 today in the big conference room.

如下所示的另一组选项设置：

CONTENT_PREFIX=Msg:
FROM_FORMAT=From:${pa}
SUBJECT_FORMAT=Subj:$s

将会生成以下 SMS 消息：

From:John Doe Subj:Today’s meeting Msg:The staff meeting is at 14:30 today in the big conference room.

C.2.3 SMS 消息提交过程

电子邮件消息转换成一条或多条 SMS 消息（可能每个收件人的设置不同）后，SMS 消息将被提交到目标 SMSC。提交过程是使用基于 TCP/IP 的 SMPP V3.4 完成的。SMPP 服务器的主机名 (SMPP_SERVER) 将用作与 SMS 通道相关联的正式主机名；要使用的 TCP 端口 (SMPP_PORT) 将通过 port 通道关键字来指定。

当有消息需要处理时，通道就会被启动。该通道将作为发送器绑定至 SMPP 服务器，并递交使用 ESME_ 通道选项（如C.3.3.4 SMPP 选项中所述）指定的证书。表 C–2 列出了 BIND_TRANSMITTER PDU（Protocol Data Unit，协议数据单元）中的字段集，并给出了它们的值：

请注意通道是多线程的。通道可以运行多个出队列线程，具体取决于要发送邮件的数量。（甚至可能会运行多个通道进程。）每个线程执行一次 BIND_TRANSMITTER，然后在该 TCP/IP 连接上发送所有必须发送的 SMS 消息，随后发送 UNBIND，最后关闭连接。系统不会为了将来可能会重新使用某个连接而将其以开放状态闲置一段时间。如果远程 SMPP 服务器发送回一个限制错误，则会发出 UNBIND，而 TCP/IP 连接将被关闭并建立一个新的连接和 BIND。如果远程 SMPP 服务器在完成其 SMS 消息发送之前发送了 UNBIND，也会发生类似情况。

然后，SMS 消息使用 SMPP SUBMIT_SM PDU 进行提交。如果返回一个永久性错误（例如 ESME_RINVDSTADR），则电子邮件消息将会作为不可传送的消息返回。如果返回一个临时性错误，电子邮件消息就会重新入队，以尝试以后传送。要说明的是，对于永久性错误，条件可能永远不存在而重复尝试传送也不会有实际结果，例如无效的 SMS 目标地址。而对于临时性错误，条件在近期可能不存在，如服务器关闭或服务器拥塞的情况。

如果 USE_HEADER_FROM 选项的值为 1，则将为提交的 SMS 消息设置源地址。所使用的值将从始发电子邮件消息中导出，并选定为所有回复最有可能被定向到的（电子邮件）地址。相应地，源地址从以下七种来源（按首选项降序显示）之一中选出：

1. Resent-reply-to:
2. Resent-from:
3. Reply-to:
4. From:
5. Resent-sender:
6. Sender:
7. Envelope From:

请注意，仅当 USE_HEADER_REPLY_TO 选项的值为 1 时，才考虑 Resent-reply-to: 和 Reply-to: 标题行。而且，仅当 USE_HEADER_RESENT 选项的值为 1 时，才考虑 Resent-reply-to:、Resent-from: 和 Resent-sender: 标题行。（请注意，这就意味着只有这两个选项的值必须都为 1 时，才考虑 Resent-reply-to: 标题行。）这两个选项的默认值均为值 0。因此，默认配置仅考虑第 4、第 6 和第 7 项。最后，由于 SMS 消息中的源地址被限制为 20 个字节，所以如果选定的源地址超过该限制，该地址就会被截断。

表 C–3 列出了 SUBMIT_SM PDU 中的强制性字段集：

表 C–4 显示了 SUBMIT_SM PDU 中的可选字段：

通道将保持与 SMPP 服务器的联结，直至它再没有要提交的 SMS 消息（消息队列为空）或者已超过 MAX_PAGES_PER_BIND 为止。在后一种情况下，如果仍有需要发送的 SMS 消息，就会建立新的连接并绑定已执行的操作。

请注意，SMS 通道是多线程的。通道中的每个处理线程均保持自身与 SMPP 服务器的 TCP 连接。例如，如果有三个处理线程都有要提交的 SMS 消息，则通道与 SMPP 服务器就有三个开放的 TCP 连接。每个连接均将作为发送器绑定到 SMPP 服务器。而且，任何给定的处理线程一次只能有一个等待提交的 SMS。即，一个给定的线程将提交一条 SMS 消息，然后在提交另一条 SMS 消息之前，先等待提交响应（即 SUBMIT_SM_RESP PDU）。

C.2.4 站点定义的地址有效性检查和转换

站点可能想要将有效性检查和转换应用于收件人电子邮件地址（如C.2.1 将电子邮件定向到通道中所述）中已编码的 SMS 目标地址。

• 去除非数字字符（例如，将 800.555.1212 转换成 8005551212）

• 添加前缀（例如，将 8005551212 转换成 +18005551212）

• 验证正确性（例如，123 为太短）

前两项任务可专门使用 DESTINATION_ADDRESS_NUMERIC 和 DESTINATION_ADDRESS_PREFIX 通道选项来完成。一般情况下，所有这三项任务和其他任务都可使用映射表实现：使用重写规则中的映射表调用，或者使用 FORWARD 映射表。使用重写规则中的映射表调用具有很强的灵活性，包括能够拒绝带有站点定义的错误响应的地址。本节其余部分将只集中介绍这种方法 - 使用重写规则中的映射表调用的方法。

假设目标地址必须仅为数字格式，长度为 10 或 11 位且以字符串 "+1" 为前缀。则其可使用以下重写规则实现

sms.siroe.com      ${X-REWRITE-SMS-ADDRESS,$U}@sms.siroe.com
sms.siroe.com       $?Invalid SMS address

上述第一条重写规则将调用名为 X-REWRITE-SMS-ADDRESS 的站点定义的映射表。该映射表传递电子邮件地址的本地部分，以便进行检查。如果映射进程确定本地部分可接受，则该地址将被接收并重写到 SMS 通道中。如果映射进程不接受本地部分，将应用下一条重写规则。由于是一条 $? 重写规则，所以该地址将被拒绝，并发送错误文本“无效的 SMS 地址”。

X-REWRITE-SMS-ADDRESS 映射表如下所示：它以属性-值对列表格式或仅按原始 SMS 目标地址执行必要的本地部分验证步骤。

X-VALIDATE-SMS-ADDRESS

! Iteratively strip any non-numeric characters 
   $_*$[$ -/:-~]%*  $0$2$R
! Accept the address if it is of the form 1nnnnnnnnnn or nnnnnnnnnn
! In accepting it, ensure that we output +1nnnnnnnnnn
   1%%%%%%%%%%      +1$0$1$2$3$4$5$6$7$8$9$Y
   %%%%%%%%%%       +1$0$1$2$3$4$5$6$7$8$9$Y
! We didn’t accept it and consequently it’s invalid
   *                $N

X-REWRITE-SMS-ADDRESS
    */id=$_*/*       $C$0/id=$|X-VALIDATE-SMS-ADDRESS;$1|/$2$Y$E
    */id=$_*/*       $N
    *                $C$|X-VALIDATE-SMS-ADDRESS;$0|$Y$E
    *                $N

如果使用上述设置，请确保 DESTINATION_ADDRESS_NUMERIC 选项的值为 0（默认值）。否则，"+" 将从 SMS 目标地址中删除。

C.2.5 站点定义的文本转换

站点可以使用转换规则表自定义C.2.2 电子邮件到 SMS 的转换过程中所述的步骤 1 至 6。这些规则通过 MTA 映射文件中的映射表来指定。

映射表的名称应为 SMS_Channel_TEXT，其中 SMS_Channel 为 SMS 通道的名称；例如，如果通道名为 sms，则映射表名为 SMS_TEXT，如果通道名为 sms_mway，则映射表名为 SMS_MWAY_TEXT。

该映射表中可包含两种类型的条目。然而，在解释这些条目的格式之前，请务必清楚地了解如何使用映射表，以便了解如何构造和使用这些条目。在这两种条目的说明之后给出了一个映射表示例。

此时，两种类型的条目是：

• C.2.5.1 消息标题条目

• C.2.5.2 消息正文条目

C.2.5.1 消息标题条目

这些条目指定了 SMS 消息中应包含哪些消息标题行，以及应如何缩写这些标题行或应如何转换这些标题行（在不能缩写时）。只有当其中一个条目将一个标题行成功映射到一个非零长度的字符串时，该标题行才能包含到将要生成的 SMS 消息中。每个条目都具有以下格式

H|pattern replacement-text

如果消息标题行与该模式匹配，则将会使用映射文件的模式匹配和字符串替换功能将该标题行替换为替换文本 replacement-text。如果在替代文本中指定了元字符 $Y，则标题行的最终映射结果将会包含在 SMS 消息中。如果某个标题行与任何模式字符串都不匹配，而且如果其映射到一个零长度的字符串或者在替代文本中未指定 $Y 元字符，则 SMS 消息中将忽略该标题行。两个条目

H|From:* F:$0$Y 
H|Subject:* S:$0$Y

会使 From: 和 Subject: 标题行包含在 SMS 消息中，其中 From: 和 Subject: 分别缩写为 F: 和 S:。条目：

H|Date:* H|D:$0$R$Y 
H|D:*,*%19%%*:*:* H|D:$0$ $5:$6$R$Y

会使 Date: 标题行被接受和映射，因此，例如标题行

Date: Wed, 16 Dec 1992 16:13:27 -0700 (PDT)

转换成

D: Wed 16:13

可能会生成非常复杂的重复映射。希望设置定制过滤器的站点将首先需要了解映射文件的工作原理。在必要时可将条目右侧的 H| 忽略。允许在该侧出现 H|，以便减小重复映射集所需的表条目数量。

C.2.5.2 消息正文条目

这些条目建立了适用于每行消息正文的映射。每行消息正文将在并入被生成的 SMS 消息中之前，通过这些映射进行传送。这些条目的格式为：

B|pattern B|replacement-text

如果消息正文中的某一行与 pattern 模式匹配，则会被替换文本 replacement-text 所替换。使用这种功能还会构造非常复杂的重复映射。在必要时可省略条目右侧的 B|。

C.2.5.3 SMS 映射表示例

示例 C–1 中显示了一个 SMS_TEXT 映射表示例。每行末尾括号内的数字都对应于该表之后标题为说明文本一节中的条目编号。

示例 C–1 SMS_TEXT 映射表示例。

SMS_TEXT

   H|From:*        H|F:$0$R$Y       (1)
   H|Subject:*     H|S:$0$R$Y       (1)
   H|F:*<*>*       H|F:$1$R$Y       ()
   H|F:*(*)*       H|F:$0$2$R$Y     (2)
   H|F:*"*"*       H|F:$0$2$R$Y     (3)
   H|F:*@*         H|F:$0$R$Y       (4)
   H|%:$ *         H|$0:$1$R$Y      (5)
   H|%:*$          H|$0:$1$R$Y      (5)
   H|%:*$ $ *      H|$0:$1$ $2$R$Y  (6)
   B|*--*          B|$0-$1$R        (7)
   B|*..*          B|$0.$1$R        (7)
   B|*!!*          B|$0!$1$R        (7)
   B|*??*          B|$0?$1$R        (7)
   B|*$ $ *        B|$0$ $1$R       (6)
   B|$ *           B|$0$R           (5)
   B|*$            B|$0$R           (5)

               

说明文本

上述 SMS_TEXT 映射表示例中条目的说明如下：

上例中，元字符 $R 用于实现和控制映射的重复应用。通过在这些映射上迭代，可获得强大的过滤功能。例如，要清除单个前导或后缀空格 (6) 或将两个空格缩减为一个空格 (7) 的简单映射在作为整体采用时会成为一个过滤器，能够去除全部前导和后缀空格并将多个连续空格缩减为一个空格。这种过滤有助于减少每条 SMS 消息的长度。

1. 这两个条目会使 From: 和 Subject: 标题行包含在 SMS 消息中。From: 和 Subject: 分别缩写为 F: 和 S:。某些其他条目可以进一步影响 From: 和 Subject: 标题行。

   此条目将把包含 <...> 模式的 From: 标题行缩减至只剩下尖括号中的文本。例如：

   F: "John C. Doe" <jdoe@siroe.com> (Hello)

   将被替换为：

   F: jdoe@siroe.com

2. 此条目将删除 From: 标题行中 (...) 模式内包含的所有内容。例如：

   F: "John C. Doe" <jdoe@siroe.com> (Hello)

   将被替换为：

   F: "John C. Doe" <jdoe@siroe.com>

3. 此条目将删除 From: 标题行中 "..." 模式内包含的所有内容。例如：

   F: "John C. Doe" <jdoe@siroe.com> (Hello)

   将被替换为：

   F: <jdoe@siroe.com> (Hello)

4. 此条目将删除 From: 标题行中 at 符号 (@) 右侧包含的所有内容。例如：

   F: "John C. Doe" <jdoe@siroe.com> (Hello)

   将被替换为：

   F: "John C. Doe" <jdoe@

5. 这四个条目将从消息标题和正文行中删除前导和后缀空格。

6. 这两个条目会将消息标题和正文行中的两个空格缩减为一个空格。

7. 这四个条目会将双字节短划线、句号、感叹号和问号转变成匹配字符的单字节形式。这样还有助于缩减 SMS 消息中的字节数。

条目的顺序是非常重要的。例如，按照给定顺序，消息 From: 标题行的正文：

From: "John C. Doe" (Hello)

将缩减为：

jdoe

实现这一目的的操作步骤如下：

1. 我们以 From: 标题行开始：

   From: "John C. Doe" (Hello)

   第一个映射条目中的模式将与之匹配并生成以下结果：

   F: "John C. Doe" (Hello)

   结果字符串中的 $R 元字符将使结果字符串被重新映射。

2. 此映射将应用到上一步的结果字符串中。这将生成：

   F: jdoe@siroe.com

   映射中的 $R 会把整个映射集重新应用到此步骤的结果中。

3. 接下来，将应用映射生成：

   F: jdoe

   映射中的 $R 会把整个映射集重新应用到此步骤的结果中。

4. 接下来，将应用映射生成：

   F:jdoe

   映射中的 $R 会把整个映射集重新应用到此步骤的结果中。

5. 由于其他条目都不匹配，所以最后将得到以下字符串：

   F:jdoe

   该字符串被并入到 SMS 消息中。

   ---

   注 –

   imsimta 测试映射实用程序可用于测试映射表。例如，

   # imsimta test -mapping -noimage_file -mapping_file=test.txt Enter table name: SMS_TEXT Input string: H|From: "John C. Doe" (Hello) Output string: H|F:jdoe Output flags: [0,1,2,89] Input string: ^D #

   有关 imsimta test 实用程序的详细信息，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“imsimta test”。

   ---