文档库 最新最全的文档下载
当前位置:文档库 › 03-第3章 SIP协议

03-第3章 SIP协议

目录

第3章 SIP协议........................................................................................................................ 3-1

3.1 概述.................................................................................................................................... 3-1

3.1.1 基本概念.................................................................................................................. 3-1

3.1.2 相关术语.................................................................................................................. 3-2

3.1.3 协议栈结构 .............................................................................................................. 3-5

3.1.4 SIP协议的应用........................................................................................................ 3-5

3.2 协议消息............................................................................................................................. 3-6

3.2.1 消息类型.................................................................................................................. 3-6

3.2.2 消息结构.................................................................................................................. 3-9

3.3 基本消息流程 ................................................................................................................... 3-22

3.3.1 SIP用户注册流程.................................................................................................. 3-22

3.3.2 成功的SIP用户呼叫流程 ...................................................................................... 3-25

3.3.3 成功的SIP中继呼叫流程 ...................................................................................... 3-33

3.3.4 成功的SIP-T中继呼叫流程................................................................................... 3-36

第3章 SIP协议

3.1 概述

3.1.1 基本概念

会话启动协议SIP(Session Initiation Protocol)是由IETF提出并主持研究的一个

在IP网络上进行多媒体通信的应用层控制协议,它被用来创建、修改、和终结一个

或多个参加者参加的会话进程。这些会话包括Internet多媒体会议、Internet电话、

远程教育以及远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动,

统称为多媒体会话。参加会话的成员可以通过组播方式、单播联网方式或者两者结

合的方式进行通信。

SIP协议是一个正在发展和不断研究中的协议。一方面,它借鉴了其他Internet标

准和协议的设计思想,在风格上遵循因特网一贯坚持的简练、开放、兼容和可扩展

等原则,并充分注意到因特网开放而复杂的网络环境下的安全问题。另一方面,它

也充分考虑了对传统公共电话网的各种业务,包括IN业务和ISDN业务的支持。

利用带有会话描述的SIP邀请消息来创建会话,以使参加者能够通过SIP交互进行

媒体类型协商。它通过代理和重定向请求用户当前位置,以支持用户的移动性。用

户也可以登记它们的当前位置。SIP协议独立于其他会议控制协议,它在设计上独

立于下面的传输层协议,因此可以灵活方便地扩展其他附加功能。

SIP作为一个应用层的多媒体会话信令协议,可以被用来发起一个会话进程、在会

话中邀请其他参加者加入会议,会话本身可以通过基于组播协议的会话通告协议

(SAP)、电子邮件、网页通告、以及轻量级号薄访问协议(LDAP)等方式预先通

告各个可能的参加者。SIP协议支持别名映射、重定向服务、ISDN和IN业务。它

支持个人移动(personal mobility),即终端用户能够在任何地方、任何时间请求和

获得已订购的任何电信业务。总的来说,会话启动协议能够支持下列五种多媒体通

信的信令功能:

●用户定位:确定参加通信的终端用户的位置;

●用户通信能力协商:确定通信的媒体类型和参数;

●用户意愿交互:确定被叫是否乐意参加某个通信;

●建立呼叫:包括向被叫“振铃”,确定主叫和被叫的呼叫参数;

●呼叫处理和控制:包括呼叫重定向、呼叫转移、终止呼叫等等。

SIP协议可以通过MCU(Multipoint Control Unit)、单播联网方式、或组播方式创

建多方会话,支持PSTN和因特网电话之间的网关功能。

SIP协议可以与其他用于建立呼叫的信令系统或协议结合使用,它在设计上充分考

虑了对其他协议的可扩展性。譬如,SIP协议支持的主叫可以识别出H.323协议支

持的被叫,通过H.245网关利用H.225.0协议向被叫发起并建立呼叫;另外,一个

SIP主叫可以识别出PSTN上的被叫及其电话号码,通过与PSTN相连的网关向被

叫发起并建立呼叫。

SIP协议不提供发言控制(floor control)、投票等会议控制功能,也不规定如何管

理一个会议。但是SIP协议可被用来引发这些会议控制协议。SIP协议本身不具备

资源预留功能,但可以向被邀请者们传达这方面的信息。

3.1.2 相关术语

1. 呼叫

一个呼叫是由一个公共源端所邀请的在一个会议中的所有参加者组成,由一个全球

唯一的Call-ID进行标识。

例如:由同一个源邀请的一个会议的所有参加者构成一个呼叫;点到点IP电话会话

是一种最简单的会话,它映射为单一的SIP呼叫。

通常情况下,呼叫由主叫方创建,但是更一般说来,呼叫可由并不参与媒体通信的

第三方创建,此时会话的主叫方和会话的邀请方并不相同。对于多播会议来说,一

个用户可由不同的人邀请参加同一会议,则每一个邀请应视作不同的呼叫。对于基

于MCU的会议,每个参与者使用一个呼叫邀请自己加入MCU。

2. 事务

SIP是一个客户/服务器协议。客户和服务器之间的操作从第1个请求至最终响应为

止的所有消息构成一个SIP事务。

一个正常的呼叫一般包含三个事务。其中,呼叫启动包含两个操作请求:邀请(Invite)

和证实(ACK),前者需要回送响应,后者只是证实已收到最终响应,不需要回送

响应。呼叫终结包含一个操作请求:再见(Bye)。

3. SIP URL

为了能正确传送协议消息,SIP还需解决两个重要的问题。一是寻址,即采用什么

样的地址形式标识终端用户;二是用户定位(下面介绍)。SIP沿用WWW技术解

决这两个问题。

寻址采用SIP URL(Uniform Resource Locators),按照RFC2396规定的URI导则定义其语法,特别是用户名字段可以是电话号码,以支持IP电话网关寻址,实现IP电话和PSTN的互通。

SIP URL的一般结构为:

SIP:用户名:口令@主机:端口;传送参数;用户参数;方法参数;生存期参数;服务器地址参数?头部名=头部值

“SIP”表示需采用SIP协议和所指示的端系统通信。

“用户名”可以由任意字符组成,一般可取类似与E-mail用户名形式,也可以是电话号码(SoftX3000目前用户名是电话号码)。

“主机”可为主机域名或IPv4地址。

“端口”指示请求消息送往的端口号,其缺省值为5060,即公开的SIP端口号。

“口令”可以置于SIP URL中,但一般不建议这样做,因为其安全性是有问题的。

“传送参数”指示采用TCP还是UDP传送,缺省值为UDP。

“用户参数”,SIP URL的一个特定功能是允许主机类型为IP电话网关,此时,用户名可以为一般的电话号码。由于BNF语法表示无法区分电话号码和一般的用户名,因此,在域名后增加了“用户参数”字段。该字段有两个可选值:IP和电话,当其设定为“电话”时,表示用户名为电话号码,对应的端系统为IP电话网关。

“方法参数”指示所用的方法(操作)。

“生存期参数”指示UDP多播数据包的寿命,仅当传送参数为UDP、服务器地址参数为多播地址时才能使用。

“服务器地址参数”指示和该用户通信的服务器的地址,它覆盖“主机”字段中的地址,通常为多播地址。

“传送参数”、“生存期参数”、“服务器地址参数”和“方法参数”均属于URL 参数,只能在重定向地址,即后面所说的Contact字段中才能使用。

下面给出若干个SIP URL的示例:

Sip; 55500200@191.169.1.112;

55500200为用户名,191.169.1.112为IP电话网关的IP地址。

Sip; 55500200@127.0.0.1:5061; User=phone;

