CN103023868B - 用于发送寻呼模式消息的方法和设备 - Google Patents

Abstract

本公开涉及寻呼模式消息收发。一种提供寻呼模式消息收发的途径，其使用会话模式消息收发机制来发送具有指示会话模式是用于寻呼类型消息的指示的消息。响应于所述指示，接收器将该消息作为寻呼模式消息，即使该消息是以会话模式接收的。

Description

用于发送寻呼模式消息的方法和设备

相关申请交叉引用

本申请是国际申请号为PCT/FI2006/050234、国际申请日为2006年6月5日、进入国家阶段日期为2008年1月15日、中国申请号为200680025858.7的发明专利申请的分案申请。

技术领域

本发明涉及消息收发，并更具体地，涉及寻呼模式消息收发，也称为一次消息收发。

背景技术

通信技术，特别是基于IP的通信技术和最终用户终端的演进已经支持多种通信可能性和不同服务的引入。越来越多的服务通过使用由SIP(会话发起协议)所提供的原语来实现，其中SIP并非垂直集成在通信系统中，而是集成在构建多媒体架构的工具中。更具体地，SIP是一种IETF定义的应用层控制(信令)协议用于创建、修改以及终止与一个或多个参与者之间的会话。这些会话例如包括网络电话呼叫、多媒体分发、多媒体会议以及PoC(蜂窝上的按键通话)会话。为了进行消息收发服务，使用SIP和现有SIP实现以提供在线和即时消息收发服务的SIMPLE(SIP即时消息收发和现场支持扩展)在IETF中作了定义。OMA(开放移动联盟)还基于SIP/SIMPLE协议而定义了IM(即时消息收发)作动器(enabler)。SIMPLE定义了两种模式的即时消息交换：寻呼模式和会话模式。寻呼模式使用SIP消息(SIPMESSAGE)方法，通过该方法来发送寻呼模式即时消息，并且其中，在协议层，后继即时消息与先前消息不相关：每个紧接的消息，甚至对之前消息的答复，都被认为是独立的事务。因此，SIPMESSAGE方法与传统的电子邮件和短消息服务类似。会话模式使用SIP用于信令和会话建立并使用MSRP(消息会话中继协议)用于在建立了会话之后承载一系列即时消息。下面，组合简单地被称为MSRP机制。换言之，MSRP机制提供聊天类型的消息收发，这被称为会话模式消息收发。

问题出现在当用户希望发送大型寻呼模式消息的时候。SIPMESSAGE方法可以使用UDP或TCP传输。TCP也为大型消息提供可靠的传输方法，但针对SIPMESSAGE方法TCP传输无法总是得以保证。如果使用UDP来发送大型消息，则大于UDP最大尺寸的分组被分段，并且可能无法按正确顺序到达接收方。此外，即使可以确保TCP，但仍然存在阻塞控制的其他有关问题。由于SIPMESSAGE方法是SIP会话控制信令的一部分，所以使用与SIP信令所用非常相同的资源来发送和接收消息。对于用户终端而言，这意味着可以在用户终端中对大型消息进行发送和接收的时间阻断实际的SIP信令。用于SIP信令的上述资源可以是通用PDP(分组数据协议)上下文，或者在GERAN(GSM/EDGE无线接入网络)和/或UTRAN(UMTS陆地无线接入网络)系统的情况下为专用信令PDP上下文。在其他系统中，例如，该资源可以是预留的和/或专用的带宽用于信令目的。除了SIP信令被阻断之外，加载SIP代理的其他有关问题可能出现。由于寻呼模式消息传统上使用SIPMESSAGE方法，所以使用SIPMESSAGE方法的所有消息通过SIP代理来传送。因此，通过SIP代理传送的大尺寸寻呼模式消息可以引起SIP代理性能的严重降低，从而导致有效地阻断所有SIP信令并降低SIP网络的整体性能。因此，在某些情况中，SIPMESSAGE方法不适合用于大尺寸消息。

