一种确认版本信息的方法、装置及系统的制作方法

专利名称：一种确认版本信息的方法、装置及系统的制作方法
技术领域：
本发明涉及通信领域，特别涉及一种确认版本信息的方法、装置及系统。
背景技术：
随着第三代移动通信标准化组织3GPP(3rd Generation PartnershipProject)协 议的不断演化，核心网的移动应用部分MAP (Mobile ApplicationPart)协议已经发展出多 个版本，如Phasel，PhaSe2、Phase2+等等。随着版本的升高，MAP协议所能实现的功能不断 增加，提供了越来越多的业务支撑，同时也使现行网络中各个设备支持的版本多样化、复杂 化。而正是由于现行网络设备构成的复杂性，不同协议版本的设备之间的交互也相应复杂 起来。因此，网络设备在交互时可能存在采用的MAP层协议版本不一致的情况，对于这种情 况，MAP层协议规定需要进行对话。通过降低版本、向下兼容的方式完成交互，这样就导致如 果网络中设备的MAP层协议版本不一致，就必然存在大量的版本协商。目前为了有效减少 网络中各个设备之间的对话操作，传统的方法一是通常采用统一网络设备的MAP版本的方 式，使网络中所有的设备的MAP版本一致，避免网络设备之间的对话。随着MAP版本自身的 不断改进以及各种新业务的不断发展，使网络中所有的设备的MAP版本一致、避免网络设 备之间的对话已变得不可能。传统的方法二是通过记录接收、发送成功的消息中的对端设 备地址和采用的MAP版本信息，然后后续发送消息给这些设备时可采用之前记录的MAP版 本信息，从而有效减少对话。该方法实现的前提是必须通过成功的消息交互(如发送或接 收)，从而获取对端版本信息，才能在后续的消息交互中直接使用之前记录的版本号。而现 存网络中有大量对端设备并不支持版本协商流程，导致设备间交互无法成功，不能记录对 端设备的版本信息，而达不到减少对话的目的，造成网络资源的浪费。

发明内容
有鉴如此，为了解决现存网络中存在许多设备由于不支持版本协商，导致设备间
交互失败，无法确认对端设备的版本信息而导致对话失败的问题。 本发明实施例提出的一种版本信息确认的方法，具体包括 向设备发起第一次对话请求，并接收所述设备针对所述第一次对话请求返回的错 误码信息；根据所述错误码信息向所述设备发起多次对话请求，根据所述设备针对所述多 次对话请求返回的多次信息确定所述设备的版本信息 相应的，本发明实施例提出了一种确认版本信息的系统，具体包括第二设备用于 确认第一设备的版本信息，所述第一设备，用于根据所述第二设备发起的对话请求返回信 息； 所述第二设备，用于向所述第一设备发起第一次对话请求，并接收所述第一设备 针对所述第一次对话请求返回的错误码信息，根据所述错误码信息向所述第一设备发起多 次对话请求，根据所述第一设备针对所述多次对话请求返回的多次信息确定所述第一设备 的版本信息。
4
同时，本发明实施例提出了一种确认版本信息的装置，具体包括 请求模块，用于向设备发起对话请求； 接收模块，用于接收所述设备针对每次对话请求返回的信息； 判断模块，用于判断所述设备针对每次对话请求返回的信息是否为错误码信息；
当所述设备针对所述第一次对话请求返回的信息为错误码信息时，触发所述请求模块继续
发起对话请求，并在后续对话请求的返回信息为非错误码信息时，继续触发所述请求模块； 当后续对话请求的返回信息为错误码信息时，则触发确认模块；
确认模块，用于确认所述设备的版本信息。 本发明实施例方案由于对于不支持版本协商的设备通过采用多次尝试的方式最 终确认对端设备的版本信息，克服了许多设备不支持版本协商流程，导致设备间交互无法 成功，不能确认设备的版本信息的技术问题，根据多次交互可以确认不支持版本协商的设 备的版本信息。