55500200为用户名,127.0.0.1为主机的IP地址,5061为主机端口号。用户参数为“电话”,表示用户名为电话号码。

Sip: alice@https://www.wendangku.net/doc/eb15613862.html,; method=REGISTER;

Alice为用户名,https://www.wendangku.net/doc/eb15613862.html,为主机域名。方法参数为“登记”。

4. 用户定位

用户定位基于登记。SIP用户终端上电后即向登记服务器(SoftX3000)登记,SIP 专门为此定义了一个“登记”(REGISTER)请求消息,并规定了登记操作过程。

5. 定位服务(Location Service)

SIP重定位服务器或代理服务器用来获得被叫位置的一种服务,可由定位服务器提供,但SIP协议不规定SIP服务器如何请求定位服务。在华为U-SYS解决方案中,SoftX3000兼任定位服务器的角色。

6. 代理,代理服务器(Proxy、Proxy sever)

作为一个逻辑网络实体代表客户端转发请求或者响应,可以同时作为客户端和服务器端。代理服务器有三种形态:Stateless、Statefull和Call Stateful,其可以采用分支、循环等方式向多个地址尝试转发请求。

代理服务器的主要功能:路由、认证鉴权、计费监控、呼叫控制、业务提供等。在华为U-SYS解决方案中,SoftX3000兼任代理服务器的角色。

7. 重定向服务器(Redirect server)

重定向服务器将请求中的目的地址映射为零个或多个新的地址,然后返回给客户端,客户端直接再次向这些新的地址发起请求。重定向服务器并不接收或者拒绝呼叫,主要完成路由功能,与注册过程配合可以支持SIP终端的移动性。在华为U-SYS解决方案中,SoftX3000兼任重定向服务器的角色。

8. 注册员(Registrar)

注册员为接收注册请求的服务器,通常与Proxy或者Redirect Server共存。注册员需要将注册请求中的地址映射关系保存到数据库中,供后续的相关呼叫过程使用,同时可以提供定位服务。在华为U-SYS解决方案中,SoftX3000兼任注册员的角色。

9. 用户助理(User Agent)

用来发起或者接收请求的逻辑实体称为User Agent。

10. 用户助理客户(User Agent Client)

发起请求的一方称为UAC(User Agent Client),举例SIP Phone就是UAC的一种实际形态。

11. 用户助理服务器(User Agent Server)

接收请求的一方称为UAS(User Agent Server),举例SoftX3000就是UAS的一

种实际形态。

注意:UAC和UAS的划分是针对一个事务而言的。

3.1.3 协议栈结构

SIP协议栈结构如图3-1所示。

H.323SIP RTSP RSVP RTCP

H.263 etc.

RTP

TCP UDP

IP

PPP Sonet AAL3/4AAL5

ATM Ethernet

PPP

V.34图3-1SIP协议栈

SIP协议是IETF多媒体数据和控制体系结构的一部分,与其它协议相互合作,例如:

RSVP(Resource ReServation Protocol)用于预约网络资源,RTP(Real-time

Transmit Protocol)用于传输实时数据并提供服务质量(QoS)反馈,RTSP

(Real-Time Stream Protocol)用于控制实时媒体流的传输,SAP(Session

Announcement Protocol)用于通过组播发布多媒体会话,SDP(Session Description

Protocol)用于描述多媒体会话。但是SIP协议的功能和实施并不依赖这些协议。

传输层支持:SIP协议承载在IP网,网络层协议为IP,传输层协议可用TCP或UDP,

推荐首选UDP。

3.1.4 SIP协议的应用

SoftX3000通过SIP/SIP-T与其它软交换系统互通,以及与其它SIP域设备(如SIP

Phone,SIP Softphone等)互通,SIP协议在NGN中的典型应用如图3-2所示:

£?

SIP SoftPhone

SIP Phone

图3-2 SIP 在NGN 中的典型应用

3.2 协议消息

3.2.1 消息类型

SIP 消息采用文本方式编码,分为两类:请求消息和响应消息。

1. 请求消息

用于客户端为了激活按特定操作而发给服务器的SIP 消息,包括INVITE , ACK ,OPTIONS ,BYE ,CANCEL 和REGISTER

消息等,各消息功能如表3-1所示。

表3-1 请求消息

2. 响应消息

用于对请求消息进行响应,指示呼叫的成功或失败状态。不同类的响应消息由状态码来区分。状态码包含三位整数,状态码的第一位用于定义响应类型,另外两位用于进一步对响应进行更加详细的说明。各响应消息分类和含义如表3-2所示。

表3-2响应消息

请求消息和响应消息都包括SIP头字段和SIP消息字段。

在SIP消息中加入SDP消息正文部分。

3.2.2 消息结构

1. 请求消息

(1) 请求消息结构

如图3-3所示是SIP请求命令的格式,由起始行、消息头和消息体组成。通过换行

符区分消息头中的每一条参数行。对于不同的请求消息,有些参数可选。

图3-3SIP请求消息结构

(2) 请求消息参数

下面仅对几个常用的参数字段进行说明。

Call-ID

该字段用以唯一标识一个特定的邀请或标识某一客户的所有登记。

需要注意的是,一个多媒体会议可能会有多个呼叫,每个呼叫有其自己的Call-ID。例如,某用户可数次邀请某人参加同一历时很长的会议。用户也可能会收到数个参加同一会议或呼叫的邀请,其Call-ID各不相同。用户可以利用会话描述中的标识,例如SDP中的o(源)字段的会话标识和版本号判定这些邀请的重复性。

Call-ID的一般格式为:

Call-ID:本地标识@主机

其中,主机应为全局定义域名和全局可选路IP地址,此时,本地标识由在“主机”范围内唯一的URI字符组成。否则,本地标识必须是全局唯一的值,以保证Call-ID 的全局唯一性。Call-ID字符需区分大小写。

Call-ID示例:

Call-Id: call-973636852-4@191.169.150.101

其中,191.169.150.101为主机的IP地址,call-973636852-4为全局唯一的本地标识。

●From

所有请求和响应必须包含此字段,以指示请求的发起者。服务器将此字段从请求消息复制到响应消息。

该字段的一般格式为:

From:显示名;tag=xxxx

其中,显示名为用户界面上显示的字符,如果系统不予显示,应置显示名为“匿名(Anonymous)”。显示名为任选字段。tag称为标记,为16进制数字串,中间可带连字符“-”。当两个共享同一SIP地址的用户实例用相同的Call-ID发起呼叫邀请时,就需用此标记予以区分。标记值必须全局唯一。用户在整个呼叫期间应保持相同的Call-ID和标记值。

From字段的示例:

From: ;tag=1c17691

●To

该字段指明请求的接收者,其格式和From相同,仅第一个关键词代之以To。所有请求和响应消息必须包含此字段。

字段中的标记参数可用于区分由同一SIP URL标识的不同的用户实例。由于代理服务器可以并行分发多个请求,同一请求可能到达用户的不同实例(如住宅电话等)。由于每个实例都可能响应,因此需用标记来区分来自不同实例的响应。需要注意的是,To字段中的标记是由每个实例至于响应消息中的。

To字段的示例:

To:

To: ;tag=62beb3ca

注意,在SIP中,Call-ID、From和To三个字段标识一个呼叫分支。在代理服务器并行分发请求时,一个呼叫可能会有多个呼叫分支。

●Cseq

Cseq称之为命令序号。客户在每个请求中应加入此字段,它由命令名称和一个十进制序号组成,该序号由请求客户选定,在Call-ID范围内唯一确定。序号初值可为任