一种解决方案是，当消息尺寸超过特定限制时，使用MSRP机制来代替SIPMESSAGE方法。然而，MSRP机制是针对会话模式消息收发服务，而不是针对寻呼模式消息收发的。此外，接收到的寻呼模式消息可以延迟并存储在消息收发收件箱中，从中用户可以在 方便的时候读取它们，但在会话模式消息收发中，接收到的消息由用户终端打开并展现给用户以方便进行对话。因此，从接收者的角度出发，当使用MSRP机制时不能接收寻呼模式消息。

发明内容

本发明的一个目的是提供方法和用于实现该方法的设备，从而克服上述问题。本发明的目的可以由在独立权利要求中声明的方法、用户终端和服务器来实现。在从属权利要求中公开了本发明的优选实施方式。

本发明是基于对该问题的认识，并解决该问题通过：指示使用的会话模式(聊天类型)消息收发机制发送的消息是否为寻呼模式消息，以及响应于该消息是寻呼模式消息，将其当作使用寻呼模式机制或根据为此寻呼模式机制所定义的特定指令而加以接收。通过会话模式意味着使用为进行系列消息交换而设计的协议，例如MSRP。通过寻呼模式意味着每个消息在协议层是独立事务，即在协议层，后续的即时消息与先前消息不相关。

本发明的一个有益效果在于通过使用该指示，即使当寻呼模式消息被作为会话模式消息来传送时也可以作为寻呼模式消息来接收。另一有益效果在于可以避免由于大型消息而带来SIP信令的阻断。

附图说明

下面，将参考附图并通过优选实施方式来更详细地描述本发明，附图中：

图1示出了简化的系统框架；

图2是图示了在发送模式中根据本发明实施方式的用户终端的功能性的流程图；

图3和图4是图示了在接收模式中根据本发明实施方式的用户终端的功能性的流程图；

图5A至图5D图示了根据本发明实施方式的SIP邀请(SIPINVITE)消息的例子；以及

图6、图7、图8和图9图示了根据本发明实施方式的信令。

具体实施方式

以下实施方式仅是示例性的。尽管本说明书可能在多个位置使用“一种”、“一个”或“一些”实施方式，但这并不必然意味着每个此类参考是相同的实施方式，或者该特征仅应用于单个实施方式。不同实施方式的单个特征也可以结合起来提供其他实施方式。

本发明可应用于任何用户终端、服务器和/或任何通信系统或应用于可由用户终端接入并提供消息收发服务的不同通信系统的任意组合，消息收发服务即以消息格式将数据从一个实体向另一实体近乎实时地发送或发送到邮件箱。对消息格式以及数据类型而言不存在限制。该数据可以是文本、语音、视频剪辑、多媒体等等。通信系统可以是固定通信系统或无线通信系统或使用固定网络和无线网络二者的通信系统。所使用的协议、通信系统和终端的规范发展迅速，特别是在无线通信中。此发展可能要求对本发明的额外变化。因此，所有的词汇和表达应当做宽泛解释并且旨在示意而非限制本发明。

下面，将使用采用SIP和MSRP的简化系统环境作为本发明可应用的系统环境的例子来解释本发明，而不对本发明构成限制。应当意识到，通信系统和例如代理的中间节点以及SIP和MSRP下面或上面使用的其他协议或相应协议与实际发明无关。因此，这里将不需要进行详细讨论。本发明主要涉及应用层中的消息传送。

图1是高度简化的系统架构，其仅示出了通信系统1、两个用户终端UT2、UT2’和网络3。对于本领域技术人员而言明显的是，系统还包括其他设备、系统实体例如即时消息收发服务器、功能和结构，这里不需要进行详细描述。

用户终端2、2’ 一件装备或设备，其允许用户直接或经由计算 机系统与通信系统进行交互，即，其向用户提供信息并允许用户输入信息，即用户终端是特定通信的终结点。换言之，用户终端2、2’可以是任何节点或支持消息收发并且如果接入网络存在则能够在该接入网络(在图1中未示出)上与系统网络进行通信的主机。用户终端2、2’可以是无线地或经由固定连接而连接到网络3的非移动设备，例如个人计算机PC。用户终端2、2’还可以是支持消息收发的无线移动终端，充当服务平台并支持不同的服务有关功能的加载和执行的多服务终端，或经由可能的接入网络可连接到网络的膝上型PC，经由可能的接入网络可连接到网络的个人数字助理PDA等等。

