IP电话网络技术 第2章.docx
- 文档编号:26897604
- 上传时间:2023-06-23
- 格式:DOCX
- 页数:45
- 大小:351.32KB
IP电话网络技术 第2章.docx
《IP电话网络技术 第2章.docx》由会员分享,可在线阅读,更多相关《IP电话网络技术 第2章.docx(45页珍藏版)》请在冰豆网上搜索。
IP电话网络技术第2章
2.1相关TCP/IP协议
IP电话与TCP/IP协议族息息相关,这里仅对与IP电话相关的协议加以介绍。
2.1.1IP协议
IP协议是TCP/IP协议族的一部分,位于网络层,是被广泛使用的一种互联网协议。
它是一种面向无连接的协议,也就是说正在通信的端点之间没有建立连接。
通过Internet的每一个包都被视为单独的数据单元,与其他数据单元没有任何联系。
两个通信端点之间的任何系统只需要完成IP及其下层的服务功能,没有必要执行IP以上的协议功能。
如果需要,这两个端点之间可通过IP上层的协议跟踪并保障所到达包的顺序。
IP使用32位(IPv4)或128位(IPv6)的IP地址,地址通过编码来确认不同的网络和主机,这种编码为主机的地址分配提供了灵活性。
在IP协议的下层也有几个处理网络和物理连接的协议,但这里没有提及。
IP从高层接收数据,对于该数据,IP添加一个报头,在报头中为数据加上与之相关的信息,然后传到下一层。
IP最重要的任务是将数据包发送到合适的下一跳,全部路由信息都包含在IP数据包的报头中。
当来自传输层的数据大于数据链路层的尺寸时,IP协议就将其分割并重新组包。
IPv4的报头格式如图2.1所示,各字段意义如下所述。
偏移
图2.1IPv4的报头格式
版本(Version):
当前的版本是4。
分组头长度(HeadLength):
是以32位字为单位的IP分组头的长度。
这样,一个典型的20字节的分组头应该包含5个32位字。
服务类型(TypeofService):
8比特的服务类型字段分为两个部分——优先级(Precedence)和服务类型(TOS)。
优先级由3比特组成,定义优先级的最初目的是提供一种能够为特定分组流分配优先级的手段。
其余的5比特为穿越网络的IP分组定义了服务类型。
实际上,TOS字段从未按其最初设想而被真正地使用过,但目前新的研究工作正在努力试图重新定义TOS字段,以使其能够为IP分组分配服务类型,这就是所谓的差分服务(DifferentiatedServices)。
总长度(TotalLength):
是一个16比特的数据包长度字段,用来定义以字节为单位的整个IP分组的总长。
IP分组的最大长度为65536字节。
标识(Identification):
这个字段包含一个16比特的标识符,目的主机用它来识别和组合IP分组的片段。
如果IP分组的入线数据链路的最大传输单元(MTU)长度大于其出线数据链路的MTU长度,IP路由器就会把该IP分组分段。
MTU长度的定义是数据链路帧所能承载的最大的IP分组的长度。
IP分组的组装只在目的主机上进行。
数据分段并不是一个好办法,因为它在路由器和目的主机上引入了额外的开销。
一种被称为“通路MTU发现”(PathMTUDiscovery)的技术可以使发送分组的源主机发现从源端到目的地通路上的最长MTU长度,因而可以避免任何不必要的分段操作。
标志(Flag):
标志字段由3比特构成,其含义如下:
Bit0保留;
Bit10代表可以对分组进行分段,1代表不可分段;
Bit20代表最后一个段,1代表还有更多的段。
偏移(Offset):
偏移字段由13比特构成。
原始IP分组被分段后,每一个分段生成的数据块(FragmentBlock)都有一个从IP分组起始位置开始编号的序号,这个序号记录在偏移字段中。
生存时间(TTL,TimeToLive):
TTL字段用来防止在网络中出现IP分组的无限循环。
一个IP分组每经过一个路由器,TTL值都会减小。
当TTL的值减到0时,路由器就会丢弃该分组。
最初TTL值是一定数量的秒数,但目前它的含义是在路由器之间允许的最大跳(hop)数。
TTL值也被用来控制组播(Multicast)分组在网络中传播的范围。
组播分组的TTL值必须大于通往外部路由器接口中所配置的TTL阈值,否则该分组将被丢弃。
协议(Protocol):
协议字段用来鉴别利用了IP服务的邻接高层所采用的协议。
例如,6=TCP,17=UDP,1=ICMP(互联网控制消息协议),89=OSPF等。
分组头校验和(HeaderChecksum):
这个16比特的字段是根据IPv4分组头中的其他字段计算出来的。
分组每经过一个路由器,校验和的值都会被更新,因为TTL字段和IP选项字段中的值可能发生改变。
源IP地址(SourceIPAddress):
发出IP分组的主机的32位IP地址。
目的IP地址(DestinationIPAddress):
32位目的主机IP地址。
IP分组头中还可以有一系列的选项字段。
这些选项由通路上的每一个路由器来处理。
选项字段可以被添加到一个IP分组中,内容包括源选路和路由器警告等。
实际中选项字段很少被使用,因为它所带来的任何功能的增强与它所引起的每个中间路由器的额外处理开销相比都是不值得的。
IP的版本4即IPv4(32位地址),将被版本6即IPv6(128位地址)所取代,IPv6的分组头长度为40字节,其格式如图2.2所示,各字段意义如下所述。
图2.2 IPv6的报头格式
版本:
版本号是6。
业务流类型(TrafficClass):
是IPv6分组中的DiffServDS字节。
流标记(FlowLabel):
是一个由源端分配的非零值,用来鉴别需要特殊服务处理(如QoS或非缺省特定服务等)的特定流中的分组。
流标记的长度为20比特。
负载长度:
是一个16比特长的字段。
它定义了在IPv6分组头后面的扩展头加上负载的字节长度。
下一分组头(NextHeader):
它定义了紧跟在后面的分组头的类型,它可能是一个扩展分组头、传输层分组头(如TCP),或者甚至是数据负载。
该字段的长度为1字节。
跳数限制(HopLimit):
1个8比特的值,其功能与IPv4中的TTL字节相同。
源地址:
128比特的IPv6源地址。
目的地址:
128比特的IPv6目的地址。
地址被用尽是IPv4存在的最大弊病,IPv6克服了这一缺点。
为了优化对数据的处理,IPv6将IPv4包中的一些特殊选项安排到不同的可选报头中。
IPv6通过对数据包的流进行标记来支持资源分配。
通过这种方法,对于像语音、图像这些对时延要求较高的数据包流,可有别于非实时性数据进行特殊对待,以保证其实时性。
IPv6还具有鉴权和保密的机制。
2.1.2TCP协议
TCP协议是面向连接的协议,也就是说通信双方建立连接后,这种连接会一直保持直到双方应用程序的信息交换结束。
TCP协议负责发送信息的打包并负责在接收端对这些包进行重组,恢复成原始信息。
其报头如图2.3所示,各字段意义如下所述。
31
确认序号
图2.3TCP报头
源端口(16比特):
源服务访问点。
目的端口(16比特):
目的服务访问点。
序号(32比特):
除了SYN标志置位的情况以外,它表示的是这个报文段中第1个数据8位组的序号。
如果SYN置位,那么它就是初始序号ISN(InitialSequenceNumber),而第1个数据8位组的序号为ISN+1。
确认序号(32比特):
包含了TCP实体希望接收的下一个数据8位组的序号。
数据偏移量(4比特):
首部中32位字的数量。
保留(6比特):
为将来使用而保留。
URG:
紧急指针字段的含义。
ACK:
确认字段的含义。
PSH:
急迫功能。
RST:
复位连接。
SYN:
序号同步。
FIN:
发送结束。
窗口(16比特):
流量控制的信用分配值,以8位组为单位。
其内容为从确认字段中指出的那个8位组开始,发送方愿意接受的8位组的数量。
检验和(16比特):
报文段中所有16比特字加上一个伪首部的二进制反码之和,即取模(216-1)。
紧急指针(16比特):
指向紧急数据序列的最后一个8位组。
它使接收方能够知道共有多少紧急数据到来。
选项(可变):
目前只定义了一个选项,它指出了能够接收的最大报文段长度。
TCP面向传输层业务提供可靠的连接。
在传输数据之前,需要通信的终端系统先建立好一条连接。
连接建立后,TCP负责检查所有的数据包以保证数据包能到达接收端。
通过超时和重传机制来保障所传送的数据业务的可靠性。
TCP还具有流控制和错误检测功能。
数据包的传输速率根据网络负载来进行提高和降低的调整。
被破坏的数据包被卸载,然后进行重传。
TCP以上的应用就不必进行上述工作,因为这些功能TCP都已提供。
TCP通过确认机制来检验所发送的数据包是否已无差错地到达了接收端(目的地)。
TCP适合于可靠的数据交换,而对于实时应用,由于对实时性要求高,一般采用其他的超时和流控机制;一般的数据交换只要求接收到数据的准确性,而实时性业务更关心的是接收到信息的及时性。
2.1.3UDP协议
UDP协议是一种传输层协议,它对高层提供非连接服务,利用IP协议从一端向另一端发送数据。
不像TCP协议,UDP协议不能确保能够到达目的地,也不在接收端对打包的信息进行重组,即UDP协议不提供对到达的数据包排序的功能。
这就意味着使用UDP的用户应用程序必须保证所有到达信息的完整性及到达顺序的正确性。
然而正是这种可靠性的缺乏,使它对一些应用特别适合,如语音和图像的应用。
因此从应用者的角度来说,有了是否采用包的重传机制以及采用哪种流控机制的可能。
对于那些交换的数据量小、处理时间要求严格的应用程序倾向于使用UDP协议,而不是TCP协议。
UDP报头只包含源和目的地端口、包的长度以及用于错误检测的检验和(Checksum)字段,且检验和字段是可选项,如图2.4所示。
各字段意义如下所述。
图2.4UDP报头格式
源端口:
源端口号码。
UDP端口的概念和TCP中相同,并且是统一编号的。
上层程序通过端口使用传输层所提供的服务,无论是UDP还是TCP服务。
目的端口:
目的端口号码。
长度:
UDP数据包的长度,包括首部和数据部分。
检验和:
防止UDP数据包在传输中出错。
UDP可同时受理多个应用,不同的端口号被分配给不同的应用。
2.1.4RTP/RTCP协议
RTP用于实时数据通信,包括语音和图像的传输层协议,它与其他协议一起用于像IP电话这类的交互式业务。
RTP由数据和控制两部分组成,其中控制部分被称为RTCP。
RTP的数据部分提供对实时性应用的支持(例如语音、图像这类连续媒体),包括定时重建、丢失检测、安全保障以及内容确认等。
RTCP提供基于Internet的组内实时会议的支持,这种支持包括资源确认、语音和图像网关的支持以及多址到单址的转换。
它还提供接收端QoS的反馈,以及不同媒体的流同步。
以前Internet主要用于文件传输和电子邮件,今天这种状态正在改变——多方参与的应用不断增加,实时性业务也在不断增长。
实时性应用与传统的数据业务有很大不同,它在通信中关心的是时延而不是数据的完整性。
TCP适合于可靠的通信,它的流控制和错误检测机制不适合于低时延业务。
正是由于上述原因,使得RTP协议得以产生和发展。
RTP既可运行于面向连接的协议之上,也可运行于面向非连接的协议之上,这是要以组帧和分段为代价的。
不像TCP,它不支持可靠的传输。
RTP用RTCP来监测所连接业务的QoS,并通过时钟和时间戳来使不同的媒体同步。
RTP的报头格式如图2.5所示,各字段意义如下所述。
9
其他同步源标识符
时间戳
图2.5 RTP报头格式
V(2比特):
版本号,目前为2。
P(1比特):
填充标识,表明数据区后是否有填充域。
X(1比特):
扩充标识,表明后面是否跟有扩展头标。
CC(4比特):
标识其他同步源(CSRC)数目,表明头标后所跟CSRC标识符数目。
M(1比特):
重要事件标记,由初始文件定义,如是否在分组数据流中定义了帧定界符等。
PT(7比特):
标识数据类型,表明数据区的数据类型,即包内数据采用何种编码方法,如对语音来说有PCM、ADPCM、LPC等。
序列号(16比特):
标识数据包的序号,用于接收端正确建立数据包顺序以及判断是否有数据包丢失。
时间戳(32比特):
表明数据包的时间同步信息,是接收方用来维持实时或与其他多媒体数据流的同步性的。
它既可以用于流内同步,也可用于流间同步。
它记录了数据包的第1个字节的创建时间。
时间戳的大小与数据流类型有关。
例如,频率为65.536Hz的时间戳常用于数字视频,而音频流则按采样速率打上时间戳记。
如果后续的多个RTP数据包属于数据流的同一个应用数据单元(即一个视频流),那么它们就可以使用同一个时间戳。
同步源标识符(SSRC,32比特):
发送者的标识符,是由发送方产生的随机数,并且为RTP会话生命周期所独有。
SSRC允许接收方惟一地识别一个数据流,在一个进程内不能有两个相同的标识符。
如果SSRC标识符发生冲突,可以找到这种冲突并且加以解决。
其他同步源标识符(CSRC,32比特):
对包内数据有贡献的源标识符,比如,如果混合器(mixer)改变了包内数据类型,则此混合器应作为其他同步源标识符。
2.1.5RTSP协议
RTSP协议是一个应用层协议,用来控制具有实时性数据的递交。
RTSP提供一个扩充框架,提供语音、图像这类数据按需交付。
数据源可以是实时的,也可以是存储式的。
该协议用于控制多个数据交付进程,为用户提供了选择UDP、多址UDP和TCP的数据交付手段,并提供了选择基于RTP交付机制的手段。
2.2IP电话基本流行网络协议
2.2.1IP电话网络协议主要开发组织
为了能使不同厂家的IP电话产品之间有良好的互联互通性,国际上的标准化组织都在积极参与并制订IP电话的标准。
目前,参与IP电话技术标准开发和推广的组织超过20家,其中最具影响力的主要有4家:
国际电信联盟标准化部门(ITU-T)、欧洲电信标准协会(ETSI)、Internet工程任务委员会(IETF)和国际多媒体电话会议协会(IMTC)。
ITU-T侧重电信标准,IMTC侧重互操作性,IETF侧重IP标准,ETSI侧重商业实现。
由于IP电话技术标准的开发涉及多个领域,这几家开发组织相互之间建立了比较良好的协作关系,而其他机构主要是发展、充实、实现和推广这些标准。
2.2.1.1国际电信联盟ITU
国际电信联盟ITU(InternationalTelecommunicationUnion)是联合国的一个专门机构,也是联合国机构中历史最长的一个国际组织,简称国际电联、电联或ITU。
该组织成立于1865年5月17日,定名为“国际电报联盟”。
1924年,在巴黎成立了“国际电话咨询委员会(CCIF)”。
1925年,在巴黎成立了“国际电报咨询委员会(CCIT)”。
1927年,在华盛顿成立了“国际无线电咨询委员会(CCIR)”。
1932年改名为“国际电信联盟”,1947年成为联合国的一个专门机构,总部由瑞士伯尔尼迁至日内瓦,还成立了国际频率登记委员会(IFRB)。
1956年,CCIF和CCIT合并为“国际电报电话咨询委员会”,即CCITT(InternationalTelegraphandTelephoneConsultativeCommittee)。
1992年12月的全权代表大会通过了电信联盟的改革方案,电信联盟的实质性工作由国际电信联盟标准化部门(ITU-T)、国际电信联盟无线电通信部门和国际电信联盟电信发展部门三大部门承担。
其中国际电信联盟标准化部门由原来的CCITT和CCIR的标准化部门合并而成,主要职责是完成电联有关电信标准化的目标,使全世界的电信标准化。
ITU-T的SG16研究组主要从事多媒体终端和安全问题的研究,最主要的工作就是制订H.323系列建议。
刚开始,一般都是通过现有的公共交换电话网实现数据通信。
因此,国际电信联盟从20世纪60年代起制订了V系列标准,其内容和在电话与电报网上进行数据传输有关,例如关于调制解调器的标准都是V系列的。
后来,由于数据通信的迅速发展,越来越多的数据网络建立起来。
从20世纪70年代起,国际电信联盟又开始制订X系列标准,其内容是在公共数据网中传输数据,例如著名的分组交换协议X.25。
ITU-T的第15研究小组在1996年通过了H.323v1,这是一个基于局域网的视频会议系统。
ITU-T的第16研究小组在1998年2月完成了H.323v2,它把H.323v1推广到包交换网络,目前正在讨论H.323v3。
2.2.1.2IMTC
IMTC(InternationalMultimediaTeleconferencing)即国际多媒体电话会议协会,由来自北美、欧洲和亚太地区的150多个成员组成。
宗旨是建立开放的国际标准,推动交互式多媒体远程会议的解决方案的应用和实现。
IMTC的VoIP论坛不定期地进行一些活动来制订标准,以促进IP电话业务的发展。
IMTC的工作目前集中于ITU采纳的多媒体会议标准——ITU-TT.120、H.320、H.323、H.324。
主要活动包括发起、实施不同会议产品供应商和基于这些标准的服务之间的互操作性测试会晤,就潜在技术和应用价值培训商家和客户,鼓励IMTC成员遵从那些能够加强多媒体电子会议产品的互操作性和可用性的标准。
IMTC成员在1997年4月采纳了VoIPIA1.0(IA即互操作协议)作为正式的实现协议,目前正在开发IA3.0。
IA1.0主要以H.323为基础,以G.711和G.723.1作为互操作支持的基本语音编码算法,规定舒适语音再生(CNG)、DTMF信号传输、动态地址映射和网关定位的互操作要求;IA2.0主要用来实现安全框架、计费结算、语音流复用、漫游用户标识和呼叫记录报告技术。
2.2.1.3IETF
IETF(InternetEngineeringTaskForce,Internet工程任务委员会)主要工作是制订新的信令协议,包括会话初始协议(SIP)、Internet和PSTN的网络互通协议。
IETF和IP电话工作组负责制订相关协议和框架文件,包括呼叫处理语法等。
该工作组还写出了一些业务模型文件,描述由呼叫处理语法实现的业务并讨论语法的使用方法,另外还包括网关属性分配协议等。
负责标准化Internet的协议由致力于Internet技术发展的各类组织组成。
IETF产生于1989年,当时Internet组织委员会IAB(InternetActivitiesBoard)分成两组,一组主要从事长期研究,另一组负责现有需要的工程。
Internet研究任务委员会IRTF由前一组演化而成,而后一组则形成了Internet工程任务委员会IETF。
IETF的工作领域集中在9个方面:
应用程序、Internet服务、网络管理、运行要求、路由、安全性、服务应用程序、传输和用户服务。
IETF每年开三次会,讨论不断出现的项目、建议和标准。
日常事务由MailingLists联系协调。
IETF由多个工程组组成,其成员在许多领域具有丰富的经验。
这些领域包括应用程序开发、开放系统互连(OSI)集成、路由选择、安全性和网络管理等。
工作组有公开成员资格和参与权利,每组设一个主任,称为AD(AreaDirector)。
IETF主席控制各组的方向,并帮助它作出决定和提出生产性成果。
规程要得到许多Internet委员会复审并通过,但只有IAB才能正式批准产生一项标准。
IETF在IP电话技术标准的开发中起着举足轻重的作用。
由于IP电话技术涉及电信和IP两个方面,所以人们在开发相关标准时,会同时提交给ITU-T和IETF。
ITU-T与IETF相比较而言,反应速度快,组织的开放性好。
IETF中有很多工程任务小组开发的标准都直接或间接地涉及IP电话技术。
1.AVT/RTP任务组
AVT/RTP任务组是为说明在UDP和IP复播上实时传输语音和视频的协议而建立的。
这是一个主要为集成和协调已有的研究活动中的当前AVT(Audio/VideoTransport)工作的短期小组。
由于语音和视频的UDP传输只适合于在Internet快速部分上的小规模实现,因此不会产生新的标准协议。
但是,该任务组产生的协议应该对将来及现在用于与访问网络级资源管理机制相结合的传统协议的大规模实现有所帮助。
作为现在研究的结果,这些机制将可以提供低延时服务和防止语音和视频通信不公平地消费网络带宽。
2.IPTEL任务组
IETF的IPTEL任务组负责制订相关协议和框架文件,包括呼叫处理语法等。
它是贝尔实验室主持的一个小组,主要开发IP电话信令处理和能力交流方面的协议及一些外围协议。
该工作组还写出了一些业务模型文件,描述由呼叫处理语法实现的业务并讨论语法的使用方法,另外还包括网关属性分配协议等。
按计划,该任务组将形成信令处理语法、服务模型、网关属性分布协议三个方面的文档。
3.MMUSIC任务组
MMUSIC任务组负责开发支持Internet电子会议会话的标准协议。
MMUSIC主要集中在支持目前多播主干网MBone(MulticastBackbone)上流行的松散控制的会议,同时还保证它开发的协议通用性足以用于管理紧密控制的会话。
目前,MMUSIC已经起草了以下协议:
关于分布式会话描述的会话描述协议SDP和会话通报协议SAP、提供会话通报安全性的SAPSecurity、控制实时数据按需传送的实时流协议RTSP、发起会话和邀请用户的会话发起协议SIP、管理紧密控制会话的简单会话控制协议SCCP。
另外,该任务组还起草了两个指导性文件:
MMUSIC体系框架、基于ITU和Internet电子会议系统的互操作性状况。
MMUSIC将与ITU标准实体及相关工业协会协作以保证SIP/ASP/SDP与ITUH.323及H.332之间的互操作性。
4.PINT任务组
PINT任务组由贝尔实验室主持,负责开发PSTN和Internet之间的连接组织,通过该连接组织,Internet应用可以请求并丰富PSTN电话服务。
PINT任务组负责写出一些业务模型文件,描述由呼叫处理语法实现的业务并讨论语法的使用方法。
另外,PINT任务组的工作还包括制订网关属性分配协议等。
2.2.1.4ETSI
ETSI(EuropeanTelecommunicationsStandardsInstitute,欧洲电信标准协会)是一个非赢利性组织,主要任务是确定和产生可以用于未来几十年的电信标准。
ETSI是一个开放的论坛,拥有来自50个国家和地区的696个成员,代表了管理者、网络操作者、制造商、网络提供者以及用户等各界人士。
所有对促进欧洲电信标准表示关注的欧洲组织都有权在ETSI发表意见,并将直接影响标准的制定过程。
ETSI的工作基于国际标准化组织实体(主要有ITU-T、ITU-R、IETF)的活动,并与之协作。
ETSITIPHONE工程组的主要目标是规定一套业务互操作性要求,确定接口和功能方面的体系结构,对呼叫控制程序、信息流和协议进行规定,研究端到端服务质量参数、E.164地址与IP地址之间的转换,同时规定计费和安全方面的问题。
TIPHONE工程组希望向各类网络运营者都提供面向业务的解决方案,其工作主要基于H.323系列建议和现有的电路交换网标准。
ETSITIPHONE把它的工作分为4个剧情和3个阶段。
4个剧情分别是:
①IP用户到SCN用户的通信;②SCN用户到IP用户的通信;③SCN用户之间通过IP连接;④IP用户之间通过SCN连接。
3个阶段分别是:
处理剧情①;处理剧情①和②,并修正第1个阶段的文档;处理剧情①、②、③和④,并修正前2个阶段的文档。
这些任务由6个工作组来完成,这6个工作组分别负责以下任务:
WG1处理互操作、计费和安全。
WG2处理体系结构和参考配置。
WG3处理呼叫控制过程、信息流和协议。
WG4处理命名、编号和寻址。
WG5处理服务
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IP电话网络技术 第2章 IP 电话 网络技术
![提示](https://static.bdocx.com/images/bang_tan.gif)