意值,其后具有相同Call-ID值,但不同命令名称、消息体的请求,其Cseq序号应加1。重发请求的序号保持不变。服务器将请求中的Cseq值复制到响应消息中,用于将请求和其触发的响应相关联。

ACK和CANCEL请求的Cseq值(十进制序号)和对应的INVITE请求相同,BYE 请求的Cseq序号应大于INVITE请求。服务器必须记忆相同Call-ID的INVITE请求的最高序号,收到序号低于此值的INVITE请求应在给出响应后予以丢弃。

由代理服务器并行分发的请求,其Cseq值相同。严格来说,Cseq对于任何可由BYE或CANCEL请求取消的请求以及客户可连续发送多个具有相同Call-ID请求的情况都是需要的,其作用是判定响应和请求的对应关系。

Cseq字段的示例:

Cseq: 1 INVITE

Via

Via字段用以指示请求历经的路径。它可以防止请求消息传送产生环路,并确保响应和请求消息选择同样的路径,以保证通过防火墙或满足其它特定的选路要求。

发起请求的客户必须将其自身的主机名或网络地址插入请求的Via字段,如果未采用缺省端口号,还需插入此端口号。在请求前传过程中,每个代理服务器必须将其自身地址作为一个新的Via字段加在已有的Via字段之前。如果代理服务器收到一个请求,发现其自身地址位于Via头部中,则必须回送响应“检测到环路”。

当请求消息通过网络地址翻译点(如防火墙)时,请求的源地址和端口号可能被改变,此时Via字段就不能成为响应消息选路的依据。为了防止这一点,代理服务器应校验顶端Via字段,如果发现其值和代理服务器检测到的前站地址不符,则应在该Via字段中加入“receive”参数,如此修改后的字段称为“接收方标记Via头部字段”。例如:

Via:SIP/2.0/UDP https://www.wendangku.net/doc/eb15613862.html,:5060

Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30

由点10.0.0.1发出的请求消息路径外部地址为191.169.12.30的网络地址翻译点后,到达代理服务器https://www.wendangku.net/doc/eb15613862.html,。后者注意到前站发送地址和Via字段地址不符,就把实际发送地址作为接收方标记加在顶端Via字段的末尾,然后再将代理自己的地址作为新加的Via字段置于最上面。

若代理服务器向多播地址发送请求,则必须在其Via头部字段中加入“多播地址(maddr)”参数,此参数指明该多播地址。

代理服务器或UAC收到Via头部字段时的处理规则是:

规则1:第1个Via头部字段应该指示本代理服务器或UAC。如果不是,丢弃该消息,否则,删除该Via字段。

规则2:如果没有第2个Via头部字段,则该响应已经到达目的地。否则,继续做如下处理。

规则3:如果第2个Via头部字段包含“maddr”参数,则按该参数指示的多播地址发送响应,端口号由“发送方”参数指明,如未指明,就使用端口号5060。响应的生存期应置为“生存期(ttl)”参数指定的值,如未指明,则置为1。

规则4:如果第2个Via字段不包含“maddr”参数,但有一个接收方标记字段,则应将该响应发往“received”参数指示的地址。

规则5:如果既无“maddr”参数又无标记,就按发送方参数指示的地址发送响应。

Via字段的一般格式为:

Via:发送协议发送方;隐藏参数;生存期参数;多播地址参数;接收方标记,分支参数

其中,发送协议的格式为:协议名/协议版本/传送层,协议名和传送层的缺省值分别为SIP和UDP。发送方为通常的发送方主机和端口号。隐藏参数就是关键词hidden,如有此参数,表示该字段已由上游代理予以加密,以提供隐私服务。多播地址参数和接收方标记的意义如前所述。生存期参数与多播地址参数配用。分支参数用于代理服务器并行分发请求时标记各个分支,当响应到达时,代理可判定是哪一分支的响应。

Via字段的示例:

Via:SIP/2.0/UDP191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=z9hG4b kbc427dad6

Contact

该字段用于INVITE、ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息,其作用是给出其后和用户直接通信的地址。

INVITE和ACK请求中的Contact字段指示该请求发出的位置。它使被叫可以直接将请求(如BYE请求)发往该地址,而不必借助Via字段经由一系列代理服务器返回。

对INVITE请求的成功响应消息可包含Contact字段,它使其后SIP请求(如ACK 请求)可直接发往该字段给定的地址。该地址一般是被叫主机的地址,如果该主机位于防火墙之后,则为代理服务器地址。

对应于INVITE请求的呼叫进展响应消息中包含的Contact字段的含义和成功响应消息相同。但是,CANCEL请求不能直接发往该地址,必须沿原请求发送的路径前传。

REGISTER请求中的Contact字段指明用户可达位置。该请求还定义了通配Contact 字段“*”,它只能和值为0的“失效”字段配用,表示去除某用户的所有登记。Contact

字段也可设定“失效”参数(任选),给定登记的失效时间。如果没有设定该参数,则用“失效”字段值作为其缺省值。如果两者均无,则认为SIP URI的失效时间为1小时。

REGISTER请求的成功响应消息中的Contact字段返回该用户当前可达的所有位置。

重定向响应消息,如用户临时迁移、永久迁移、地址模糊等消息中的Contact字段给出供重试的其它可选地址,可用于对BYE、INVITE和OPTIONS请求的响应消息。

Contact字段的一般格式为:

Contact:地址;q参数;动作参数;失效参数;扩展属性

其中,地址的表示形式和To,From字段相同。q参数,其取值范围为[0,1],指示给定位置的相对优先级。数值越大,优先级越高。动作参数仅用于REGISTER请求。它表明希望服务器对其后至该客户的请求进行代理服务还是重定向服务。如果未含此参数,则执行动作取决于服务器的配置。失效参数指明URI的有效时间,可用秒表示,也可用SIP日期表示。扩展属性就是扩展名。

Contact字段的示例为:

Contact: ;q=0.7;expires=3600

●Max-Forwards

该字段用于定义一个请求到达其目的地址所允许经过的中转站的最大值。请求每经过一个中转站,该值减1。如果该值为0时该请求还没有到达其目的地址,服务器将回送“483”(Too Many Hops)响应并终止这个请求。

设置该字段的目的主要是为了出现环路时不会一直消耗代理服务器的资源。该字段的初始值为70。

Max-Forwards字段的一般格式为:

Max-Forwards:十进制整数

●Allow

该字段给出代理服务器支持的所有请求消息类型列表。

Allow字段的示例:

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

●Content-Length

该字段表示消息体的大小,为十进制值。应用程序使用该字段表示要发送的消息体的大小,而不考虑实体的媒体类型。如果使用基于流的协议(如TCP协议)作为传输协议,则必须使用此消息头字段。

消息体的长度不包括用于分离消息头部和消息体的空白行。 Content-Length值必须大于等于0。如果消息中没有消息体,则Content-Length头字段值必须设为0。

SDP用于构成请求消息和2xx响应消息的消息体。

Content-Length字段的一般格式为:

Content-Length:十进制值

Content-Length字段的示例:

Content-Length: 349

表示消息体的长度为349个字节。

●Content-Type

Content-Type字段表示发送的消息体的媒体类型。如果消息体不为空,则必须存在Content-Type 头字段。如果消息体为空且Content-Type 头字段存在,则表示此类型的消息体长度为0 (如一个空的声音文件)。

Content-Type字段的示例:

Content-Type: application/sdp

●Supported