用户终端2包括至少一个用户接口(UI)21，通过该接口，用户可以创建和/或读取消息；一个或多个消息收发应用(Appl)22；存储器(Mem)23(或者用户终端设置为可访问存储器)，用于至少临时地存储接收到的寻呼模式类型的消息；以及收发器(TRx)24，用于发送和接收通信(消息)。

消息收发应用22可以是软件应用，配置为实现根据本发明的功能。该功能例如可以通过更新相应的消息收发应用或通过向终端添加新的消息收发应用来实现。

图2是图示了在发送模式中根据本发明实施方式的用户终端的功能的流程图。在图2的例子中，假设用户总是以类似的方式创建寻呼模式消息，并且假设用户终端选择与该消息一起使用的方法/机制。

图2开始于用户创建了寻呼模式消息并经由用户接口给出指令以发送消息到接收器(步骤201)。换言之，在步骤201，用户终端接收“向该地址发送消息”命令。响应于该命令，在步骤202，用户终端确定该消息的尺寸，并且在步骤203，检查该消息尺寸是否大于针对该尺寸的预定限制。该预定限制可以例如由所使用的服务协议来定义，由用户或运营商来定义，或者其可以预配置到终端。优选地，该预定限制对应于适合于传输协议消息的尺寸。然而，预定限制的值以及设置预定限制的方式对本发明没有显著的影响。在本发 明的某些实施方式中，甚至可以的是，所有的寻呼模式消息无论其尺寸如何，都使用MSRP机制或相应机制来发送。例如，用户终端可以被预先配置为总是使用会话模式，因为运营商不允许使用寻呼模式。

如果消息尺寸不超过该限制(步骤203)，那么在步骤204，用户终端使用SIPMESSAGE方法来发送内容。

如果消息尺寸确实超过该限制(步骤203)，那么在步骤205，根据本发明，用户终端使用MSRP机制来发送具有寻呼模式指示符的消息。根据该实现，用户终端可以或者可以不向由MSRP发送的寻呼模式消息添加关于消息的实际尺寸的信息。实际消息发送过程在图6、图7和图8中有更详细的图示。

在本发明的一个实施方式中，用户必须从三个选项中进行选择：小型寻呼模式消息(尺寸小于或等于预定限制)、其他寻呼模式消息、会话(聊天)消息收发，并且当用户选择其他寻呼模式消息时，则在发送消息的时候使用具有寻呼模式指示符的会话模式消息收发机制。

图3是图示了在接收模式中根据本发明实施方式的用户终端的功能的流程图。在图3的例子中，假设不传送关于消息的实际尺寸的信息。为简明起见，进一步假设用户终端具有足够的用于消息的自由存储器，从而可以接收消息，并且假设用户终端被配置为接受寻呼模式消息。当该消息大于自由存储器时，所发生的事与本发明无关；这依赖于接收终端的实现；例如，如果不存在足够的自由存储器，则终端可以拒绝该会话请求，或者当存储器满的时候，接受会话请求，但终止该会话。

响应于接收到SIPINVITE(MSRP)(步骤301)，在步骤302，用户终端检查该SIPINVITE(MSRP)是否针对寻呼模式消息。如果是，则在步骤303，用户终端建立会话；在步骤304，接收消息；在步骤305，存储该消息；以及，在步骤306，释放该会话。随后或同时，在步骤307，用户终端向用户指示已经接收到消息。然后用户 可以稍后读取该消息。换言之，用户终端向用户发挥作用，就像通过SIPMESSAGE方法接收到消息一样。

如果SIPINVITE(MSRP)用于聊天(即用于会话模式消息收发)，而不是用于寻呼模式消息(步骤302)，则在步骤308，用户终端建立会话并在步骤309显示对话，直到会话结束为止。

接收用户终端可以配置为拒绝所有寻呼模式消息，在此情况下，不建立会话，而是代替步骤303至步骤307，发送拒绝。

接收用户终端可以配置为将寻呼模式消息请求转发至网络收件箱或另一终端等，在此情况下，不建立会话，而是代替步骤303至步骤307，转发请求。此示例的例子示出在图7和图8中。即使将所有寻呼模式消息转发以存储到其他地方，并且用户需要通过另一终端察看它们，该转发终端仍被考虑为提供寻呼模式消息收发。

