- 浏览: 742422 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
u011487470:
感觉就是知识采集一样,博主能不能整理一下
基于Web的IM简介 -
whxtbest:
whxtbest 写道2里面:如果T本身就是重复的话 比如 ...
关于后缀树的一些理解 -
whxtbest:
2里面:如果T本身就是重复的话 比如S是aaab,T是aa ...
关于后缀树的一些理解 -
刘亮love小雪:
谢谢啦
Java 2D高级绘图 -
bluky999:
收集的资料挺多的 哈哈
基于Web的IM简介
Instant Message是指用户间实时的短消息通信,这些消息一般都比较简短。IM一般以实时对话的模式使用,也就是说,消息在用户之间的来回传输时延足够小,能够满足用户间实时对话的要求。
以下是IETF定义的Instant Message系统模型。
图表 1 IETF定义的Instant Message模型
SIP协议中MESSAGE消息的扩展使得SIP能够支持IM通信。既然MESSAGE是对SIP消息的扩展,那么它也就继承了一般SIP请求的一切路由和安全特性。MESSAGE与INVITE不同,本身并不会初始化一个SIP对话。在普通应用中,IM应用像页面消息一样独立存在。MESSAGE可以利用其它SIP请求建立的对话来发送。
u IM的两种模型
IM应用有页面模型和会话模型两种形式。在页面模型中,消息之间没有直接的联系,每个Instant message相互独立,任何形式的对话只是在用户终端界面显示的不同。与会话模型比较,会话模型有一个直接的对话上下文的联系,并且有明显的开始与结束标志。在SIP中,IM会话与一个媒体会话相关联,这个会话一般由INVITE事务发起、BYE事务终结。
每种模型都有着重要价值。现在大多数的IM客户段都支持这两种模型。用户既可以向某个联系人发送简单的消息,也可以邀请一个或多个联系人加入到同一个对话中。当用户要发送消息到一个或几个联系人时,可以使用页面模型;同样,在群组聊天等扩展的会话中,会话模型不可缺少。
由于页面模型使用的广泛性,本文只讨论基于页面模型的IM。当然,会话模型再IM中也十分重要。
另外,在SIP对话中传输MESSAGE消息时,必须确保MESSAGE请求的目的地正好是该对话的目的端。这样就限制了IM终端与信令终端的灵活性,要求二者必须统一。显然。这在IM应用中是不能接受的。但令一方面,从应用的角度来说,在SIP建立的对话中发送MESSAGE又是合理的。例如,在一个语音会话中,参与者可能想要发送一条消息给对方,这时会将IM与该会话关联后直接发送。但在实际部署中,不应该单纯地为了关联多个MESSAGE而创建对话。但这并不表示不能使用SIP来创建以IM为内容的媒体会话。
u MESSAGE消息格式
在MESSAGE消息的使用中,Request-URI一般为接收方的URI。在用户端已经获知接受方的当前位置信息的情况下,Request-URI可以是一个设备地址。MESSAGE消息的消息体可以是任何MIME类型的消息体,包括message/cpim(见RFC3860)格式。由于各个IM协议都要求支持message/cpim格式,使用不同IM协议的各个终端可以就在不使用网关或其它转换器的情况下实现信息的交互。这可以帮助实现不同IM协议终端间安全的端到端通信。
另外,发送端可以通过添加Expires消息头来限制MESSAGE消息的生命周期。如果MESSAGE消息添加了Expires消息头,那么还需要添加Date消息头来标明消息的发送时间,以此来确定MESSAGE消息的超时时间。如果没有Date头域,接收端将以接受到消息的时间为起始来决定超时时间。没有Expires头域的消息不会超时。如果消息在向用户呈现之前超时,则UAS可以根据本地策略来处理超时的消息,例如删除消息、保留消息直到用户阅读。一旦用户阅读了消息,则该条消息超时。如果消息在中转过程中超时,同样根据本地策略来处理超时的消息。
关于即时消息收件箱地址的介绍可查看RFC3861。
MESSAGE请求在到达目的地前可能会穿越一系列的代理,这些代理将使用不同的传输即时协议。过程中每一跳的目的以及地址分配规则可以查看RFC3860。在穿越一些代理过程中,每一个代理会根据可用的路由信息重写Request-URI。
u 对MESSAGE消息的响应
一般来说,MESSAGE的最终接受代理会回复200 OK来表示对同意接收消息,但并不表明接受者已经阅读了该消息。
如果收到对MESSAGE的200 OK响应,发送端将认为消息已经被成功发送至目的地,但并不意味着接收端已经阅读了该消息。
如果接收到的是202 Accepted响应,则表示消息被发送至网关,并被存储转发至其它服务器,由其它服务器来完成最终的消息投递。一个对MESSAGE的2XX响应是不允许携带任何消息体的,同时在2XX消息中不能使用Contact头域。对于一个已经回复了202 Accepted响应的消息来说,还需要其它机制来确保该消息被成功发送至接受端,这里不再详细讨论。
4XX与5XX响应表示MESSAGE消息投递失败,6XX则表示消息被成功投递至接收端,但被接收端拒绝。
对于支持MESSAGE方法的地UAS必须能够接受并显示text/plain类型的消息体,同时也可以支持message/cpim格式。
u MESSAGE拥塞控制
如上文所述,由于MESSAGE不同于其它SIP请求,MESSAGE请求携带IM媒体流,而其它SIP消息携带的则是关于媒体流的信令信息,而不是媒体本身。这样当呼叫信令与即时消息共享SIP下部结构时,IM流量会影响信令流的正常工作。因此,拥塞控制应该从SIP规范的层次来讨论,而不是作为一个独立的优化策略来讨论。由于MESSAGE与其它SIP方法的不同,对MESSAGE消息也应该特殊考虑。
可能的情况下,MESSAGE请求应该使用有端到端拥塞控制机制的传输协议进行传输,如TCP、SCTP。然而,SIP协议本身并不能禁止下一跳使用UDP传输。
在UAC不能确保每一跳的传输拥塞安全性的条件下,媒体会话外的MESSAGE请求大小不能超过1300字节,除非UAC能确保MESSAGE消息比所有中间路由的最小MTU小200字节。在使用媒体会话传输或间接内容类型的情况下,可以支持更大负荷的传输。
u MESSAGE实例
下面的消息流给出了从U1到U2的初始IM通信过程,其中U1、U2在同一个域,直接仅仅经过一个代理。
图表 2 MESSAGE消息流
F1 MESSAGE:
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
F2 MESSAGE:
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
F3 200 OK:
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com; branch=z9hG4bK123dsghds;received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
F4 200 OK:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
参考:
RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
RFC2778 A Model for Presence and Instant Messaging
以下是IETF定义的Instant Message系统模型。
图表 1 IETF定义的Instant Message模型
SIP协议中MESSAGE消息的扩展使得SIP能够支持IM通信。既然MESSAGE是对SIP消息的扩展,那么它也就继承了一般SIP请求的一切路由和安全特性。MESSAGE与INVITE不同,本身并不会初始化一个SIP对话。在普通应用中,IM应用像页面消息一样独立存在。MESSAGE可以利用其它SIP请求建立的对话来发送。
u IM的两种模型
IM应用有页面模型和会话模型两种形式。在页面模型中,消息之间没有直接的联系,每个Instant message相互独立,任何形式的对话只是在用户终端界面显示的不同。与会话模型比较,会话模型有一个直接的对话上下文的联系,并且有明显的开始与结束标志。在SIP中,IM会话与一个媒体会话相关联,这个会话一般由INVITE事务发起、BYE事务终结。
每种模型都有着重要价值。现在大多数的IM客户段都支持这两种模型。用户既可以向某个联系人发送简单的消息,也可以邀请一个或多个联系人加入到同一个对话中。当用户要发送消息到一个或几个联系人时,可以使用页面模型;同样,在群组聊天等扩展的会话中,会话模型不可缺少。
由于页面模型使用的广泛性,本文只讨论基于页面模型的IM。当然,会话模型再IM中也十分重要。
另外,在SIP对话中传输MESSAGE消息时,必须确保MESSAGE请求的目的地正好是该对话的目的端。这样就限制了IM终端与信令终端的灵活性,要求二者必须统一。显然。这在IM应用中是不能接受的。但令一方面,从应用的角度来说,在SIP建立的对话中发送MESSAGE又是合理的。例如,在一个语音会话中,参与者可能想要发送一条消息给对方,这时会将IM与该会话关联后直接发送。但在实际部署中,不应该单纯地为了关联多个MESSAGE而创建对话。但这并不表示不能使用SIP来创建以IM为内容的媒体会话。
u MESSAGE消息格式
在MESSAGE消息的使用中,Request-URI一般为接收方的URI。在用户端已经获知接受方的当前位置信息的情况下,Request-URI可以是一个设备地址。MESSAGE消息的消息体可以是任何MIME类型的消息体,包括message/cpim(见RFC3860)格式。由于各个IM协议都要求支持message/cpim格式,使用不同IM协议的各个终端可以就在不使用网关或其它转换器的情况下实现信息的交互。这可以帮助实现不同IM协议终端间安全的端到端通信。
另外,发送端可以通过添加Expires消息头来限制MESSAGE消息的生命周期。如果MESSAGE消息添加了Expires消息头,那么还需要添加Date消息头来标明消息的发送时间,以此来确定MESSAGE消息的超时时间。如果没有Date头域,接收端将以接受到消息的时间为起始来决定超时时间。没有Expires头域的消息不会超时。如果消息在向用户呈现之前超时,则UAS可以根据本地策略来处理超时的消息,例如删除消息、保留消息直到用户阅读。一旦用户阅读了消息,则该条消息超时。如果消息在中转过程中超时,同样根据本地策略来处理超时的消息。
关于即时消息收件箱地址的介绍可查看RFC3861。
MESSAGE请求在到达目的地前可能会穿越一系列的代理,这些代理将使用不同的传输即时协议。过程中每一跳的目的以及地址分配规则可以查看RFC3860。在穿越一些代理过程中,每一个代理会根据可用的路由信息重写Request-URI。
u 对MESSAGE消息的响应
一般来说,MESSAGE的最终接受代理会回复200 OK来表示对同意接收消息,但并不表明接受者已经阅读了该消息。
如果收到对MESSAGE的200 OK响应,发送端将认为消息已经被成功发送至目的地,但并不意味着接收端已经阅读了该消息。
如果接收到的是202 Accepted响应,则表示消息被发送至网关,并被存储转发至其它服务器,由其它服务器来完成最终的消息投递。一个对MESSAGE的2XX响应是不允许携带任何消息体的,同时在2XX消息中不能使用Contact头域。对于一个已经回复了202 Accepted响应的消息来说,还需要其它机制来确保该消息被成功发送至接受端,这里不再详细讨论。
4XX与5XX响应表示MESSAGE消息投递失败,6XX则表示消息被成功投递至接收端,但被接收端拒绝。
对于支持MESSAGE方法的地UAS必须能够接受并显示text/plain类型的消息体,同时也可以支持message/cpim格式。
u MESSAGE拥塞控制
如上文所述,由于MESSAGE不同于其它SIP请求,MESSAGE请求携带IM媒体流,而其它SIP消息携带的则是关于媒体流的信令信息,而不是媒体本身。这样当呼叫信令与即时消息共享SIP下部结构时,IM流量会影响信令流的正常工作。因此,拥塞控制应该从SIP规范的层次来讨论,而不是作为一个独立的优化策略来讨论。由于MESSAGE与其它SIP方法的不同,对MESSAGE消息也应该特殊考虑。
可能的情况下,MESSAGE请求应该使用有端到端拥塞控制机制的传输协议进行传输,如TCP、SCTP。然而,SIP协议本身并不能禁止下一跳使用UDP传输。
在UAC不能确保每一跳的传输拥塞安全性的条件下,媒体会话外的MESSAGE请求大小不能超过1300字节,除非UAC能确保MESSAGE消息比所有中间路由的最小MTU小200字节。在使用媒体会话传输或间接内容类型的情况下,可以支持更大负荷的传输。
u MESSAGE实例
下面的消息流给出了从U1到U2的初始IM通信过程,其中U1、U2在同一个域,直接仅仅经过一个代理。
图表 2 MESSAGE消息流
F1 MESSAGE:
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
F2 MESSAGE:
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
F3 200 OK:
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com; branch=z9hG4bK123dsghds;received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
F4 200 OK:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
参考:
RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
RFC2778 A Model for Presence and Instant Messaging
发表评论
-
[转]RFC3428 IM(即时消息)
2008-05-26 14:41 2151即时消息(IM)指的是近似实时的消息交互。即时消息通常很短,虽 ... -
dialog, transaction, session之我见
2008-05-06 11:12 4483SIP中3个很重要的概念,就是dialog, session和 ... -
SIP应答头
2008-04-07 14:20 23351xx = 通知性应答 100 正在尝试 180 正在拨打 ... -
SIP Servlet知识点总结【更新】
2008-04-02 18:33 28251) sip.xml处理http请求的web应用里的概念一样: ... -
【转】Ethereal简介
2008-04-02 13:39 1488Ethereal是一个开放源码 ... -
启动sailfin时问题:CLI156 Could not start the domal的解决办法
2008-04-01 16:21 1776Default server domain can be cr ... -
Sailfin自带的例子CallSetup的实现过程
2008-03-21 18:22 19281. 首先,UAC(可以是X-lite等)向Registrar ... -
Eclipse环境下开发基于Sailfin的Sip Servlet应用
2008-03-21 18:01 7188SailFin项目由爱立信公司开发,它基于具有健壮性和可扩展性 ... -
SIP: From ,Contact, Via 和 Record-Route/Route head
2008-03-21 15:37 11829From: 如果一个SIP消息中没有Contact或者Reco ... -
SIP电话设计思路
2008-03-19 10:06 15751. caller调用方法Call creat ... -
sailfin安装方法
2008-03-10 18:06 1887https://sailfin.dev.java.net/do ... -
SIP IM设计思路
2008-02-22 02:44 32321。启动客户端界面程序InstantMessagingGUI, ... -
SIP协议简介
2008-02-20 04:25 2514SIP( Session Initiation Proto ... -
Jain Sip知识点总结
2008-02-20 03:36 16481)register的时候from头和to头一样 2)requ ... -
Jain-Sip API
2008-02-20 02:17 2769http://snad.ncsl.nist.gov/proj/ ... -
[更新]SIP Communicator功能总结
2008-02-01 01:05 17731) contact list的meta data可以重名名, ... -
sip-communicator
2008-01-31 01:11 1536http://www.sip-communicator.org ... -
How to configure Eclipse to compile and debug SIP
2008-01-30 00:42 1392http://www.sip-communicator.org ...
相关推荐
全球V2X技术进展概述——第5届SIP-adus大会(SIP-adus Workshop 2018)车联网综述.pdf
标准SIP协议客户端,电脑PC端软件,可配置自己SIP服务器使用,调试PBX,调试各种SIP服务器都很好用,支持主流语音编码!拿出来免费贡献,用的上的自行下载即可使用!SIP技术支持可以联系我们,标准SIP协议客户端,...
下一代网络)以及IMS(IP Multimedia Subsystem,IP多媒体子系统)的网络中,可以支持并应用于语音、视频、数据等多媒体业务,同时也可以应用于Presence(呈现)、Instant Message(即时消息)等特色业务。...
基于SIP协议REFER方法呼叫转接的设计与实现
开发支持sip协议的jar包。concurrent.jar,JainSipApi1.2.jar,log4j-1.2.8.jar,nist-sdp-1.0.jar,sip-sdp.jar。
下一代网络)以及IMS(IP Multimedia Subsystem,IP多媒体子系统)的网络中,可以支持并应用于语音、视频、数据等多媒体业务,同时也可以应用于Presence(呈现)、Instant Message(即时消息)等特色业务。...
SIP消息示例分析,图文并茂,可帮助初学SIP者增进理解。
什么是SIP SIP将付诸实施 Presence 小结
基于SIP的Web语音系统的研究,贾睿,李崴海,本文设计并实现了基于SIP的Web语音系统——WebVox。该系统基于SIP协议实现了Web语音系统服务器端的呼叫控制、会话建立等功能。并且在Jai
skype转SIP协议软件 SISKY2.6
第一章 SIP协议. 3 SIP独立与媒体. 3 SIP独立于传输层. 3 SIP有很好的扩展性. 3 SIP和最终用户服务. 3 第二章 SIP协议概述. 4 SIP语法. 4 SIP事务. 5 SIP会话. 5 Server 行为. 7 第三章 oSIP...
中文版的SIP协议,RFC3261 嫌英文看着麻烦的可以试试
免费的VOIP网络电话,Android平台SIP客户端 支持服务端: Cisco CallManager, OpenSER, Kamailio, OpenSIPS, Asterisk, ...支持DTMF: 发送DTMF tone(RFC2833 and SIP INFO), 检测DTMF tone(RFC2833 and SIP INFO).
RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP).docx
YDT 2256-2011标准 该标准规定了支持sip协议设备上的SIP协议安全性的技术要求
学习和研究sip协议的重要参考图书资料——sip揭秘,希望对初涉sip的朋友有所帮助。
H248协议介绍 sip VOIP SoftSwith
安卓Andriod源码——-Sip2Peer-1.0实现p2p.zip
安卓Android源码——-Sip2Peer-1.0实现p2p.zip
《SIP揭密》在SIP创始人设定的背景下对SIP给予了详细介绍,同时解释了怎样才能把它当作一种有创新能力的工具用于电信业务。《SIP揭密》由IETF最早的SIP发起人之一撰写,深入解释了当今人们谈论最多的关于SIP协议是...