SIP协议中定义的100类临时响应消息的传输是不可靠的,即UAS发送临时响应后并不能保证UAC端能够接受到该消息。

如果需要在该响应消息中携带媒体信息,那么就必须保证该消息能够可靠的传输到对端。100rel扩展为100类响应消息的可靠传输提供了相应的机制。100rel新增加对临时响应消息的确认请求方法:PRACK。

如果UAC支持该扩展,则在发送的消息中增加Supported:100rel头域和字段。如果UAS支持该扩展,则在发送100类响应时增加Require:100rel头域和字段。UAC 收到该响应消息后需要向UAS发送PRACK请求通知UAS已收到该临时响应。UAS 向UAC发送对PRACK的2XX响应消息结束对该临时响应的确认过程。

如果某一UA想要在发送的临时响应消息中携带SDP消息体,那么UAC和UAS都必须支持和使用100rel扩展以保证该消息的可靠传输。

举例:

Supported: 100rel

●User-Agent

User-Agent头字段包含有发起请求的用户终端的信息。

显示用户代理的软件版本信息可能会令用户在使用有安全漏洞的软件易受到外界攻击,因此,应该使User-Agent头字段成为可选配置项。

举例:

User-Agent: Softphone Beta1.5

●Expires

Expires头字段指定了消息(或消息内容)多长时间之后超时。

举例:

Expires: 5

●Accept-Language

Accept-Language头字段用在请求消息中,表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言类型。如果消息中没有Accept-Language头字段,则服务器端认为客户端支持所有语言。

举例:

Accept-Language: en

●Authorization

Authorization字段包含某个终端的鉴权证书。

首先介绍一下终端向服务器端请求认证的一般过程:

终端发起请求时如果服务器端需要对用户进行认证,那么会在本地产生本次认证的NONCE,并且通过认证请求头域将所有必要的参数返回给终端从而发起对用户认证过程。

终端收到认证请求消息后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE,并且通过新的请求消息发送给服务器端。

服务器端在收到带有认证响应的新的请求消息后首先检查NONCE的正确性。如果NONCE不是本地产生,则直接返回失败。否则如果NONCE是本地产生,但是认证过程已经超时,则服务器端会重新产生NONCE并重新发起对用户的认证过程。其中老的NONCE会通过CNONCE参数返回。

NONCE验证通过后服务器端会根据NONCE、用户名、密码(服务器端可以根据本地用户信息获取用户的密码)、URI等采用和终端相同的算法生成RESPONSE,并且对此RESPONSE和请求消息中的RESPONSE进行比较,如果二者一致则用户认证成功,否则认证失败。

Authorization字段的一般格式为:

Authorization:认证方式 USERNAME,REALM,NONCE,RESPONSE,URI,CNONCE,ALGORITHM

认证方式:有DIGEST、BASIC、CHAP-PASSWORD、CARDDIGEST等认证方式。DIGEST为HTTP-DIGEST认证方式。目前SoftX3000只支持HTTP-DIGEST

方式。以后为了实现Uniphone的卡号呼叫还会加入卡号认证的CARDDIGEST方式。

USERNAME:被认证的用户的用户名。

REALM:用于标识发起认证过程的域。

NONCE:由发起认证过程的实体产生的加密因子。

RESPONSE:终端在收到服务器的认证请求后根据服务器端产生的NONCE、用户名、密码、URI等信息经过一定的算法生成的一个字符串。该字符串中包含了经过加密后的用户密码。(在认证过程中处理用户密码之外其他信息都会通过SIP消息以明文的方式在终端和服务器端进行传递。)

URI:发起的呼叫请求消息的Request-URI。由于终端在收到认证请求后需要重新向服务器端发起请求(其中带有认证响应信息)。该请求消息在经过网络服务器时某些字段包括Request-URI都有可能被修改。认证头域的URI参数用于传递终端发起请求时原始消息的Request-URI用于对认证信息进行认证,这样才能保证认证过程的正确性。

CNONCE:如果在服务器端超时后终端才向服务器返回了带有认证响应的新的请求消息,则服务器端需要重新产生NONCE重新对用户进行认证。其中NONCE中带有新的NONCE,老的NONCE会通过CNONCE参数返回给终端。

ALGORITHM:用于传递生成RESPONSE的算法。

举例:

Authorization: DIGEST USERNAME="6540012", REALM="https://www.wendangku.net/doc/eb15613862.html,", NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6", URI="sip:191.169.150.30"

(3) 请求消息示例

下面是SIP请求消息编码的示例:

INVITE sip:66500002@191.169.1.110 SIP/2.0

From: ;tag=1ccb6df3

To:

CSeq: 1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000

Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6

Contact:

Supported: 100rel,100rel

Max-Forwards:70

Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,N OTIFY,MESSAGE,REFER

Content-Length:230

Content-Type: application/sdp

v: 0

o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.1.116

s: Sip Call

c: IN IP4 191.169.1.95

t: 0 0

m: audio 30000 RTP/AVP 8 0 4 18

a: rtpmap:8 PCMA/8000

a: rtpmap 0 PCMU/8000

a: rtpmap 4 G723/8000

a: rtpmap 18 G729/8000

第一行:请求起始行。INVITE请求消息。请求URI,即被邀用户的当前地址为“sip:66500002@191.169.1.110”。SIP版本号为2.0。

第二行:From字段。指明请求发起方的地址为“”。标记为“1ccb6df3”,用于共享同一SIP地址的不同用户用相同的Call-ID发起呼叫邀请时,对用户进行区分。

第三行:To字段。指明请求接收方的地址为“”。

从From和To字段,我们可以看出:

IP地址为191.169.1.116的MGC控制下的终端44510000拨打IP地址为191.169.1.110的MGC控制下的66500002终端。终端类型可以为SIP、H.323、IAD/AG下挂的ESL等。

第四行:Cseq字段。用于将INVITE请求和其触发的响应、对应的ACK、CANCEL 请求相关联。

第五行:Call-ID字段。该字段唯一标识一个特定的邀请,全局唯一。Call-ID为“20973e49f7c52937fc6be224f9e52543@sx3000”,sx3000为发起呼叫的SoftX3000的域名,20973e49f7c52937fc6be224f9e52543为本地标识。

第六行:Via字段。该字段用于指示该请求历经的路径。“SIP/2.0/UDP”表示发送的协议,协议名为“SIP”,协议版本为2.0,传输层为UDP;“191.169.1.116:5061”表示发送方SoftX3000 IP地址为191.169.1.116,端口号为5061;“branch=z9hG4bkbc427dad6”为分支参数,SoftX3000并行分发请求时标记各个分支。

第七行:Contact字段。指示其后的请求(如BYE请求)可以直接发往,而不必借助Via字段。

第八行:100rel扩展,该字段为100类响应消息的可靠传输提供了相应的机制。

第九行:Max-Forwards字段。表示该请求到达其目的地址所允许经过的中转站的最大值为70。

第十行:Allow字段。给出IP地址为191.169.1.116的SoftX3000支持的请求消息类型列表。

第十一行:Content-Type字段,表示消息中携带的消息体是单消息体且为SDP。

第十二行:空行,表示下面为SDP会话描述。

第十三行:SDP协议版本号,目前为0版本。