在本发明的另一实施方式中，在接收到消息之后执行检查(即在步骤304之后执行步骤302，并且在检查之后在步骤305或步骤308中该过程继续)。

图4是图示了在接收模式中根据本发明实施方式的用户终端的功能的流程图。在图4的例子中，假设存在关于消息的实际尺寸的信息。为简明起见，进一步假设(如结合图3所示，这里将没必要重复相同的解释)用户终端具有足够的用于消息的自由存储器，并且用户终端配置为接受寻呼模式消息。

响应于接收到SIPINVITE(MSRP)(步骤401)，在步骤402，用户终端检查该SIPINVITE(MSRP)是否针对寻呼模式消息。如果是，则在步骤403，用户终端向用户通知该消息的尺寸。如果用户接受了该消息(步骤404)，则在步骤405，用户终端建立会话；在步骤406，接收该消息；以及在步骤407，存储该消息。用户然后可以稍后读取该消息。接下来在步骤408，用户释放该会话。换言之，用户终端向用户发挥作用，就像通过SIPMESSAGE方法接收到消息一样。在此具体例子中，用户终端不向用户通知消息的接收，因为假设通过接受该消息递送，已经向用户通知了该消息。然而，在另 一实现中，用户设备可以配置为向用户通知该消息的接收。

如果用户未接受该消息(步骤404)，那么在步骤409，用户终端拒绝会话建立。在另一实施方式中，用户终端可以不拒绝，而是转发会话建立，从而该消息存储在网络中并且稍后可以被获取，如图7和图8所示。

如果SIPINVITE(MSRP)用于聊天(即用于会话模式消息收发)而不是用于寻呼模式消息(步骤402)，则在步骤410，用户终端建立会话，并在步骤411中显示对话，直到会话结束为止。

在本发明的另一实施方式中，代替询问用户是否接受了该消息(即代替步骤403)，用户终端配置为接受不超过预定尺寸限制的消息。该预定尺寸限制例如可以由运营商、用户终端制造商和/或用户来定义。

下面，将以图5A至图8中示出的一些例子来更详细地描述该信令，其使用SDP(会话描述协议)来发起通过TCP的会话和MSRP以传送实际的内容，而不将本发明限制于此例子。结合下列例子作出的另一假设是接收用户终端将不拒绝该消息。如果需要，可以在 http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-l0.txt中找到进一步的信息，其在此并入作为参考。然而，使用哪些协议对本发明没有影响，上述仅作为例子。例如，代替SDP，可以使用其他的提供回答机制协议，并且，代替TCP，可以使用其他阻塞控制协议，例如SCTP(信令公共传输协议)。

图5A至图5D图示了会话模式消息可以如何指示会话模式邀请是针对寻呼模式消息的一些例子。

在图5A的实施方式中，寻呼模式消息由包含新寻呼模式指示符5-1的m行(m＝message9msrppage-mode)和指示消息5-2的实际尺寸(a＝max-size:actualsize)的参数a＝max-size的组合来指示。

在图5B的实施方式中，寻呼模式消息由包含新寻呼模式指示符5-1的m行(m＝message9msrppage-mode)和指示消息的实际尺寸(a＝max-size:actualsize)的参数5-3a＝max-size的组合来指示。在 此实施方式中，参数a＝max-size指示消息的最大尺寸。

在图5C的实施方式中，寻呼模式消息由参数5-3a＝actual-size来指示。当参数的值不同于0的时候，其隐性地指示该消息是寻呼模式消息，反之亦然。在此实施方式中，m行信息指示将使用MSRP，并且参数a＝max-size指示消息的最大尺寸。

在图5D的实施方式中，寻呼模式消息由包含新寻呼模式指示符5-1(m＝message9msrppage-mode)的m行来指示。在此实施方式中，参数a＝max-size指示消息的最大尺寸，而不需要附加的a参数。

