CN101321135A - 一种处理呼叫模式消息的方法和用户代理 - Google Patents
一种处理呼叫模式消息的方法和用户代理 Download PDFInfo
- Publication number
- CN101321135A CN101321135A CNA2007100747378A CN200710074737A CN101321135A CN 101321135 A CN101321135 A CN 101321135A CN A2007100747378 A CNA2007100747378 A CN A2007100747378A CN 200710074737 A CN200710074737 A CN 200710074737A CN 101321135 A CN101321135 A CN 101321135A
- Authority
- CN
- China
- Prior art keywords
- message
- call mode
- user agent
- mode message
- replacement
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种处理呼叫模式消息的方法,包括步骤:第二用户代理接收到第一用户代理发送的第一呼叫模式消息,第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息,第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理。进一步在进行替换处理后,还可以返回替换处理结果通知。
Description
技术领域
本发明涉及通信领域的会话初始协议SIP(Session Initiation Protocol),尤其涉及会话初始协议的呼叫模式消息MESSAGE。
背景技术
目前的会话初始协议(SIP:Session Initiation Protocol)的呼叫模式(pagermodel)消息即MESSAGE方法主要用来实现发送即时消息,具体可参见相应的规范RFC3428。典型的MESSAGE消息流程如图1所示,主要包括如下步骤:
步骤101.发送方即第一用户代理UA1发送MESSAGE消息;
步骤102.代理服务器PROXY将该MESSAGE消息转发给接收方即第二用户代理UA2;
步骤103.第二用户代理UA2返回200 OK响应;
步骤104.代理服务器PROXY将该200 OK响应转发给第一用户代理UA1。
MESSAGE消息并没有在发送方和接收方之间建立任何会话,所以也被称为呼叫模式(pager model)消息或寻呼消息。目前用户在发送MESSAGE消息后,如果发现发错了内容或发错了对象,则无法召回已经发送的MESSAGE消息。另外有时候用户或业务服务器希望用一个包含更新内容的消息去替换先前已经发送的消息,如更新消息中指示的某个约会的时间和地点,使接收方不必阅读先前的那个消息,这也都无法实现。
发明内容
本发明要解决的技术问题在于提出了一种处理呼叫模式消息的方法,能够更新或召回先前已经发出的呼叫模式消息。
本发明还提出了一种替换即时消息的方法,使用户能够替换先前已经发出的即时消息。
本发明还提出了一种用户代理,能够更新或删除先前的呼叫模式消息。
为解决上述问题,本发明提出的技术方案如下:
一种处理呼叫模式消息的方法,该方法包括步骤:
第二用户代理接收到第一用户代理发送的第一呼叫模式消息;
第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息;
第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理。
一种替换即时消息的方法,包括步骤:
发送第一即时消息,并在通用呈现和即时消息内容中包含消息标识;
发送包含替换第一即时消息指示信息的第二即时消息,所述的指示信息包含对应第一即时消息的消息标识;
根据所述的指示信息将消息标识相匹配的第一即时消息进行替换处理。
一种用户代理,包括:
传输处理模块,用于接收消息处理模块发来的会话初始协议消息,并采用相应的承载协议将其发送出去;
消息处理模块,用于对会话初始协议消息进行编解码和事务控制;
替换处理模块,用于与消息处理模块交互处理与替换处理相关的消息。
本发明的有益效果如下:
本发明通过在用户代理发送的呼叫模式消息中包含替换先前呼叫模式消息指示信息,利用所采用的替换指示信息可以使一个接收方的用户代理唯一确定一个先前的呼叫模式消息,从而接收方的用户代理可以根据所述的指示信息进行替换处理。另外本发明在进行替换处理后,还可以向发送方返回替换处理结果通知。还通过对群发消息的替换消息进行适当转换后进行替换处理,使之能替换部分或全部接收方先前收到的消息。还通过在通用呈现和即时消息格式中包含替换指示信息,使之能在使用不同即时消息传输协议的网络之间进行消息的替换。
附图说明
图1为现有技术中发送MESSAGE消息的基本消息交互流程图,
图2为本发明第一实施例替换MESSAGE消息的基本流程图,
图3为本发明第三实施例替换群发MESSAGE消息的基本流程图,
图4为本发明用户代理的内部模块示意图。
具体实施方式
本发明的第一实施例描述了如何替换一个MESSAGE消息。如图2所示,主要包括如下步骤:
步骤201.第二用户代理UA2接收到第一用户代理UA1发送的第一呼叫模式消息。第二用户代理UA2可以是最终的接收方,一般位于用户终端如手机或个人计算机中,最终的接收方收到MESSAGE消息一般立即返回200 OK响应。第二用户代理UA2也可以是网络侧的存储转发服务器(Message Relay),收到MESSAGE消息后如果不能立即传送给最终的接收方,则对该消息进行缓存后续再发送,同时向发送方即第一用户代理UA1返回202 Accepted响应。第一呼叫模式消息的内容举例如下:
MESSAGE sip:user2@domain.com SIP/2.0
From:sip:user1@domain.com;tag=49583
To:sip:user2@domain.com
Call-ID:asd88asd77a@1.2.3.4
CSeq:1MESSAGE
Content-Type:text/plain
Content-Length:18
Watson,come here.
为简明起见省略了部分消息内容。其中该消息起始行中的请求地址(Request URI)即最终接收方的地址为“sip:user2@domain.com”。From头字段中的地址为发送方的逻辑地址,To头字段中的地址为最终接收方的逻辑地址,Call-ID头字段中为对话号,CSeq头字段为本对话中发送MESSAGE消息的序号值。另外在SIP消息的发送方地址From和接收方地址To头字段中还可以包含全局唯一的标签(tag),与对话号Call-ID共同唯一确定一个对话,具体可参见IETF(Internet Engineering Task Force)规范RFC3261。本发明中充分利用了综合以上现有的几个字段中的信息可以唯一确定一个呼叫模式消息的特性。消息体的内容为内容类型Content-Type为纯文本“text/plain”的一段文字。
步骤202.第一用户代理UA1发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息,可称为替换消息。例如当用户发现发错了消息内容后,希望再发送一个MESSAGE消息替换先前的MESSAGE消息,以免最终接收方错误使用先前的消息内容。则替换消息即第二呼叫模式消息的内容举例如下:
MESSAGE sip:user2@domain.com SIP/2.0
From:sip:user1@domain.com;tag=53568
To:sip:user2@domain.com
Call-ID:fgh11qwe22s@1.2.3.4
CSeq:1MESSAGE
Replaces:asd88asd77a@1.2.3.4;to-tag=0;from-tag=49583
Content-Type:text/plain
Content-Length:31
Watson,I am coming to see you.
其中在替换头字段Replaces中包含第一呼叫模式消息的对话号Call-ID,如上述的“asd88asd77a@1.2.3.4”,以及第一呼叫模式消息的From和To头字段中的标签,即from-tag=49583和to-tag=0,其中替换头字段Replaces中的标签为0时可以匹配0或空(null)的From和To头字段中的标签值。From和To头字段中的逻辑地址与第一呼叫模式消息相同。
另外替换头字段Replaces中的to-tag值也可以从对第一呼叫模式消息返回的200 OK或202 Accepted响应的To字段中获得。因为第一呼叫模式消息中的To头字段中的标签可能没有对应的值,如果对该第一呼叫模式消息返回的响应里To字段有标签值,则第二呼叫模式消息中可以使用该值作为to-tag值。当接收者的逻辑地址对应注册有多个物理地址时,第一呼叫模式消息可能会被分叉,每个物理地址对应的用户代理都会返回相应的200 OK等响应,而且其中的To头字段中的标签各不相同。
如果对应同一个对话发送了多个MESSAGE消息,则在替换消息的指示信息中还可以包括要替换的消息对应的序列号,以替换某个特定的MESSAGE消息。如第一呼叫模式消息部分内容为:
MESSAGE sip:user2@domain.com SIP/2.0
From:sip:user1@domain.com;tag=49583
To:sip:user2@domain.com;tag=92321
Call-ID:asd88asd77a@1.2.3.4
CSeq:3MESSAGE
则第二呼叫模式消息中包含替换指示信息的头字段Replaces内容如下:
Replaces:asd88asd77a@1.2.3.4;to-tag=92321;from-tag=49583;id=3
其中序号标识参数id中的值与第一呼叫模式消息中的CSeq头字段中序列号值相同。
步骤203.第二用户代理UA2根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理。
第二用户代理UA2收到第二呼叫模式消息后,可以立即返回200 OK或202Accepted响应,告知第一用户代理UA1已经成功收到该消息,但这并不表示替换成功。第二用户代理UA2根据第二呼叫模式消息中的头字段Replaces中的指示信息确定匹配的消息,并对匹配的消息进行替换处理。如可以直接删除匹配的消息,或者当用户浏览或打开上述匹配的消息时,提示用户该消息已经被第二呼叫模式消息所替换了,或者当用户浏览或阅读第二呼叫模式消息,同时显示所替换的第一呼叫模式消息。如果第二用户代理根据第二呼叫模式消息中的头字段Replaces中的指示信息匹配到不止一个消息,则最好当作没有发现匹配的消息的进行处理。
如果第一用户代理UA1希望的替换处理是召回第一呼叫模式消息,即删除第一呼叫模式消息的同时,也不保留第二呼叫模式消息,则可以在步骤202中发送的第二呼叫模式消息中指定替换处理的具体方式,这时的第二呼叫模式消息可以称为召回消息,是一种特殊的替换消息。如在头字段Replaces中指定替换处理的具体方式为召回:
Replaces:asd88asd77a@1.2.3.4;to-tag=92321;from-tag=49583;id=3;recall
或,Replaces:asd88asd77a@1.2.3.4;to-tag=92321;from-tag=49583;id=3;usage=recall
第二用户代理UA2检测到第二呼叫模式消息中包含召回的替换处理的具体方式时,则同时删除其所匹配的消息即第一呼叫模式消息和第二呼叫模式消息。缺省的替换处理方式为替换更新,即表示要用第二呼叫模式消息去更新第一呼叫模式消息。
另外由于MESSAGE消息有时会被缓存在网络侧的服务器中进行存储转发,可能无法确定作为最终接收用户的第二用户代理UA2会先收到原始的第一呼叫模式消息,还是替换消息即第二呼叫模式消息。如果先收到第二呼叫模式消息,则第二用户代理UA2以后再收到原始的第一呼叫模式消息时,可以直接抛弃掉第一呼叫模式消息。
第二实施例描述使用通用呈现和即时消息CPIM(Common Presence andInstant Messaging)格式作为消息体内容的情况,以及发送替换消息的用户如何获知是否替换成功。第一用户代理UA1在发送的替换消息中包含要获取替换处理通知的指示,具体可以采用即使消息处理通知IMDN(InstantMessage Disposition Notification)的方式,假定第一呼叫模式消息包含的CPIM消息体中的消息标识如IMDN消息标识为“23gh123k”,部分内容举例如下:
MESSAGE sip:user2@domain.com SIP/2.0
Content-Type:Message/CPIM
NS:imdn<urn:ietf:params:imdn>
imdn.Message-ID:23gh123k
imdn.Disposition-Notification:read
IMDN消息标识是为了发送方匹配处理通知用的,除了采用IMDN消息标识外还可以设置专用的CPIM消息标识头字段如“Msg-ID”来唯一确定一个发送的CPIM消息。另外希望在接收方在阅读该消息后返回即时消息阅读处理通知,即处理通知头字段imdn.Disposition-Notification包含阅读通知指示“read”。通常当发送方在没有收到阅读通知时可以发送替换消息尤其是召回消息,因为接收方如果已经阅读了一般就没有必要召回了。则替换消息即第二呼叫模式消息的CPIM消息体中的替换头字段Replaces中包含相应的消息标识,替换消息部分内容举例如下:
MESSAGE sip:user2@domain.com SIP/2.0
Content-Type:Message/CPIM
Replaces:imdn-id=23gh123k
NS:imdn<urn:ietf:params:imdn>
imdn.Message-ID:34jk324j
imdn.Disposition-Notification:replace
注意此处的替换头字段Replaces为CPIM消息体内容的头字段,而不是MESSAGE消息的头字段。在CPIM的处理通知imdn.Disposition-Notification头字段中包含要获取替换处理通知的指示如“replace”,如果不需要获知处理结果,也可以不必在CPIM消息体中包含IMDN的各头字段。关于CPIM格式具体可以参见规范FRC3862,采用CPIM可以使即时消息通信具有更好的互通性。另外CPIM消息体不一定是用SIP MESSAGE消息来承载,还可以采用其他协议如HTTP、SMTP等协议。本实施例给出替换方法可以适用于任何使用CPIM的消息传送业务中,尤其是即时消息业务中。使用CPIM消息的好处是利于不同网络之间进行即时消息的互通,即使不同网络将承载即时消息的协议不同,只要消息体中都使用CPIM格式,则在网络之间的网关很容易进行转换。
第二用户代理UA2根据第二呼叫模式消息中的头字段Replaces中的指示信息即IMDN的消息标识确定所匹配的消息,在imdn.Message-ID头字段中具有相同消息标识的消息即为匹配的消息,并对匹配的消息进行替换处理。当然在CPIM消息体的替换头字段Replaces还可以包含替换处理的具体方式如召回用法:
Replaces:imdn-id=23gh123k;usage=recall
另外还可以在CPIM消息体的内容处理方式Content-Disposition头字段中包含替换指示信息,举例如下:
Content-Type:Message/CPIM
Content-Disposition:recall;msgid=23gh123k
其中替换指示信息中具体的替换方式如“recall”表示召回CPIM消息,或“replace”表示更新CPIM消息,要替换的消息可以由消息标识参数如“message-id”唯一确定,先前的要进行替换的消息在CPIM消息头字段包含有消息标识头字段或IMDN的消息标识头字段。
第二用户代理UA2在进行替换处理后还可以向第一用户代理UA1返回替换处理的结果。其处理结果包含在一个IMDN消息体中发送给第一用户代理UA1,该消息的部分内容举例如下:
Content-type:message/imdn+xml
Content-Disposition:notification
<?xml version=″1.0″encoding=″UTF-8″?>
<imdn xlmns=″urn:ietf:params:xml:ns:imdn″>
<message-id>34jk324j</message-id>
<disposition><replace/></disposition>
<status><replaced/></status>
</imdn>
此处可以采用MESSAGE消息承载IMDN消息体,其中消息体和消息头的一些内容为简明起见进行了适当省略。在内容类型Content-type为“message/imdn+xml”的IMDN消息体中的<message-id>元素的值与替换消息头字段imdn.Message-ID相匹配,并且通过处理<disposition>和状态<status>元素指明替换处理的状态为已经替换成功。如果是召回处理成功则返回的状态可以为:<status><recalled/></status>;如果没有发现匹配的消息,则返回的状态可以为:<status><notfound/></status>;如果第二用户代理禁止替换,则返回的状态可以为:<status><forbidden/></status>;其他错误可以返回状态:<status><error/></status>。另外IMDN消息体中还可以包含发送方和接收方的身份标识如SIP URI,以及替换消息的时间和备注等。
第三实施例描述如何替换群发的呼叫模式消息。如图3所示,包括步骤:
步骤301.第一用户代理UA1向群发服务器即第二用户代理UA2发送第一呼叫模式消息,包含接收方的地址列表(URI list);群发服务器收到该消息后将其分发给地址列表的各接收方,如第三用户代理UA3和第四用户代理UA4等。假定向第三用户代理发送的为第一呼叫模式消息的分发消息A,向第三用户代理发送的为第一呼叫模式消息的分发消息B。第一呼叫模式消息以及所对应的各分发消息的对话标识一般不相同。
步骤302.第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息。如果第一用户代理UA1希望只召回发送给第三用户代理的呼叫模式消息,则第一用户代理UA1在发送的替换消息即第二呼叫模式消息中不仅要在替换头字段Replaces中包含替换指示信息,还要在消息体中包含要替换的地址列表,如果只包含替换头字段Replaces而不包含替换地址列表,则表示要替换所有分发的呼叫模式消息。包含替换地址列表的替换消息内容举例如下:
MESSAGE sip:list-service.domain.com SIP/2.0
Replaces:asd88asd77a@1.2.3.4;to-tag=0;from-tag=49583;id=1
Content-Type:application/resource-lists+xml
Content-Disposition:recipient-list
<?xml version=″1.0″encoding=″UTF-8″?>
<resource-lists xmlns=″urn:ietf:params:xml:ns:resource-lists″><list>
<entry uri=″sip:user3@domain.com″/>
</list></resource-lists>
其中该消息的请求地址Request URI为sip:list-service.domain.com,对应群发服务器(MESSAGE URI-list Service)。消息体内容中包含要进行替换处理的地址列表如<entry uri=″sip:user3@domain.com″/>。其中消息体中可能还包含有其他内容,如纯文本的信息,这时用内容类型为多部分混合“multipart/mixed”的消息体来包含这些不同类型的内容即可。另外地址列表内容的处理方式Content-Disposition字段中也可以包含内容为替换地址列表的指示如“replace-list”。
步骤303.群发服务器根据发送记录生成相应的替换消息,并进行分发。收到替换消息的群发服务器确定需要向哪些地址分发替换消息。如果替换消息中不包含替换地址列表,则要对先前第一呼叫模式消息的分发消息全部分发相应的替换消息;如果包含替换地址列表,则只对替换列表中的接收方分发相应的替换消息。分发的替换消息中一般要包含除替换地址列表之外的其他消息体内容。
群发服务器中一般记录有第一呼叫模式消息和各分发消息之间的对应关系,当群发服务器收到替换消息即第二呼叫模式消息时,首先根据替换消息的头字段Replaces中包含的替换指示信息确定匹配的第一呼叫模式消息,然后在生成的分发的替换消息的头字段Replaces中包含与第一呼叫模式消息的分发消息相应的标识,举例如下,如群发服务器向第三用户代理UA3发送的第一呼叫模式消息的分发消息A部分内容如下:
MESSAGE sip:user3@domain.com SIP/2.0
To:<sip:user3@domain.com>
From:user1<sip:user1@domain.com>;tag=210342
Call-ID:39s02sds120d9sj21
CSeq:1MESSAGE
其中分发消息A的对话号Call-ID和From标签等都与第一呼叫模式消息不同,则群发服务器向第三用户代理UA3发送的相应的替换消息即第二呼叫模式消息的分发消息部分内容如下:
MESSAGE sip:user3@domain.com SIP/2.0
Replaces:39s02sds120d9sj21;to-tag=0;from-tag=210342;id=1
头字段Replaces中的各标识与第一呼叫模式消息的分发消息相对应。即群发服务器不能直接复制第一用户代理UA1发送的替换消息中的替换头字段Replaces,而是要根据自己存储的消息分发记录匹配到相应的分发消息,使用分发消息中的信息如对话号等生成最终的替换头字段Replaces。可见群发服务器并不是直接分发替换消息,而是要将替换头字段Replaces进行相应转换后再分发。如果群发服务器没有保存相应的消息分发记录,则可以向第一用户代理返回无法进行替换处理的通知。
如果群发服务器还没有对第一呼叫模式消息进行分发,然后就收到了相应的替换消息,则可以直接分发相应的替换消息。如果是召回处理的情况,则取消对第一呼叫模式消息的分发。如果替换消息中包含了地址列表,则上述的处理应只针对这部分地址列表进行,如只取消向指定的地址列表分发消息,或者向指定的地址列表分发相应的替换消息而向其他的地址仍然对原来的第一呼叫模式消息进行分发。群发服务器也可以向第一用户代理返回替换处理通知,在替换处理通知中可以包含地址列表以及相应的处理结果。
步骤304.接收到群发服务器分发的替换消息的用户代理如第三用户代理UA3进行相应的替换处理,与第一实施例中的相同,此处不再赘述。
如果第二呼叫模式消息中还包含了要获取替换处理通知的指示,则群发服务器在分发的替换消息中应当复制该指示,而最终的接收方返回的替换处理通知可以直接发送给第一用户代理,即From头字段中的逻辑地址,而不必发送给群发服务器。
无论是替换还是特别的召回处理,都最好提供安全机制,以防止攻击者恶意删除或篡改用户已经接收的消息。可以采用SIP所提供的安全机制对替换消息的发送方进行身份验证,如摘要认证(Digest)或者签名S/MIME等,具体可参见RFC3261。另外在一个信任域内也可以采用P-Asserted-Identity头字段对替换消息的发送方进行身份识别,具体可参见RFC3325。
一般来说,第一呼叫模式消息和第二呼叫模式消息的发送方是同一个用户,即两个消息的From头字段中的逻辑地址一般是相同的。当然本发明也允许不是同一用户,只要是接收方能够信任替换消息的发送方,并且对身份进行了认证,就可以进行相应的替换处理,否则可以向其返回禁止响应或者要求其进行身份认证。接收方还可以设置一些本地策略进行鉴权,如是否允许替换处理,允许接受哪些用户的替换消息,是否允许召回处理等。
如图4所示,本发明的用户代理包含基本的三个模块:传输处理模块S43,消息处理模块S42和替换处理模块S41。其中传输处理模块用于接收上层的消息处理模块发来的SIP消息,并采用相应的承载协议如UDP(UserDatagram Protocol)或TCP(Transmission Control Protocol)将其发送出去。消息处理模块用于对SIP消息进行编解码、以及事务控制等。替换处理模块用于进行与包含替换指示信息的消息的相关处理等,将与替换处理相关的消息通过消息处理模块编解码并管理相应事务收发消息。替换处理模块可以指示所述消息处理模块在即将发送的呼叫模式消息中包含替换指示信息,或者从消息处理模块接收已经解码的与替换处理相关的消息,并进行消息的替换处理,如产生相应的替换消息或产生替换结果通知消息等。替换处理模块还可以与消息存储模块S411、认证鉴权模块S412、替换结果处理模块S413、群发处理模块S414等进行交互,完成相应的功能。如通过消息存储模块获取已经发送的消息的对话标识或消息标识等,以生成相应替换消息中的替换指示信息,替换处理模块调用消息处理模块对生成的替换消息进行编码并且生成相应的事务,替换消息最终通过传输处理模块用UDP或TCP等协议发送出去。消息存储模块主要用于存储已经发送和接收的消息,向替换处理模块提供所存储的消息信息,以及根据替换处理模块的指示替换所存储的消息。
替换处理模块还可以通过认证鉴权模块在即将发送包含替换消息中增加签名信息或接收身份验证,对收到的替换消息进行认证或鉴权等。另外通过替换结果处理模块对已经完成的替换处理还可以生成相应的替换结果通知消息;或者当用户代理作为群发服务器时通过群发处理模块将收到的替换消息分发给多个人如指定的地址列表或者所要替换消息的接收方列表。
用户代理实际上一般同时具有上述实施例中UA1、UA2和UA3等发送方和接收方的处理能力,可以位于用户终端如手机、个人计算机等中,也可以位于应用服务器中。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (17)
1、一种处理呼叫模式消息的方法,其特征在于,该方法包括步骤:
第二用户代理接收到第一用户代理发送的第一呼叫模式消息;
第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息;
第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理。
2、根据权利要求1所述的方法,其特征在于,所述的指示信息为第二呼叫模式消息的替换头字段中的内容。
3、根据权利要求2所述的方法,其特征在于,所述第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息的步骤具体为:第一用户代理发送第二呼叫模式消息,其替换头字段中包含第一呼叫模式消息的对话号、发送方地址标签和接收方地址标签;
所述第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理的步骤具体为:第二用户代理将对话号、发送方地址标签和接收方地址标签都与第二呼叫模式消息的替换头字段中的对应值相匹配的呼叫模式消息进行替换处理。
4、根据权利要求2所述的方法,其特征在于,所述第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息的步骤具体为:第一用户代理发送第二呼叫模式消息,其替换头字段中包含第一呼叫模式消息的对话号、发送方地址标签、接收方地址标签和消息序列号;
所述第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理的步骤具体为:第二用户代理将对话号、发送方地址标签、接收方地址标签和消息序列号都与第二呼叫模式消息的替换头字段中的对应值相匹配的呼叫模式消息进行替换处理。
5、根据权利要求1所述的方法,其特征在于,所述第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息,其中的指示信息还包含替换处理的具体方式为召回处理;
则所述第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理的步骤具体为:第二用户代理同时删除第一呼叫模式消息和第二呼叫模式消息。
6、根据权利要求1所述的方法,其特征在于,所述的第一用户代理发送的第一呼叫模式消息中包括即时消息处理通知消息标识;
所述第一用户代理发送包含替换第一呼叫模式消息指示信息的第二呼叫模式消息的步骤具体为:第一用户代理发送第二呼叫模式消息,其通用呈现和即时消息内容的替换头字段中包含第一呼叫模式消息的即时消息处理通知消息标识。
7、根据权利要求6所述的方法,其特征在于,所述第一用户代理发送的第二呼叫模式消息中还包括要获取替换处理通知的指示;
则在所述第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理步骤之后,第二用户代理向第一用户代理返回相应的替换处理结果通知消息。
8、根据权利要求1至7任一项所述的方法,其特征在于,所述的第二用户代理为群发服务器,第二用户代理接收到第一用户代理发送的第一呼叫模式消息中包含地址列表,并将第一呼叫模式消息向地址列表分发;
所述的第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理的步骤具体为:
如果第二呼叫模式消息中包含指定的地址列表,则第二用户代理即群发服务器向第二呼叫模式消息中指定的地址列表分发替换消息,向每个地址对应的用户代理所分发的替换消息中的所述指示信息与群发服务器对第一呼叫模式消息向该地址所分发的消息相对应。
9、根据权利要求1至7任一项所述的方法,其特征在于,所述的第二用户代理为群发服务器,第二用户代理接收到第一用户代理发送的第一呼叫模式消息中包含地址列表,并将第一呼叫模式消息向地址列表分发;
所述的第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理的步骤具体为:
如果第二呼叫模式消息中没有包含地址列表,则第二用户代理即群发服务器向对应第一呼叫模式消息中指定的地址列表分发替换消息,向每个地址对应的用户代理所分发的替换消息中的所述指示信息与群发服务器对第一呼叫模式消息向该地址所分发的消息相对应。
10、根据权利要求1至7任一项所述的方法,其特征在于,所述的第二用户代理为群发服务器,第二用户代理接收到第一用户代理发送的第一呼叫模式消息中包含地址列表,在将第一呼叫模式消息向地址列表分发之前收到了第二呼叫模式消息;
所述的第二用户代理根据所述指示信息用第二呼叫模式消息对第一呼叫模式消息进行替换处理的步骤具体为:
第二用户代理直接分发相应的替换消息,或者当是召回处理的情况时取消发送对应的第一呼叫模式消息的分发消息。
11、根据权利要求8所述的方法,其特征在于,接收所述分发的替换消息的用户代理直接向第一用户代理返回替换处理通知消息。
12、一种替换即时消息的方法,其特征在于,包括步骤:
发送第一即时消息,并在通用呈现和即时消息内容中包含消息标识;
发送包含替换第一即时消息指示信息的第二即时消息,所述的指示信息包含对应第一即时消息的消息标识;
根据所述的指示信息将消息标识相匹配的第一即时消息进行替换处理。
13、根据权利要求12所述的方法,其特征在于,所述的指示信息包含在通用呈现和即时消息内容的替换头字段中,或者包含在内容处理方式头字段中。
14、根据权利要求12或13所述的方法,其特征在于,
在发送的所述第二即时消息中还包括要获取替换处理通知的指示;
在根据所述的指示信息将所匹配的第一即时消息进行替换处理步骤之后,返回相应的替换处理结果通知消息。
15、一种用户代理,其特征在于,包括:
传输处理模块,用于接收消息处理模块发来的会话初始协议消息,并采用相应的承载协议将其发送出去;
消息处理模块,用于对会话初始协议消息进行编解码和事务控制;
替换处理模块,用于与消息处理模块交互处理与替换处理相关的消息。
16、根据权利要求15所述的用户代理,其特征在于,所述替换处理模块处理与替换处理相关的消息具体为:
指示所述消息处理模块在即将发送的消息中包含替换指示信息;和/或,
从消息处理模块接收已经解码的与替换处理相关的消息,进行替换处理。
17、根据权利要求15或16所述的用户代理,其特征在于,还包括以下至少一个模块:
消息存储模块,用于存储已经发送和接收的消息,向替换处理模块提供所存储的消息信息,以及根据替换处理模块的指示替换所存储的消息;
认证鉴权模块,用于在即将由替换处理模块发送的替换消息中增加签名信息和/或接收身份验证,或者对收到的替换消息进行认证和/或鉴权;
替换结果处理模块,用于对已经完成的替换处理生成相应的替换结果通知消息,并由替换处理模块发送;
群发处理模块,用于将收到的替换消息生成给指定地址列表的分发消息,并由替换处理模块发送。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007100747378A CN101321135A (zh) | 2007-06-05 | 2007-06-05 | 一种处理呼叫模式消息的方法和用户代理 |
PCT/CN2008/071109 WO2008148339A1 (fr) | 2007-06-05 | 2008-05-27 | Procédé, agent d'utilisateur servant à traiter un message d'un modèle de dispositif de messagerie |
US12/631,145 US20100138507A1 (en) | 2007-06-05 | 2009-12-04 | Method for processing pager model messages and user agent thereof |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007100747378A CN101321135A (zh) | 2007-06-05 | 2007-06-05 | 一种处理呼叫模式消息的方法和用户代理 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101321135A true CN101321135A (zh) | 2008-12-10 |
Family
ID=40093187
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2007100747378A Pending CN101321135A (zh) | 2007-06-05 | 2007-06-05 | 一种处理呼叫模式消息的方法和用户代理 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20100138507A1 (zh) |
CN (1) | CN101321135A (zh) |
WO (1) | WO2008148339A1 (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9477947B2 (en) | 2009-08-24 | 2016-10-25 | International Business Machines Corporation | Retrospective changing of previously sent messages |
US9338071B2 (en) | 2014-10-08 | 2016-05-10 | Google Inc. | Locale profile for a fabric network |
WO2016070338A1 (zh) * | 2014-11-04 | 2016-05-12 | 华为技术有限公司 | 一种显示消息的方法、装置及设备 |
US10693825B2 (en) * | 2018-06-06 | 2020-06-23 | T-Mobile Usa, Inc. | Systems and methods for editing, recalling, and deleting messages |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU7106200A (en) * | 1999-09-18 | 2001-04-24 | Genie L. Ogilvie | Self-removing email for recipient convenience |
US7343394B2 (en) * | 2003-03-10 | 2008-03-11 | International Business Machines Corporation | Method of managing e-mail messages |
CN100401724C (zh) * | 2005-12-15 | 2008-07-09 | 华为技术有限公司 | 发送即时消息的方法和设备 |
US20080307362A1 (en) * | 2007-06-08 | 2008-12-11 | Apple Inc. | Desktop Filter |
-
2007
- 2007-06-05 CN CNA2007100747378A patent/CN101321135A/zh active Pending
-
2008
- 2008-05-27 WO PCT/CN2008/071109 patent/WO2008148339A1/zh active Application Filing
-
2009
- 2009-12-04 US US12/631,145 patent/US20100138507A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20100138507A1 (en) | 2010-06-03 |
WO2008148339A1 (fr) | 2008-12-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101635906B1 (ko) | 통신 이력 제공 방법 | |
ES2349353T3 (es) | Tratamiento de mensajes instantaneos en caso de no disponibilidad del receptor. | |
EP1929730B1 (en) | Method and apparatus for instant messaging | |
US9397968B2 (en) | Method for processing deferred message | |
JP4560018B2 (ja) | 接続制御システム、接続制御装置、接続制御方法および接続制御プログラム | |
RU2504115C2 (ru) | Способ и устройство для управления контактами адресной книги | |
CN101212719B (zh) | 一种无线通信网络中实现融合消息业务的方法及系统 | |
US20070226295A1 (en) | Method and apparatuses for retrieving messages | |
CN101714170B (zh) | 一种基于xdms的群组管理系统及方法 | |
CN101461261B (zh) | 利用基于sip的消息服务的组广告方法 | |
US20080270553A1 (en) | Method and System for Instant Notification of Communication Block Information | |
EP1938536A1 (en) | Retrieval of offline instant messages | |
RU2404549C2 (ru) | Механизм удаления сообщения или файла в мультимедийных службах, работающих по протоколу sip | |
CN102130845A (zh) | 回执报告的发送方法及处理系统 | |
CN101321135A (zh) | 一种处理呼叫模式消息的方法和用户代理 | |
KR20130082561A (ko) | 연락처 정보의 구독을 초대하는 장치 및 방법 | |
CN101345742B (zh) | 一种即时通讯用户状态显示的系统和方法 | |
KR20090087791A (ko) | 비통합메시징 서비스와 인터워킹하기 위한 통합메시징서비스 제공 시스템 및 방법 | |
CN101267325A (zh) | 发起和加入会议通话的方法、会议服务器和终端 | |
CN101754428A (zh) | 基于sip的即时通讯系统中的添加好友的实现方法 | |
KR20080034072A (ko) | Sip기반의 전송 메시지를 이용한 이종 메시지의 전송방법 및 이를 위한 사용자 장치 | |
Camarillo et al. | Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) | |
KR20090058611A (ko) | 아이엠에스 기반의 프레즌스 서비스 연동 시스템 및 방법 | |
CN101325581B (zh) | 一种发送会话初始协议参考消息的方法和用户代理 | |
CN101312452A (zh) | 回复呼叫模式消息的方法和用户代理 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20081210 |