第十四行:会话拥有者/创建者和会话标识,用于给出会话的发起者(其用户名和用户主机地址)以及会话标识和会话版本号。“HuaweiSoftX3000”为用户名,用户名是用户在发起主机上的登录名,如果主机不支持用户标识的概念,该字段标记为“-”。第一个“1073741831”为会话标识,会话标识为一数字串,使得多元组(用户名、会话标识、网络类型、地址类型、地址)构成会话的全球唯一的标识符。第二个“1073741831”为版本号,指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。其基本要求是会话数据修改后,其版本号应递增。“IN”指网络类型,为文本串形式,目前规定的“IN”为Inernet。“IP4”指地址类型,为文本串形式,目前已定义的有“IP4”和“IP6”两种。“191.169.1.116”为创建会话的主机的IP地址。对于IP4地址类型,可以是域名全称或点分十进制IP4地址表示形式。对于IP6地址类型,可以是域名全称或压缩文本IP6地址表示形式。

第十五行:会话名。每个会话描述必需有一个且只有一个会话名。

第十六行:连接数据。网络类型和地址类型目前的定义值仅限于IN和IP4。“191.169.1.95”为SoftX3000(IP地址:191.169.1.116)控制下的MG的IP地址(终端类型为IAD/AG下挂的ESL电话)或SIP、H.323终端的IP地址(终端类型为SIP、H.323电话)。

第十七行:时间描述,给出会话激活的时间区段,允许会话周期性发生。“0”表示起始时间。该字段的格式为t:<起始时间><终止时间>。其中起始时间和终止时间值为NTP(Network Time Protocol)时间值的十进制表示,单位为秒。

第十八行:媒体级描述,该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。目前定义的媒体类型有5种:音频、视频、应用、数据和控制。“30000”指明媒体流发往的传送层端口,即MG的UDP端口号(终端类型为IAD/AG下挂的ESL电话)或SIP、H.323终端的UDP端口号(终端类型为SIP、H.323电话)。“RTP/AVP”为传送层协议,其值和“c”行中的地址类型有关,对于IP4来说,大多数媒体业务流都在RTP/UDP上传送,已定义如下两类协议:RTP/AVP,音频/视频应用文档,在UDP上传送;Udp,UDP协议。“8 0 4 18”对于音频和视频来说,就是RTP音频/视频应用文档中定义的媒体静荷类型。表示会话中所有这些格式都可能被用到,但第一个格式是会话的缺省格式。

SIP协议呼叫流程及协议分析

一、SIP协议介绍: 会话发起协议SIP(Session Initiation Protocol)是一个应用层控制信令协议,用于建立、更改和终止多媒体会话或呼叫。SIP作为一个基础,可以在其上提供很多不同的服务。目前已经定义的媒体类型有音频、视频、应用、数据、控制。 二、SIP呼叫流程: 注册流程: (1)用户首次试呼时,终端代理A 向代理服务器发送REGISTER 注册请求; (2)代理服务器通过后端认证/计费中心获知用户信息不在数据库中,便向终端代理回送401Unauthorized 质询信息,其中包含安全认证所需的令牌; (3)终端代理提示用户输入其标识和密码后,根据安全认证令牌将其加密后,再次用REGISTER 消息报告给代理服务器; (4)代理服务器将REGISTER 消息中的用户信息解密,通过认证/计费中心验证其合法后,将该用户信息登记到数据库中,并向终端代理A 返回成功响应消息200 OK。 呼叫流程:

(1)用户摘机发起一路呼叫,终端代理A 向该区域的代理服务器发起Invite 请求;(2)代理服务器通过认证/计费中心确认用户认证已通过后,检查请求消息中的Via 头域中是否已包含其地址。若已包含,说明发生环回,返回指示错误的应答;如果没有问题,代理服务器在请求消息的Via 头域插入自身地址,并向Invite 消息的To 域所指示的被叫终端代理B 转送Invite 请求; (3)代理服务器向终端代理A 送呼叫处理中的应答消息,100 Trying; (4)终端代理B 向代理服务器送呼叫处理中的应答消息,100 Trying; (5)终端代理B 指示被叫用户振铃,用户振铃后,向代理服务器发送180 Ringing 振铃信息; (6)代理服务器向终端代理A 转发被叫用户振铃信息; (7)被叫用户摘机,终端代理B 向代理服务器返回表示连接成功的应答(200 OK);(8)代理服务器向终端代理A 转发该成功指示(200 OK); (9)终端代理A 收到消息后,向代理服务器发ACK 消息进行确认; (10)代理服务器将ACK 确认消息转发给终端代理B; (11)主被叫用户之间建立通信连接,开始通话; 结束流程:

sip协议原理分析及总结

SIP协议学习总结 1、SIP协议定义 SIP(Session Initiation Protocol,即初始会话协议)是IETF提出的基于文本编码的IP电话/多媒体会议协议。用于建立、修改并终止多媒体会话。SIP 协议可用于发起会话,也可以用于邀请成员加入已经用其它方式建立的会话。多媒体会话可以是点到点的话音通信或视频通信,也可以是多点参与的话音或视频会议等。SIP协议透明地支持名字映射和重定向服务,便于实现ISDN,智能网以及个人移动业务。SIP协议可以用多点控制单元(MCU)或全互连的方式代替组播发起多方呼叫。与PSTN相连的IP电话网关也可以用SIP协议来建立普通电话用户之间的呼叫。 SIP协议在IETF多媒体数据及控制体系协议栈结构的位置 H.323SIP RTSP RSVP RTCP H.263 etc. RTP TCP UDP IP PPP Sonet AAL3/4AAL5 ATM Ethernet PPP V.34 SIP协议支持多媒体通信的五个方面: ◆用户定位:确定用于通信的终端系统; ◆用户能力:确定通信媒体和媒体的使用参数; ◆用户有效性:确定被叫加入通信的意愿; ◆会话建立:建立主叫和被叫的呼叫参数; ◆会话管理:包括呼叫转移和呼叫终止; SIP协议的结构 SIP是一个分层的协议,也就是说SIP协议由一组相当无关的处理层次组成,这些层次之间只有松散的关系。 SIP最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar (BNF范式)。 第二层是传输层。它定义了一个客户端发送请求和接收应答的方式,以及一 个服务器接收请求和发送应答的方式。所有的SIP要素都包含一个通讯层。 第三层是事务层。事务是SIP的基本组成部分。一个事务是UAC向UAS发送的一个请求以及UAS向UAC发送的一系列应答。事务层处理应用服务层的重发,匹配请求的应答,以及应用服务层的超时。任何一个用户代理客户端完成的事情都是

SIP协议相关文件

Osip2是一个开放源代码的sip协议栈,是开源代码中不多使用C语言写的协议栈之一,它具有短小简洁的特点,专注于sip底层解析使得它的效率比较高。 eXosip是Osip2的一个扩展协议集,它部分封装了Osip2协议栈,使得它更容易被使用。 一、介绍 Osip2是一个开放源代码的sip协议栈,是开源代码中不多使用C语言写的协议栈之一,它具有短小简洁的特点,专注于sip底层解析使得它的效率比较高。但缺点也专门明显,首先确实是可用性差,没有专门好的api封装,使得上层应用在调用协议栈时专门破裂;其次,只做到了transaction层次的协议过程解析,

缺少call、session、dialog等过程的解析,这也增加了使用的难度;再次,缺少线程并发处理的机制,使得它的处理能力有限。 eXosip是Osip2的一个扩展协议集,它部分封装了Osip2协议栈,使得它更容易被使用。eXosip增加了call、dialog、registration、subscription等过程的解析,使得有用性更强。然而eXosip局限于UA的实现,使得它用于registrar、sip server等应用时极其不容易。另外,它并没有增加线程并发处理的机制。而且只实现了音频支持,缺少对视频和其它数据格式的支持。 综合来讲,Osip2加上eXosip协议栈仍然是个实现Sip协议不错的选择。因此需要依照不同的需求来增加更多的内容。 二、Osip2协议栈的组成 Osip2协议栈大致能够分为三部分:sip协议的语法分析、sip 协议的过程分析和协议栈框架。 1、Sip协议的语法分析:

要紧是osipparser2部分,目前支持RFC3261和RFC3265定义的sip协议消息,包括INVITE、ACK、OPTIONS、CANCEL、BYE、SUBSCRIBE、NOTIFY、MESSAGE、REFER和INFO。不支持RFC3262定义的PRACK。 遵循RFC3264关于SDP的offer/answer模式。带有SDP的语法分析。 支持MD5加解密算法。支持Authorization、www_authenticate 和proxy_authenticate。 2、Sip协议的过程分析: 要紧是osip2部分,基于RFC3261、RFC3264和RFC3265的sip 协议描述过程,围绕transaction这一层来实现sip的解析。 Transaction是指一个发送方和接收方的交互过程,由请求和应答组成。请求分为Invite类型和Non-Invite类型。应答分为响应型的应答和确认型的应答。响应型的应答是指那个应答仅代表

SIP协议主要消息讲解

第一章SIP协议主要消息 1.1 SIP消息分类 SIP协议是以层协议的形式组成的,就是说它的行为是以一套相对独立的处理阶段来描述的,每个阶段之间的关系不是很密切。 SIP协议将Server和User Agent之间的通讯的消息分为两类:请求消息和响应消息。 请求消息:客户端为了激活特定操作而发给服务器的SIP消息,包括INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。 SIP请求的6种方法: 1、邀请(INVITE)——邀请用户加入呼叫 2、确认(ACK)——确认客户机已经接收到对INVITE的最终响应 3、可选项(OPTIONS)——请求关于服务器能力的信息 4、再见(BYE)——终止呼叫上的两个用户之间的呼叫 5、取消(CANCEL) 6、注册(REGISTER)——提供地址解析的映射,让服务器知道其它用户的位置 响应消息:服务器向客户反馈对应请求的处理结果的SIP消息,包括1xx、2xx、3xx、4xx、5xx、6xx响应 1.2 SIP消息结构 请求消息和响应消息都包括SIP消息头字段和SIP消息体字段; SIP消息头主要用来指明本消息是有由谁发起和由谁接受,经过多少跳转等基本信息; SIP消息体主要用来描述本次会话具体实现方式; 1.3 消息格式 1.3.1 请求消息格式 SIP请求消息的格式,由SIP消息头和一组参数行组成,如图1-1所示。通过换行符区分命令行和每一条参数行。

图1-1 SIP 请求消息结构 注意:参数行的顺序不是固定的。对应的参数解释见错误!未找到引用源。。 消息体定义: Call-ID :头字段是用来将消息分组的唯一性标识 From :头字段是指示请求发起方的逻辑标识,它可能是用户的注册地址。From 头字段包含一个URI 和一个可选的显示名称 CSeq :头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成,请求方法必须与对应的请求消息类型一致 Max-Fowords :头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值,每经过一跳,这个值就被减一。如果在请求消息到达目的地之前该值变为零,那么请求将被拒绝并返回一个483(跳数过多)错误响应消息。 Via :头字段定义SIP 事务的下层(传输层)传输协议,并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后,才能在请求消息中加入Via 头字段值。 expires :参数指出了该值中包含的URI 地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数,那么URI 地址的有效期由Expires 头字段值来确定。 消息头

SIP协议格式详解

1.SIP 1.1.1.SIP格式 每条SIP消息由以下三部分组成: (1)起始行(Start Line):每个SIP消息由起始行开始。起始行传达消息类型(在请求中是方法类型,在响应中是响应代码)与协议版本。起始行可以是一请求行(请求)或状态行(响应)。 (2)SIP头:用来传递消息属性和修改消息意义。它们在语法和语义上与HTTP头域相同(实际上有些头就是借自HTTP),并且总是保持格式:<名字>:<值>。 (3)消息体:用于描述被初始的会话(例如,在多媒体会话中包括音频和视频编码类型,采样率等)。消息体能够显示在请求与响应中。SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP 范围之外的会话描述信息。可能的体类型就包括本文将要描述的SDP会话描述协议。

1.1. 2.消息头 Header field where proxy ACK BYE CAN INV OPT REG Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o

Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alter-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * Cseq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o o Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c - o o o o o Retry-After 404, 413,

SIP协议与视频通信

SIP协议与视频通信 关键字:SIP视频通信H.323 摘要:文章简要概述现有视频通信技术,包括H.320与H.323应用。然后介绍IETF可以用于视频通信的协议:SIP。在SIP介绍中首先描述SIP协议的历史,然后描述SIP的组成部件。明确部件后举例说明了一个SIP呼叫建立的流程。在第四部分通过与H.323协议族比较来说明SIP用于视频通信的优劣。最后指出SIP协议用于视频通信的前景。 引言 沟通是人类生存的基本需求,通信已成为现代生活中必不可少的内容。在任何时间,任何地点与人和人通信是电信发展的目标。通信技术发展到今天,电话网几乎覆盖全球。语音通信(电话)似乎已基本达到上述目标。但是随着技术的发展,人们已不满足仅仅语音通信。大规模视频通信已成为下一阶段信息产业发展方向。虽然电视会议已出现二十多年,当前不但统一的标准而且有成熟的产品;但是由于种种原因一直没有得到象电话那样的普遍应用。视频通信似乎一直是一座未被足量开采的金矿。随着传输技术的发展,带宽资源已不是瓶颈;随着一场SARS的肆虐,视频通信又成为热点。随着SIP协议的出现,视频通信在技术上又有了新的发展动力。 视频通信协议概述 基于H.320的视频应用 传统会议电视利用以电话网2M或者1.544M直联数字线路连接终端会议电视设备进行实时音频、视频和数据信息的传送。通过使用多点控制器,可以在一块控制板具备所有主会场的操作切换功能。最初会议电视厂家以各自专用的压缩和通信算法进行生产,各个会议电视厂家产品无法互联互通。 随着ITU-T推出H.320协议,上述问题得到很大程度的解决。H.320是同步电路交换网(如ISDN)上现频传输的标准。电路交换网适用于实时应用,如长时间和具有确定延迟的音频和视频信号传递。电路的建立依赖于带外信令、集中的路由控制和昂贵的交换设备。使用H.320协议,电话网上中商用会议电视的理想电路是384 kbps。使用384kbps的电路可以以合理的成本提供高质量的音频和视频信号。采用2M或者1.544M的中继直连当然很容易满足上述带宽要求,但是作等于建立专网,价格将令用户难以承受。 由于电话网络中继价格不断下降以及大量既成事实的基于H.320的电视会议应用,虽然H.320通信成本相对于现有的其它方式稍显昂贵,但其市场仍将在未来数年里继续成长——尽管其成长是缓慢的。 基于H.323协议的视频应用 H.323是国际电信联盟制定的局域网上的多媒体通信系列标准。该协议专门为不提供服务质量(QOS)保证的局域网技术制定,例如运行于以太网、快速以太网和令牌环网(Token Ring)上的TCP/IP和IPX。尽管H.323协议特别为局域网制定,只要带宽时延满足要求同样可以应用在更大范围例如城域网和广域网。1997年5月,国际电信联盟第15研究小组重新定义

SIP协议介绍及应用前景分析