在图6的信令图中，尽管可以涉及一个或多个居间体，但仅示出了端点之间的信令。图6图示了当接收方，或更具体而言是接收方用户终端的相应客户端，接受了消息时的信令。图6开始于Alice希望向Bob发送消息。Alice的用户终端UT1(更具体地，是UT1中的相应客户端)在点6-1注意到必须使用会话模式机制来发送寻呼模式消息。(点6-1在图2中进行了详细描述)。因此，UT1向Bob的用户终端UT2发送具有寻呼模式指示PMI的会话邀请消息6-2。消息6-2优选地是图5A至图5D中所示消息的其中之一。响应于接收到消息6-2，UT2在点6-3检测消息是针对寻呼模式消息的会话模式邀请，并通过发送消息6-4来接受该邀请。UT1通过发送消息6-5来应答该接受，然后UT1在会话模式消息6-6中发送寻呼模式消息的实际内容。响应于接收到该内容，UT2在点6-7存储该内容，从而Bob可以稍后对其进行浏览。UT2还可以通知Bob，如图3和图4所述。响应于接收到该内容，UT2还通过在消息6-8中发送会话模式应答来应答该接收。在图6所示的实施方式中，发送用户终端UT1配置为通过向UT2发送消息6-9的应答而响应于该应答终止该会话，UT2然后发送消息6-10以应答该终止。

在图7的信令图中，示出了经由接收端点的参与即时消息收发服务器的端点之间的信令，尽管可以涉及一个或多个居间实体。图7图示了当接收方(或更具体地是接收方的用户终端内的相应客户端)不接受该消息而是请求网络保存该消息以供后续获取时的信令。图7开始于Alice希望向Bob发送消息。Alice的用户终端UT1(更具体地，是UT1中的相应客户端)在点7-1注意到必须使用会话模式机制来发送寻呼模式消息。(点7-1在图2中进行了详细描述)。因此，UT1经由服务器向Bob的用户终端UT2发送具有寻呼模式指示PMI的会话邀请消息7-2。消息7-2优选地是图5A至图5D中所示消息的其中之一。响应于接收到消息7-2，UT2在点7-3检测消息是针对寻呼模式消息的会话模式邀请。由于某些原因，UT2不接受该寻呼模式消息，而是向服务器发送重定向消息7-4。重定向消息的一个例子是SIP302“MovedTemporarily(临时移动)”消息，其可以包含关于如何对待消息的信息。然而，如何以及通过哪些协议来实现重定向与本发明是无关的，并且在必要的时候给出附加指令/信息。其他例子包括采用使用了SIP协议的单独事务，例如SIPPUBLISH、SIPOPTIONS、所谓的SIPREGISTER中的功能，或具有XCAP(可扩展标记语言配置访问协议)。UT2还可以向Bob通知该消息，如以上结合图3和图4所述。

在此例子中，服务器(或更具体地是背对背用户代理)接受以提供可选的服务，并且因此服务器假设其自身为会话端点并通过发送消息7-5来接受初始邀请。UT1通过向该服务器发送消息7-6来应答该接受，然后在会话模式消息7-7中向服务器发送寻呼模式消息的实际内容。响应于接收到该内容，服务器在点7-8中存储该内容从而Bob可以在稍后浏览它们。响应于接收到该内容，服务器还通过在消息7-9中发送会话模式应答来应答该接收。在图7所示的实施方式中，发送用户终端UT1配置为通过发送消息7-10到服务器响应于应答来终止该会话，该服务器然后发送消息7-11以应答该终止。Bob然后可以稍后查看消息内容，但该查看的实现与本发明无关，因此在这里将不作详细讨论。

在图8的信令图中，和图7中一样，示出了经由接收端点的参与即时消息收发服务器的端点之间的信令，尽管可以涉及一个或多个居间实体。图8图示了当接收方(或更具体地是接收方的用户终 端内的相应客户端)不接受该消息而是请求网络中的网关GW保存该消息以供后续获取时的信令。图8开始于Alice希望向Bob发送消息。Alice的用户终端UT1(更具体地，是UT1中的相应客户端)在点8-1注意到必须使用会话模式机制来发送寻呼模式消息。(点8-1在图2中进行了详细描述)。因此，UT1经由服务器向Bob的用户终端UT2发送具有寻呼模式指示PMI的会话邀请消息8-2。消息8-2优选地是图5A至图5D中所示消息的其中之一。响应于接收到消息8-2，UT2在点8-3检测消息是针对寻呼模式消息的会话模式邀请。由于某些原因，UT2不接受该寻呼模式消息，而是向服务器发送重定向消息8-4，该重定向消息指示应当将消息转发至网关GW。(在上面结合图7描述了重定向消息)。UT2还可以向Bob通知该消息，如以上结合图3和图4所述。