图1为本发明的确认版本信息方法一个实施例的流程图。 图2为本发明的确认版本信息方法又一个实施例的流程图。 图3为本发明的确认版本信息方法又一个实施例的流程图。 图4为本发明的确认版本信息系统一个实施例的结构示意图。 图5为本发明的确认版本信息设备一个实施例的结构示意图。 图6为本发明的确认版本信息设备又一个实施例的结构示意图。
具体实施例方式
本发明实施例提供了一种确认版本信息方法，如图1所示，包括步骤 步骤102，向设备发起第一次对话请求，并接收设备针对第一次对话请求返回的错
误码信息。 这里以第二设备向第一设备发送对话请求为例进行说明，由于第二设备是第一次
向第一设备发起对话请求，第二设备不清楚第一设备的版本信息，按照随机版本向设备发
起对话请求。当第一设备不支持发起该对话请求的版本时，向第二设备发送错误码信息。 其中，错误码信息表示第一设备不支持接收到的对话请求的版本。鉴于网络错误
原因的多样性，可以预先将不支持版本协商的错误原因配置为错误码信息，比如，不支持发
起对话请求的版本的错误原因为X，则将X配置为错误码信息。当第二设备接收到第一设备
返回的错误原因时，可以根据预先配置的数据判断该错误原因是否为错误码信息，若为错
误码信息则认为第一设备不支持版本协商。该特征适用于本发明其他实施例。 步骤104，根据错误码信息向设备发起多次对话请求，根据设备针对多次对话请求
中的多次返回的信息确定设备的版本信息。 第二设备在接收到的第一设备返回的错误码信息时认定第一设备不支持第一次 对话请求的版本。此时，第二设备可以通过调整发起对话请求的版本信息，并以调整后的版 本向第一设备发起对话请求，再根据第一设备针对调整版本后的对话请求所返回的信息来 确定第一设备的版本信息。 一般情况下，调整版本并发起对话请求的过程可以是多次的，第一设备针对每一次调整版本后的对话请求，均返回信息。 本发明实施例中，在进行首次版本调整时，可以先将版本信息调整为最低版本。如 果第一设备针对调整后的对话请求返回的是非错误码，则认为第一设备支持调整后的版 本，此时，以递增的方式继续调整版本信息，并发起对话请求，重复该过程，直至第一设备返 回的信息为错误码信息时，停止调整版本信息，将上一次对话请求的版本信息确定为第一 设备的版本信息。如果版本信息调整至最高版本时，均返回非错误码信息，则停止调整，将 第一设备的版本信息确定为最高版本。 当然，在调整版本时，也可以通过从高版本到低版本向设备发起多次对话请求，或
者采用二分法，即从中间版本向设备发起多次对话请求来确定设备的版本信息。 本发明实施例，通过预先配置，当返回错误码信息时，直接认定第一设备不支持其
接收到的对话请求的版本，并通过调整每次发起对话请求的版本信息，根据第一设备针对
每次对话请求返回的信息，进行多次尝试，从而确定第一设备的版本信息。为后续的交互节
省了版本协商过程，从整体来看，提高了网络资源的利用率。 在一些应用中，如，MAP中，由于第一设备不能识别对话请求而返回的错误原因也
为X，因此，根据预先的配置，不能识别对话请求而返回的错误原因也被认为是错误码信息。
不过由于设备不能识别对话请求的情况发生的概率较低，当按照随机版本发送对话请求返
回错误码信息时，本发明实施例中也可以推定错误码信息是该设备不支持版本协商而返回
的消息，并通过采用上述调整版本信息的方式来确认第一设备的版本信息。 本发明实施例也可以采取多次尝试的方式来排除错误码信息是不能识别对话请
求而返回的错误原因的情况，具体的，当接收到的第一设备返回的错误码信息时，重复以当
前版本向第一设备发起对话请求，当重复次数到达预先设定的次数，均返回错误码信息时，
则认为错误码信息是不支持版本协商而返回的消息，而不是不能识别对话请求而返回的消息。 图2为本发明实施例提供的一种确认版本信息方法的具体流程，对多次调整发起 对话请求版本信息的过程进行了详细说明，如图2所示，包括步骤
步骤202，第二设备向第一设备发起对话请求。 第二设备第一次向第一设备发送对话请求，故无第一设备的版本信息，按照随机 版本向第一设备发送对话请求。其中，设置随机版本为非最低版本，或者随机版本为非低于 设备版本。原因是设备对版本具有向下兼容的属性，假设随机版本是最低版本，或是比第一
设备更低的版本，则第一设备可能支持版本协商。 步骤204，第一设备向第二设备返回错误码信息。 步骤206，第二设备根据第一设备返回的错误码信息认定第一设备是不支持版本 协商。 错误码信息可以预先配置，用来表示第一设备不支持接收到的对话请求的版本， 第二设备根据预先配置的数据判断第一设备返回的信息是错误码信息，从而认定第一设备 不支持版本协商。 如前述提到，在MAP中，返回错误码信息的原因有两种向设备发送对话请求，设 备不支持版本协商返回的消息；或者，向设备发送对话请求，设备不能识别对话请求而返回 的消息。
本发明实施例中，可以不对以上两种情况进行区分，直接认为错误码信息是该设
备不支持版本协商而返回的消息。认定设备不支持版本协商是从概率的角度和节省网络交
互过程角度来推测，如果判定错误，可以通过后续的确认过程来纠正。所以，对于第一次发
起对话请求而返回的错误码信息，认定是设备不支持版本协商的情形导致。 可选的，第二设备也可以进一步通过重复按照相同的版本向第一设备发起对话请
求确认第一设备不支持版本协商。通过重复发送对话请求来确认第一设备不支持第一次对
话的版本协商，该方法可用于本发明其他实施例， 步骤208，第二设备按照最低版本向第一设备发起对话请求。 第二设备在接收到第一设备返回的错误码信息时，将发起对话请求的版本信息调 整为最低版本，并以调整后的版本继续发起对话请求。
步骤210，第一设备向第二设备返回非错误码信息。 由于设备具有向下兼容的特点，第一设备一般都支持最低版本的对话请求，因此， 第一设备在接收到以最低版本发起的对话请求时，向第二设备返回非错误码信息。其中，非 错误码信息可以成功应答消息，还可以包括返回的错误原因不属于错误码信息所对应的原 因的消息，例如设备因为停电或没有运行等，设备可能不是直接返回成功应答信息，而是返 回一个错误消息，但该错误消息的错误原因不是错误码信息对应的不支持版本协商的错误 原因X。 步骤212，第二设备根据返回的非错误码信息暂时记录第一设备的版本信息。
第二设备接收到第一设备返回的信息后，判断接收到的信息为非错误码信息，则 将发起当次对话请求的版本信息暂时记录为第一设备的版本信息，如，当接收到步骤210 返回的非错误码信息时，则将第一设备的版本信息暂时记录为最低版本。在记录时，若已存 在暂时记录的第一设备的版本信息，则对已记录的版本信息进行替换；若不存在，则直接进 行记录。 步骤214，第二设备按照暂时记录的版本之上递增一个版本向第一设备发起对话 请求。 第二设备在收到第一设备返回的非错误码信息之后，以递增的方式继续进行版本 调整，并发起对话请求。 步骤216，第二设备接收第一设备返回的信息。 步骤218，若该返回信息为非错误码信息，则返回步骤212，若返回的信息为错误 码信息，则执行步骤220。 若返回的信息为非错误码信息，则第一设备支持此次对话请求中的版本协商。第 二设备继续调整发起对话的版本向第一设备发起对话请求，每次返回非错误码信息后，暂 时记录第一设备的版本信息，并且，每次暂时记录的般本信息对前次暂时记录的版本信息 进行替换。每次按照替换版本之上递增一个版本向第一设备发起对话请求，第二设备在每 次返回非错误码信息后，对第一设备暂时记录的版本信息予以替换。 第二设备通过调整每次发起对话请求的版本信息，根据调整的版本信息向第一设 备发起对话请求，并接收第一设备针对每次对话请求返回的信息，直至第一设备返回的信 息为错误码信息，第二设备将上一次对话请求的版本信息确定为第一设备的版本信息。即 通过不断调整递增发起对话的版本信息的过程确定第一设备最终的版本信息。
可选的，在返回步骤212之前，还可以进一步判断当次发起对话请求的版本是否 已达到最高版本，若否，则返回步骤212 ;否则，执行步骤220。 步骤220，确认第一设备不支持该次版本协商，确认设备版本信息为上一次暂时记 录的版本信息。 如前述提到返回错误码信息的原因有两种向第一设备发送对话请求，第一设备 不支持版本协商返回的消息；或者，向第一设备发送对话请求，第一设备不能识别对话请求 而返回的消息。设备不能识别对话请求的情况发生的概率较低。故直接推定返回错误码信 息是第一设备不支持版本协商而返回的消息。 通过返回的错误码信息确定第一设备不支持按照暂时记录的版本之上递增一个 版本或者不支持替换暂时记录的版本之上递增一个版本的版本协商，从而确定第一设备的 版本信息为暂时记录的版本。如果暂时记录的过程是以替换的方式进行，则第一设备的版 本信息为最后一次暂时记录的版本信息。 第二设备将确认的第一设备的版本信息保存，在下次与第一设备的交互过程中， 第二设备直接将第一设备按照确认保存的版本信息进行交互。为后续的交互节省了版本协 商过程，从整体来看，提高了网络资源的利用率。 可选的，若第二设备递增调整版本信息至最高版本向第一设备发起对话请求，第 一设备返回非错误码信息，则第一设备支持最高版本的协商。故确认第一设备版本信息为 最高版本。 本发明实施例提供了一种确认版本信息方法，本实施例以MAP层协议中的版本协 商为例进行说明，如图3所示，包括步骤 步骤302至步骤316与步骤202至216相同，此处不再赘述。 步骤318，若该返回信息为非错误码信息，则返回执行步骤312，若返回的信息为
错误码信息，则执行步骤320。 步骤320至步骤322，第二设备向第一设备重复发起对话请求，并接收第一设备返 回的信息。 即步骤318中返回的信息为错误码信息，则第二设备以此次发起对话请求的版本 信息向第一设备重复发起对话请求，此次发起对话请求的版本信息即在上一次暂时记录的 版本之上递增一个版本之后的版本信息。 若重复发起对话请求达到设置的阈值的次数时，并且，第一设备返回的信息均是 错误码信息，则确认第一设备不支持该次的版本协商，即执行步骤324。该阈值可以是任一 自然数，阈值越大，越能确定返回错误码信息的原因是不支持版本协商，阈值由第二设备设 定。从精确度(重复次数越多越能确定第一设备返回错误码信息是不支持版本协商的原 因)和节省网络资源(重复次数越少越节约网络资源)的角度，可以将阈值设置为5。即第 二设备按照暂时记录的版本之上递增一个版本向第一设备重复发起对话请求5次，第一设 备均返回错误码信息，则确定第一设备不支持该次版本协商。通过多次尝试排除是由于第 一设备不能识别对话请求的情形，确定返回错误码信息就是设备不支持版本协商。通过多 次尝试发起对话请求，如果多次均返回错误码信息，排除第一设备是不能识别对话请求的 情形，而是不支持版本协商的原因导致第一设备返回错误码信息。第二设备将确认第一设 备的版本信息保存，在下次与第一设备的交互过程中，第二设备直接将第一设备按照确认
8保存的版本信息进行交互。为后续的交互节省了版本协商过程，从整体来看，提高了网络资 源的利用率。 若重复发起对话请求达到该设置的阈值的过程中，即在第二设备向第一设备重复 发起对话请求该设置的阈值的次数范围内，第一设备返回非错误码信息，则立即终止执行 重复发起对话请求。因为，第一设备返回非错误码信息即证明第一设备支持版本协商。并 且返回执行步骤312。即将第一设备暂时记录第二设备的版本信息进行替换。
本发明实施例提供了一种确认版本信息系统，如图5所示，包括第二设备404，用 于确认第一设备的版本信息，该第一设备402根据第二设备404发起的对话请求返回信息。
第二设备404，用于向第一设备402发起第一次对话请求，并接收第一设备402针 对第一次对话请求返回的错误码信息，根据错误码信息向第一设备402发起多次对话请 求，根据第一设备402针对多次对话请求返回的多次信息确定第一设备的版本信息。第二 设备404为一种确认设备版本信息的装置。 第二设备404向第一设备402发起的多次对话请求中第一次对话请求的版本信息 调整为最低版本，并以递增的方式调整后续每次发起对话请求的版本信息。第二设备404 以调整后的版本信息向第一设备402发起每次对话请求，并接收第一设备402根据每次发 起对话请求返回的信息，直至第一设备402返回错误码信息，则第二设备404将上一次对话 请求的版本信息确认为第一设备402的版本信息。若第二设备404调整每次发起对话请求 的版本信息至最高版本时，均返回非错误码信息，则确定第一设备402的版本信息为最高 版本信息。 可选的，当第一设备402返回的信息为非错误码信息时，第二设备404将当次发起 对话请求的版本信息暂时记录为第一设备402的版本信息，并在暂时记录第一设备402的 版本信息时，对上一次暂时记录的第一设备402的版本信息进行替换，直至将最后一次暂 时记录第一设备402的版本信息确认为第一设备402的版本信息， 本发明实施例提供了一种确认版本信息装置，如图5所示，包括请求模块502，接
收模块504，判断模块506，确认模块508。 请求模块502，用于向设备发起对话请求。 其中，请求模块502向设备发起的对话请求中携带了对话的版本信息。如果对端 设备不支持请求模块502发起的对话请求的版本，请求模块502将向对端设备发起多次对 话请求。 接收模块504，用于接收设备针对每次对话请求返回的信息。 设备根据请求模块502发送的对话请求返回信息，接收模块504接收该设备返回 的信息。该设备返回的信息根据请求模块502发起的对话请求携带的不同版本，结合自身 是否支持该版本返回不同的信息，如，不支持时返回错误码信息。 判断模块506，用于判断设备针对每次对话请求返回的信息是否为错误码信息； 当设备针对第一次对话请求返回的信息为错误码信息时，触发请求模块502继续发起对话 请求，并在后续对话请求的返回信息为非错误码信息时，继续触发请求模块502 ;当后续对 话请求的返回信息为错误码信息时，则触发确认模块508。
确认模块508，用于确认设备的版本信息。 其中，判断模块506可以根据预先配置的错误原因判断返回的信息是否为错误码信息。请求模块502先以随机版本向设备发起对话请求，当设备返回的信息为错误码信息 时，判断模块506则触发请求模块502继续发起对话请求。具体的，当该错误码信息是由于 设备不能识别对话请求而返回的消息时，请求模块502可以以当前的版本信息继续发起对 话请求，当该错误码信息是由于设备不支持发起对话请求的版本时，请求模块502可以通 过调整发起对话请求的版本信息继续发起对话请求。 在上述后续发起的多次对话请求中，判断模块506继续判断设备针对后续发起的 对话请求返回的信息是否为错误码信息，如果是非错误码信息，则触发请求模块502调整 版本信息并发起对话请求；如果是错误码信息，则触发确认模块508，确认模块508根据判 断模块506的判断结果，确认设备的版本信息。 具体的，图5所示的确认版本信息装置的工作原理可以参考图2所示的方法，在此 不赘述。其中，各模块的具体结构可参考图6所示的实施例。 结合参看图6，本发明实施例提供了一种确认版本信息装置，包括请求模块602，
接收模块604，判断模块606，确认模块610。 请求模块602，用于向设备发起对话请求。 接收模块604，用于接收设备针对每次对话请求返回的信息。 判断模块606，用于判断设备针对每次对话请求返回的信息是否为错误码信息； 当设备针对第一次对话请求返回的信息为错误码信息时，触发请求模块602继续发起对话 请求，并在后续对话请求的返回信息为非错误码信息时，继续触发请求模块602;当后续对 话请求的返回信息为错误码信息时，则触发确认模块610。
确认模块610，用于确认设备的版本信息。 可选的，该装置可以包括记录子模块608，用于在设备返回的信息为非错误码信息 时，记录当次发起的对话请求的版本信息，并在记录版本信息时，对上一次记录的版本信息 进行替换。 其中，请求模块602可具体包括调整子模块6022，用于调整发起对话请求的版本
信息；发送子模块6024，用于根据调整子模块6022调整的版本信息发起对话请求。 具体的，调整子模块6022可以根据判断模块606的触发将上述后续对话请求中
的第一次对话请求调整为最低版本，并以递增的方式调整后续每次发起对话请求的版本信息。 可选的，请求模块602还可以包括判断子模块6026，用于判断版本信息是否已调 整至最高版本，若是则触发确认模块610，否则触发调整子模块6022再次调整版本信息。
确认模块610在版本信息已调整至最高版本时，将设备的版本信息确定为最高版 本。 在未调整至最高版本时，确认模块610直接根据判断模块606的判断结果确认设 备的版本信息。具体的，确认模块610可包括触发子模块6102，用于当设备返回信息为错 误码信息时，触发阈值子模块6104;阈值子模块6104用于判断以当前版本信息发送起对话 请求的次数是否超过阈值，若是，则触发认定子模块6106 ;若否，则触发请求模块中的发送 子模块6024继续以当前版本信息发送对话请求；认定子模块6106，用于将记录模块608中 最后一次记录的版本信息确认为所述设备的版本信息。 可选的，该确认设备版本信息的装置包括存储模块，用于保存确认模块610中确认设备的版本信息。 具体的，图6所示的确认版本信息装置的工作原理可以参考图3所示的方法，在此 不赘述。 本发明实施例方案由于对于不支持版本协商的设备通过采用多次尝试的方式最 终确认对端设备的版本信息，克服了许多对端设备不支持版本协商流程，导致设备间交互 无法成功，不能确认对端设备的版本信息的技术问题，从而解决了不支持版本协商的设备 交互、兼容的问题，通过确认不支持版本协商的设备的版本信息，为后续的交互节省了版本 协商过程，从整体来看，提高了网络资源的利用率。 通过以上实施例的描述，本领域的技术人员可以清楚地了解到需要说明的是，本 发明实施例不需要引入独立的功能部件，可借助软件加必需的通用硬件平台的方式来实 现，基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分 可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指
令用以执行本发明各个实施例所述的方法。这里所称的存储介质，如R0M/RAM、磁盘、光盘等。 综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。 凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的 保护范围之内。
1权利要求
一种确认版本信息的方法，其特征在于，所述方法包括向设备发起第一次对话请求，并接收所述设备针对所述第一次对话请求返回的错误码信息；根据所述错误码信息向所述设备发起多次对话请求，根据所述设备针对所述多次对话请求返回的多次信息确定所述设备的版本信息。
2. 如权利要求1所述的方法，其特征在于，所述向设备发送第一次对话请求包括 按照随机版本向所述设备发送对话请求，并且所述随机版本为非最低版本。
3. 如权利要求1或2所述的方法，其特征在于，根据所述错误码信息向所述设备发起多次对话请求包括根据所述错误码信息判定所述设备不支持版本协商，向所述设备发起多 次对话请求；所述错误码信息包括所述设备不支持版本协商返回的消息；或者，所述设备不能识 别对话请求而返回的消息。
4. 如权利要求1所述的方法，其特征在于，所述向所述设备发起多次对话请求，根据所 述设备针对所述多次对话请求返回的多次信息确定所述设备的版本信息包括调整每次发起对话请求的版本信息，根据所述调整的版本信息发起对话请求，并接收 所述设备针对所述每次对话请求返回的信息，直至所述设备返回的信息为错误码信息，将 上一次对话请求的版本信息确定为所述设备的版本信息；或者，若所述调整每次发起对话请求的版本信息至最高版本时，均返回非错误码信息，则确 定所述设备的版本信息为最高版本。
5. 如权利要求4所述的方法，其特征在于，所述调整每次发起对话请求的版本信息包括将所述多次对话请求中的第一次对话请求的版本信息调整为最低版本，并以递增的方 式调整后续每次发起对话请求的版本信息。
6. 如权利要求5所述的方法，其特征在于，所述方法还包括在所述设备返回的信息为非错误码信息时，将当次发起的对话请求的版本信息暂时记 录为所述设备的版本信息，并在暂时记录所述设备的版本信息时，对上一次暂时记录的所 述设备的版本信息进行替换。
7. 如权利要求6所述的方法，其特征在于，所述将上一次对话请求的版本信息确定为 所述设备的版本信息包括将最后一次暂时记录的版本信息确定为所述设备的版本信息。
8. 如权利要求6所述的方法，其特征在于，该方法还包括当所述返回信息为错误码信息时，重复向所述设备发起本次对话请求，直至接收到所 述设备返回的信息为非错误码信息，则执行所述调整每次发起对话请求的版本信息，根据 所述调整的版本信息发起对话请求；否则，当重复向所述设备发起本次对话请求的次数达 到预先设定的阈值时，执行所述将上一次对话请求的版本信息确定为所述设备的版本信息。
9. 一种确认版本信息的系统，其特征在于，所述系统包括第二设备用于确认第一设 备的版本信息，所述第一设备，用于根据所述第二设备发起的对话请求返回信息；所述第二设备，用于向所述第一设备发起第一次对话请求，并接收所述第一设备针对 所述第一次对话请求返回的错误码信息，根据所述错误码信息向所述第一设备发起多次对话请求，根据所述第一设备针对所述多次对话请求返回的多次信息确定所述第一设备的版 本信息。
10. —种确认版本信息的装置，其特征在于，所述装置包括 请求模块，用于向设备发起对话请求；接收模块，用于接收所述设备针对每次对话请求返回的信息；判断模块，用于判断所述设备针对每次对话请求返回的信息是否为错误码信息；当所 述设备针对第一次对话请求返回的信息为错误码信息时，触发所述请求模块继续发起对话 请求，并在后续对话请求的返回信息为非错误码信息时，继续触发所述请求模块；当后续对 话请求的返回信息为错误码信息时，则触发确认模块；确认模块，用于确认所述设备的版本信息。
11. 如权利要求10所述的装置，其特征在于，所述请求模块包括 调整子模块，用于调整发起对话请求的版本信息； 发送子模块，用于根据调整的版本信息发起对话请求。
12. 如权利要求11所述的装置，其特征在于，调整子模块具体用于将所述后续对话请 求中的第一次对话请求调整为最低版本，并以递增的方式调整后续每次发起对话请求的版 本信息；所述请求模块还包括判断子模块，用于判断版本信息是否已调整至最高版本，若是则触发确认模块，否则触 发调整子模块。
13. 如权利要求12所述的装置，其特征在于，所述装置还包括记录模块，用于在所述设备返回的信息为非错误码信息时，记录当次发起的对话请求 的版本信息，并在记录所述版本信息时，对上一次记录的版本信息进行替换。
14. 如权利要求13所述的装置，其特征在于，所述确认模块具体用于将所述记录模块 中最后一次记录的版本信息确认为所述设备的版本信息。
15. 如权利要求13所述的装置，其特征在于，所述确认模块包括 触发子模块，用于当所述返回信息为错误码信息时，触发阈值子模块； 所述阈值子模块，用于判断以当前版本信息发起对话请求的次数是否超过阈值，若是，则触发认定子模块；若否，则触发请求模块中的发送子模块；所述认定子模块，用于将所述记录模块中最后一次记录的版本信息确认为所述设备的 版本信息；所述发送子模块还用于根据所述触发模块的触发以当前版本信息继续发起对话请求。
16. 如权利要求10至15任一项所述的装置，所述装置还包括存储模块，用于保存所 述确认模块确认的所述设备的版本信息。
全文摘要
本发明公开了一种确认版本信息的方法，该方法包括如下步骤向设备发起第一次对话请求，并接收设备针对第一次对话请求返回的错误码信息；根据错误码信息向设备发起多次对话请求，根据设备针对所述多次对话请求中的所述多次返回的信息确定设备的版本信息。同时，本发明还公开了一种确认版本信息的系统和装置。确认不支持版本协商的设备的版本信息，解决了不支持版本协商的设备交互、兼容的问题。
文档编号H04W88/00GK101742700SQ20081021779
公开日2010年6月16日 申请日期2008年11月27日 优先权日2008年11月27日
发明者肖白沙 申请人:华为技术有限公司