2017年第2期信息通信2017 (总第170 期)INFORM ATION & COMMUNICATIONS (Sum. No 170) SIP协议介绍及应用前景分析 杜鑫 (中国人民解放军9155〇部队3分队) 摘要:S IP是一种源于互联网的IP语音会话控制协议,具有灵活、易于实现、便于扩展等特点。文章介绍了 S IP协议的发 展历史、网络组成,通过与传统的电信网络协议对比分析了 S IP协议的特点,结合S IP协议特点及现状对其应用前景进 行了分析。 关键词:SIP ;融合通信;VO LTE;互联网 中图分类号:TN913.23 文献标识码:A文章编号:1673-1131(2017)02-0105-02 1S IP协议的发展历史 SIP(Session Initiation Protocal)会话初始化协议的概念在 1996年出现,主要运用在Internet的不同文本类型当中,用于 电子邮件以及文字聊天等各项环节中。1999年由IE T F最初 建立,应用于Internet的相关网络环境结构当中,实现实时性 通讯。二H世纪初,由IE T F当中的S IP工作团队发出 RFC3261建议后才得到了逐渐推广。 S IP协议最初应用于Internet网络中,实现多媒体的会话 建立控制,后来作为IMS(IP M ultim edia Subsystem IP多媒体 子系统)的主要信令应用于电信领域的VOBB(V oiceover Broad Band宽带语音),近年来随着LT E的推广,SIP成为LTE 的语音最终解决方案V O LTE的主要信令协议,其应用范围从 特定环境逐步扩展至主流多媒体通信环境。 2 S IP网络组成 2.1 S IP协议在IM S中的应用 S IP协议是IM S中的基本协议,应用于M w、U t、ISC、M i、M g、M j、M k、M r等众多接口,整个IM S网络的会话控制功能 都是由S IP协议完成,具体使用情况如图1所示: P-CSCF ATS IM-SSF SIPl 4 M RFC UGC 19 图1S IP协议在IM S网络中应用示意图 2.2 S IP网络架构 S IP使用CS(Client/server客户端/服务器)架构如图2所 示,交互形式为请求、响应的方式。User Agent C lie n t即客户 端,发起S IP请求;User Agent Server即服务器端,进行S IP请 求处理,并进行响应,Request Proxy Server起到消息路由转发的功能。 3.2认证测试标准 系统B模型采用的简表是07B0,根据K N X协议必须满 足如表1所列的功能需求。认证测试将会针对这些基本功能 来设计测试例进行测试。 按照测试规范[6]要求,先通过E TS配置软件配置好K N X 设备后,采用E IT T软件编写好测试例,运行测试序列,所有测 试例均通过,说明该协议栈符合K N X协议规范要求。在软件 开发过程中,可以通过该方式进行各个功能点的验证,从而保 证软件的可靠性,缩短最终的认证周期。 表1系统B的基本功能表 协议栈主要功能 数据链路层数据帧的封装和解析、应答、数据过滤 网络层正确设置路由计数器 传输层支持四种传输模式;支持style3的状态机 配置和管理直接内存访问;用户内存的直接内存访问;验证模式;接口对象处理;下载状态机;运行状态机;重启;授权;设备描述业务;编程模式;K N X序列号;地址表?,关 联表;组对象表;应用相关参数 4结语 本文介绍的系统B模型的K N X设备是基于LPC处理器、L in u x系统来设计和实现的,并采用了 NCN5120芯片作为 K N X总线收发模块。该设备通过了第三方认证测试实验室的 认证测试,符合K N X协议规范。系统B模型K N X具有更丰 富的资源,可应用于复杂的智能家居和楼宇控制系统中,具有 广阔的市场价值和应用前景。 参考文献: [1]夏长凤.基于K N X总线智能家居控制系统的设计[J].电 器自动化,2016, 38⑴. [2]任志勇.基于K N X智能家居的应用[J].重庆电子工程职 业学院学报,2010, 19(4). [3]Jason Richards,Development o f Complex K N X Devices. W EINZIERL ENGINNERING GmbH,2010. [4]Konnex Association.Konnex Standard,Vol3,System Specifications,2013. [5]Konnex Association.Konnex Standard,Vol6,Profiles,2013. [6]Konnex Association.Konnex Standard,Vol8,System Test Specifications,2013. 作者简介:朱莉(1979-),女,四川省资中县人,电子工程师,硕 士学位,主要研宄方向为智能家居、大数据、LTE。 105

SIP协议扩展分析

协议分析 协议扩展分析 STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ????STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?

SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK 与传统 Telephony 业务互通的场景 ?Encapsulation –'Transparent' Transit of ISUP Messages –SIP 与ISUP 协议不可能一一映射 –如果为了保证SP1-SP2之间业务的无缝互通,只有SP1发出的ISUP 消息能够透传到SP2–将ISUP 消息封装在SIP 消息体里–Content-Type: application/ISUP

STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?可STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW Transaction STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???准?STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?规则CANCEL ???

sip协议解析与实现(c和c 使用osip)11

sip协议解析与实现(c和c++使用osip)11 第八章查询能力 SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息,而不用"呼叫(ringing)"另外一端。例如,在客户端插入了一个Require头域到INVITE 中,并列出了不确定目标UAS是否支持的能力之前,它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。 OPTIONS方法的目标使用Request-URI来标识,因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器,Request-URI不由客户端设置,这类似于REGISTER请求设置Request-URI的方法。 如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求,它要对这个请求进行应答而不用管Request-URI. 这个行为与HTTP/1.1一致。这个行为可以被用于"追踪路由线路(traceroute)"功能,从而使用发送一系列递增的 Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。

作为一般UA的行为,如果OPTIONS长时间没有应答,事务层能够返回一个超时错误。这将指出,目标是不可到达的并且查询的能力是不可以使用的。 OPTIONS请求可能由建立一个对话的一端发送,用于查询对端在后面的对话中可能会被使用到的能力。 第一节构造OPTIONS请求 OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。 OPTIONS可能会有一个Contact头域。 应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的,这可能被设置成用来描述UA的媒体能力的类型,比如,SDP(application/adp)。OPTIONS请求的应答被认为是有限定范围的,它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送,它保证会话中后继的请求也由应答OPTIONS的服务器所接收时,对OPTIONS请求的应答才是可用的。 OPTIONS请求的例子: OPTIONS sip:carol@https://www.wendangku.net/doc/eb15613862.html, SIP/2.0 Via: SIP/2.0/UDP https://www.wendangku.net/doc/eb15613862.html,;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70

SIP协议讲解

14 SIP协议关于本章