在此例子中，服务器(更具体地是背对背用户代理)生成针对消息8-4中所指示的GW的URI(统一资源标识符)的新请求，并在消息8-5中发送该请求。该请求优选地是没有寻呼模式指示的会话模式邀请。GW通过发送消息8-6来接受该初始邀请。UT1通过向GW发送消息8-7来应答该接受，然后在会话模式消息8-8中向GW发送该寻呼模式消息的实际内容。响应于接收到该内容，GW在点8-9存储该内容从而Bob可以在稍后浏览它们。响应于接收到该内容，GW还通过在消息8-10中发送会话模式应答来应答该接收。在结合图8所示的实施方式中，发送用户终端UTl配置为通过发送消息8-11到GW响应于应答来终止该会话，该GW然后发送消息8-12以应答该终止。Bob然后可以稍后查看消息内容，但该查看的实现与本发明无关，因此在这里将不作详细讨论。

图9图示了根据本发明进一步实施方式的信令，在该实施方式中，即时消息收发服务器也被配置为检测指示。该即时消息收发服务器可以是单独的服务器，或者是包括一个或多个其他组件的网络节点中的服务器组件。在图9所示的例子中，假设接收方(UT2)是不可到达的，或者具有一种这样的配置，根据该配置接收方的寻 呼模式消息将存储在接收方的网络收件箱中，在此例子中位于服务器中。这也可以是网络配置。在图9的信令图中，示出了发送端点UT1和接收端点的参与即时消息收发服务器之间的信令，尽管可以涉及一个或多个居间实体。图9开始于Alice希望向Bob发送消息。Alice的用户终端UT1(更具体地，是UT1中的相应客户端)在点9-1注意到必须使用会话模式机制来发送寻呼模式消息。(点9-1在图2中进行了详细描述)。因此，UT1经由服务器向Bob的用户终端UT2发送具有寻呼模式指示PMI的会话邀请消息9-2。消息9-2优选地是图5A至图5D中所示消息的其中之一。响应于接收到消息9-2，服务器(更具体地为背对背用户代理)在点9-3检测消息是针对寻呼模式消息的会话模式邀请，因此检查Bob即UT2的用于寻呼模式消息的配置。由于该配置示出了寻呼模式消息将要被存储以供后续获取，所以服务器假设其自身为会话端点并通过发送消息9-4来接受该邀请。UT1通过向服务器发送消息9-5来应答该接受，然后在会话模式消息9-6中向服务器发寻呼模式消息的实际内容。响应于接收到该内容，服务器在点9-7存储该内容，从而Bob可以稍后浏览它们。在本发明的某些其他实施方式中，该消息可以存储在另一网络节点或远程数据库中，或转发至网关。响应于接收到该内容，服务器还通过在消息9-8中发送会话模式应答来应答该接收。在结合图9所示出的实施方式中，发送用户终端UT1配置为通过发送消息9-9至服务器响应于应答来终止该会话，该服务器然后发送消息9-10以应答该终止。Bob然后可以查看该消息内容，但该查看的实现与本发发明无关，因此在这里将不作详细讨论。

在本发明的另一实施方式中，接收方的即时消息收发服务器设置为判别是否转发会话请求或基于消息尺寸、接收方的终端功能和/或网络负载将其自身假设为端点。

在基于图9的又一实施方式中，用户可以具有这样的配置，根据该配置，使用会话模式机制传送的寻呼模式消息存储在网络收件箱中并且仅通知给用户，而使用寻呼模式机制传送的寻呼模式消息 被转发给用户。

