Megaco学习笔记之基于UDP的传输（重传，临时相应）

D.1.1 提供“最多一次”功能

当协议消息在UDP上进行传输时，可能会发生消息丢失。如果发送的消息无法获得及时响应，则可能导致命令重复发送。对重发的消息，协议处理进程必须遵循 “最多一次”机制。

协议实体应当在各自的内存中保留两个列表， 一个用来记录执行完最近所接收到的TransactionRequest后返回的TransactionReply，另一个用来记录当前需要处理的事务。当协议实体接收到一个TransactionRequest 消息时， 它将接收到消息的TransactionID 与最近为具有相同MID 发出的TransactionReply响应的TransactionID相比较。两者经过比较后，如果发现TransactionID相同，则接收方不应执行接收到的事务，而只是重复发送TransactionReply响应消息。如果发现TransactionID不相同，则接收方将该接收到的TransactionRequest消息与需要处理的事务列表相比较。如果在列表中查找到TransactionID相同的消息，则表明此TransactionRequest消息为重复发送，接收方不应执行此TransactionRequest消息（参见D.1.4中TransactionPending发送机制）。
协议处理机制规定了一个长定时器值（LONG-TIMER），LONG-TIMER设定的时间值应该大于一个事务的最大持续时间，该时间还应该考虑事务重复最大次数、重复定时器的最大值以及分组在网络中的最大传输时延。

当协议实体发出响应消息后，如果LONG-TIMER超时，或者已接收到来自对等实体包含“ResponseAcknowledgement Parameter”参数的响应证实消息，则协议实体重复发送的TransactionReply响应消息应被丢弃。

D.1.3 计算重传定时器

消息请求的发送方应为所有发送的事务指定一个重传定时器，当重传定时器超时，消息请求的发送方实体仍未接收到消息响应，则应当重复发送该事务。当重复多次发送的事务仍未获得响应时，且从第一次消息发送开始至定时器超时，请求的发送方应当采用其他机制和/或拆除现有或即将建立的连接。

本建议书未对重传定时器数值进行规定。通常重传定时器的数值与特定的网络状况有关。通常，重传定时器应该通过检测发出消息与接收消息响应之间的时间间隔来估计重传定时器数值。具体实现时，发生第一次消息重传后，重传定时器计算算法必须对此后发生的每一次重传的重传定时器数值按指数递增方式进行补偿。

当Transaction重传次数达到某个值N（通常7<N<11）,则认为该连接断开(H248行业标准)。

D.1.4 临时响应

在事务执行过程中，某些事务执行可能需要较长的时间。从而可能会导致事务执行与基于重传定时器的重传进程发生冲突。执行时间太长可能导致事务被重传多次，或者导致重传定时器数值过大而降低传输的效率。如果协议实体已经预见到某一事务需要较长的执行时间， 则它可以先发送一个TransactionPending临时响应消息来指示该事务正在被处理。当协议实体接收到重复的TransactionRequest消息，如果该事务正在处理，也应该发送TransactionPending消息。

接收到TransactionPending消息的实体必须为TransactionPending消息对应的TransactionRequest消息的重传定时器设定一个不同数值。如果发起TransactionRequest的实体在接收到Transaction Pending消息之后，接收到最终的TransactionReply消息，则必须立即向对端实体发送一个确认消息，此后，必须重新使用通常的重传定时器。对于发送了TransactionPending临时响应消息的实体，必须在发送的最终响应中包含一个“immAckRequired（需要立即确认）”字段，通过这一字段来表明该实体希望能够获得一个立即的确认消息。对于同一个TransactionRequest，实协议体在接收到最终TransactionReply之后，必须忽略接收的TransactionPending消息。

根节点有一个属性“ProvisionalResponseTimerValue”(临时相应定时器取值)，用来设置受到request和送出requestpending的timer(H248行业标准)