本章将对SIP协议做一简要介绍,包括涉及的基本概念、消息结构以及简要的消息流程。 14.1 概述 SIP(Session Initiation Protocol)是一个应用层控制协议,用于创建、更改和终止会话。这里的会话类型包括多媒体会议、Internet电话等类似的应用。SIP是实现VOIP(Voice over IP)的关键协议之一。 SIP支持别名映射、重定向服务、ISDN和智能网业务。它支持个人移动(personal mobility),即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。总的来说,SIP能够支持下列五种多媒体通信的信令功能。 l用户定位:确定参加通信的终端用户的位置; l用户通信能力协商:确定通信的媒体类型和参数; l用户意愿交互:确定被叫是否乐意参加某个通信; l建立呼叫:包括向被叫“振铃”,确定主叫和被叫的呼叫参数; l呼叫处理和控制:包括呼叫重定向、呼叫转移、终止呼叫等等。 SIP可以通过MCU(Multipoint Control Unit)、单播联网方式、或组播方式创建多方会话,支持PSTN和IP电话之间的网关功能。 SIP协议对低层协议作了最少的假设,低层协议可以为SIP协议提供可靠或非可靠传输,可以为分组或字节流业务。SIP可以使用UDP协议或TCP协议作为传输层协议,首选UDP协议。 14.1.1 相关概念 呼叫 一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。一个SIP 呼叫由Call-ID进行标识。 因此,如果一个用户是被不同的人邀请参加同一个多点会议,那么每个邀请都构成一个呼叫。点到点IP电话会话是一种最简单的会话,它映射为单一的SIP呼叫。 呼叫分支 一个呼叫分支(Call leg)由Call-ID、To、From三个参数共同决定。在同一个Call-ID中,从A到B的请求与从B到A的请求都属于同一个呼叫分支,呼叫分支也可以理解成一次呼叫中消息经过的路径。 事务 事务是发生在客户端和服务器之间的,包括从客户端发给服务器的第一个请求消息直到服务器端发给客户端的最终响应消息,这期间的所有的消息。 事务是由一个呼叫分支中的CSeq顺序号来标识的。但也有例外,比如一个ACK 请求与对应的INVITE请求具有相同的CSeq,但它们却构成了各自的事务。 一个正常的呼叫一般包含三个事务。其中,呼叫启动包含两个操作请求:邀请(INVITE)和证实(ACK),前者需要回送响应,后者只是证实已收到最终响应,不需要回送响应。呼叫终结包含一个操作请求:再见(BYE)。 定位服务 SIP重定位服务器或代理服务器用来获得被叫位置的一种服务,可由定位服务器提供,但SIP协议不规定SIP服务器如何请求定位服务。 代理服务器 代理服务器(Proxy Server)是用于将SIP请求路由到目的地的中间路径。它既是客户端也是服务器。用户请求可以直接被代理服务器处理或被转发给别的代理服务器。代理服务器在转发之前要对消息进行解析,必要时还会改写请求。 重定向服务器

SIP协议测试总结

SIP协议测试总结 一:响应码定义 1、响应(Response) 1)1XX:临时响应,表示请求消息正在被处理。 2)2XX:成功响应,表示请求已被成功接收,完全理解并被接受。 3)3XX:重定向响应,表示需采取进一步以完成该请求。 4)4XX:客户机错误,表示请求消息中包含语法错误信息或服务器无法完成客户机请求。 5)5XX:服务器错误,表示服务器无法完成合法请求。 6)6XX:全局故障,表示任何服务器无法完成该请求。 100:临时响应,正在尝试 180:振铃,UA收到INVITE请求之后用该响应通知用户,该响应也可以再发起一个本地回铃 181:呼叫正在转发 182:排队 183:会话进行 200:OK 300网络协议不兼容:会话描述中的一个或多个网络协议不可用。 301网络地址格式不兼容:会话描述中的一个或多个地址格式不可用。 302传送协议不兼容:会话描述中的一个或多个传送协议不可用。 303带宽单位不兼容:会话描述中的一个或多个带宽度量单位不被理解。 304媒体类型不可用:对话描述中的一个或多个媒体类型不可用。 305媒体格式不兼容:对话描述中的一个或多个媒体格式不可用。 306媒体特征不被理解:对话描述中的一个或多个媒体特征不被支持。

307对话描述参数不被理解:除上述几种参数之外的参数不被理解。 330组播不可用:用户站点不支持组播。 331单播不可用:用户站点不支持单播通信(通常是由于防火墙的存在)。 370带宽不足:对话描述中定义的或者媒体定义的带宽超出可用带宽。 399混合告警:该告警表示用户存在的任意一种错误,收到该告警的系统不可以采取任何自动的动作 401:未授权 403:禁止 404:未找到 405:不允许的请求方法 406:不接受 407:代理服务器需要鉴权 408:请求超时 413:请求消息过大 415:不支持的媒体类型 414:Request-URI过长 415:不支持媒体类型 416:不支持的URI方案 420:错误的扩展 421:需要扩展支持 423:间隔太短 480:临时不可用 481:呼叫/事务不存在 482:检测到路由循环

SIP协议的认识及呼叫追踪分析实验

《软交换系统实验》实验报告四 实验室名称:现代通信网络实验室实验日期: 2011 年 6月 5日 学院(系)专业、班级姓名成绩 实验项目SIP协议的认识及呼叫追踪分析实验指导教师 教师评语 教师签名: 年月日 一、实验过程原始记录(数据、图表等) 1.设备配置实验记录 设备名称设备IP地址短号设置长号设置 EIA2016设备192.168.0.3 101 EIT200 SIP电话192.168.1.101 802 2.呼叫跟踪实验记录 3.1)主叫信息 群号: 1 短号: 101 长号:用户标识码: (2)被叫信息 群号:1 短号: 102 长号:用户标识码: (3)呼叫消息原始记录(包括:主叫方和被叫方与EIX交互的信令消息) ①主叫方与EIX交互的呼叫信令消息跟踪结果: [151-12:02:09:970] MSG :--->> to 192.168.0.3/58525 crypt:TRUE Phone Call proto:P2PV2 len:739 INVITE sip:25130016@192.168.0.3 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.3:2080;branch=z9hG4bK7155de6d801d63c038d6335428dfb99e ;rport From: ;tag=95e1a9c636206889ba1e1906afc802bf To: Call-ID: 9677d064ead93fedc5873390abd0f84a@192.168.0.3 CSeq: 25971 INVITE Contact: Supported: 100rel Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, [152-12:02:09:970]INFO, UPDATE, PRACK Content-Type: application/sdp Max-Forwards: 70 Content-Length: 244 v=0

SIP协议深入介绍

SIP协议深入介绍 网络事业部软交换开发部王笑蓉1.SIP简介 SIP(Session Initiation Protocol)是应用层控制协议,可以创建,修改,以及终止一个多媒体会话。它具有以下几个主要功能: User location:确定通信中的终端位置 availability:确定被叫方是否愿意进行通信 User capabilities:确定用于通信的媒体类型及参数 User setup:建立会话各方的会话参数 Session management:终止会话,修改会话参数 Session SIP协议需要和其他IETF协议一起来构成一个完整的多媒体通信构架。这些协议有: RTP(Real Time Transport):传输实时数据,提供QoS反馈信息 Streaming protocol):控制流媒体的传送 Time RTSP(Real MEGACO(Media Gateway Control Protocol):控制媒体网关 SDP(Session Description Protocol):描述多媒体会话 1.1SIP协议结构 SIP协议的行为模型可以用几个分层的相对独立处理阶段来描述: 1.语法及编码层 2.传输层 定义了客户端如何通过网络发送请求及接收响应,以及服务器端如何接收请求并发送响应。所有SIP逻辑实体都包含此层。 3.事务层 事务层处理应用层请求或响应消息的重发,响应与请求的匹配以及应用层的超时。一个SIP事务由一个请求和对该请求的所有响应构成,这些响应分临时响应 (provisional response)和最终响应(final response)。对于INVITE事务,对应于非 2xx响应的ACK确认消息也属于该事物,而对应于2xx响应的ACK确认消息则不 属于该INVITE事物。 UA以及stateful proxy均包含事务层,而stateless proxy 不包含事务层 一个事物根据逻辑功能分为客户事务(client transaction)和服务器事务(server transaction)。客户事务和服务器事务是存在于UA及有状态代理服务器(stateful

相关文档