在图2、3、4、6、7、8和9中示出的步骤、点和信令消息并非绝对按时间顺序排列，并且其中的某些步骤/点可以同时执行或以与给定顺序不同的顺序来执行。还可以在步骤/点之间或在步骤/点中执行其他功能。还可以省去某些步骤/点或部分步骤/点。信令消息仅是示例性的，并且甚至可以包括若干单独的消息用于传送相同的信息。此外，该消息可以包含其他信息。这些消息和步骤/点也可以自由组合或划分为若干部分。而且，消息的名称、类型和/或内容以及所使用的协议可以与上面提到的有所不同。

在上面，尽管本发明的公开假设了通信即文件传送和呼叫是一对一的通信，但对于本领域技术人员很明显的是，该通信也可以是一对多通信。

上面所提供的实施方式及其一部分可以组合起来以产生本发明的优选实施方式。

实现本发明功能的用户终端、其他对应设备和/或服务器或对应服务器组件实现不但包括现有技术的装置，而且还包括用于以上述方式来发送和/或接收寻呼模式消息的装置。当前的网络节点和用户终端包括处理器和存储器，其可以在根据本发明的功能中使用。实现本发明所需的所有修改和配置可以作为例程来执行，其可以实施为附加的或更新的软件例程、应用电路(ASIC)和/或可编程电路。

对于本领域技术人员明显的是，随着技术进步，可以以各种方式来实现本发明的概念。本发明及其实施方式不限于上述公开的例子，而是可以在权利要求书的范围内变化。

Claims (54)

1.一种用于发送寻呼模式消息的方法，所述方法包括：

由一个设备使用会话模式消息机制发送具有指示的所述寻呼模式消息，所述指示表明所述会话模式是用于所述寻呼模式消息的；

建立会话以用于通过消息会话中继协议来承载所述寻呼模式消息，

其中所述设备响应于所述寻呼模式消息的大小超过预定限制而发送所述寻呼模式消息。

2.根据权利要求1所述的方法，进一步包括：

使用会话发起协议创建所述会话。

3.根据权利要求2所述的方法，进一步包括：

由所述设备发送邀请消息，其中表明所述消息为寻呼模式消息的所述指示被插入所述邀请消息的报头中。

4.根据权利要求3所述的方法，其中所述邀请消息是具有提供的请求消息。

5.根据权利要求4所述的方法，其中所述提供是会话描述协议提供。

6.根据权利要求3所述的方法，进一步包括：

接收针对所述邀请消息的响应，其中所述响应是200OK消息。

7.根据权利要求6所述的方法，其中所述响应是应答。

8.根据权利要求7所述的方法，其中所述应答是会话描述协议应答。

9.根据权利要求1所述的方法，进一步包括：

由所述设备在会话模式消息中发送所述寻呼模式消息的内容。

10.根据权利要求1所述的方法，进一步包括：

将所述会话建立为非聊天会话。

11.根据权利要求1所述的方法，其中所述会话在消息递送完成之后被释放。

12.根据权利要求11所述的方法，进一步包括：

发送SIPBYE请求以终止会话。

13.根据权利要求12所述的方法，进一步包括：

在接收到对所述SIPBYE的响应之后释放所述会话。

14.一种用于发送寻呼模式消息的设备，包括：

至少一个处理器；以及

至少一个存储器，包括一个或多个程序的计算机程序代码，所述至少一个处理器、所述至少一个存储器以及所述计算机程序代码被配置为使所述设备至少：

使用会话模式消息机制发送具有指示的寻呼模式消息，所述指示表明所述会话模式是用于所述寻呼模式消息的；

建立会话以用于通过消息会话中继协议来承载所述寻呼模式消息，

其中所述设备响应于所述寻呼模式消息的大小超过预定限制而发送所述寻呼模式消息。

15.根据权利要求14所述的设备，进一步包括：

使用会话发起协议创建所述会话。

16.根据权利要求15所述的设备，进一步包括：

发送邀请消息，其中表明所述消息为寻呼模式消息的所述指示被插入所述邀请消息的报头中。

17.根据权利要求16所述的设备，其中所述邀请消息是具有提供的请求消息。

18.根据权利要求17所述的设备，其中所述提供是会话描述协议提供。

19.根据权利要求16所述的设备，进一步包括：

接收针对所述邀请消息的响应，其中所述响应是200OK消息。

20.根据权利要求19所述的设备，其中所述响应是应答。

21.根据权利要求20所述的设备，其中所述应答是会话描述协议应答。

22.根据权利要求14所述的设备，进一步包括：

在会话模式消息中发送所述寻呼模式消息的内容。

23.根据权利要求15所述的设备，进一步包括：

将所述会话建立为非聊天会话。

24.根据权利要求14所述的设备，其中所述会话在消息递送完成之后被释放。

25.根据权利要求24所述的设备，进一步包括：

发送SIPBYE请求以终止会话。

26.根据权利要求25所述的设备，进一步包括：

在接收到对所述SIPBYE的响应之后释放所述会话。

27.一种用于接收寻呼模式消息的方法，所述方法包括：

由一个设备接收会话模式请求消息；

验证包括指示的所述会话模式请求消息，所述指示表明会话模式是用于所述寻呼模式消息的；

建立会话以接收所述寻呼模式消息，或者拒绝所述请求，

其中所述寻呼模式消息是大小超过预定限制的大尺寸消息。

28.根据权利要求27所述的方法，进一步包括：

由于资源不足而拒绝所述请求。

29.根据权利要求27所述的方法，进一步包括：

发送响应于所述请求的响应消息。

30.根据权利要求29所述的方法，其中所述响应消息是200OK消息。

31.根据权利要求29所述的方法，其中所述响应是会话描述协议应答。

32.根据权利要求27所述的方法，其中所述会话模式请求消息是邀请消息。

33.根据权利要求32所述的方法，进一步包括：接收会话描述协议提供。

34.根据权利要求27所述的方法，进一步包括：在所述会话期间接收所述寻呼模式消息的内容。

35.根据权利要求34所述的方法，其中所述内容被插入会话模式消息的报头。

36.根据权利要求35所述的方法，其中所述会话模式消息是消息会话中继协议消息。

37.根据权利要求36所述的方法，进一步包括：发送响应消息确认接收到所述消息会话中继协议消息，其中所述响应消息是200OK消息。

38.根据权利要求27所述的方法，进一步包括：建立非聊天会话。

39.根据权利要求27所述的方法，进一步包括：在接收到释放请求消息之后释放所述会话。

40.根据权利要求39所述的方法，进一步包括：发送200OK消息以释放所述会话。

41.一种用于接收寻呼模式消息的设备，包括：

至少一个处理器；以及

至少一个存储器，包括一个或多个程序的计算机程序代码，所述至少一个处理器、所述至少一个存储器以及所述计算机程序代码被配置为使所述设备至少：

接收会话模式请求消息；

验证包括指示的所述会话模式请求消息，所述指示表明会话模式是用于所述寻呼模式消息的；

建立会话以接收所述寻呼模式消息，或者拒绝所述请求，

其中所述寻呼模式消息是大小超过预定限制的大尺寸消息。

42.根据权利要求41所述的设备，进一步包括：

由于资源不足而拒绝所述请求。

43.根据权利要求41所述的设备，进一步包括：

发送响应于所述请求的响应消息。

44.根据权利要求43所述的设备，其中所述响应消息是200OK消息。

45.根据权利要求43所述的设备，其中所述响应是会话描述协议应答。

46.根据权利要求41所述的设备，其中所述会话模式请求消息是邀请消息。

47.根据权利要求46所述的设备，进一步包括：接收会话描述协议提供。

48.根据权利要求41所述的设备，进一步包括：在所述会话期间接收所述寻呼模式消息的内容。

49.根据权利要求48所述的设备，其中所述内容被插入会话模式消息的报头。

50.根据权利要求49所述的设备，其中所述会话模式消息是消息会话中继协议消息。

51.根据权利要求49所述的设备，进一步包括：发送响应确认接收到所述会话模式消息，其中所述响应消息是200OK消息。

52.根据权利要求41所述的设备，进一步包括：建立非聊天会话。

53.根据权利要求41所述的设备，进一步包括：在接收到释放请求消息之后释放所述会话。

54.根据权利要求53所述的设备，进一步包括：发送200OK消息并且释放所述会话。