《协议书之sip协议的端口号.docx》由会员分享，可在线阅读，更多相关《协议书之sip协议的端口号.docx（13页珍藏版）》请在三一文库上搜索。
1、sip 协议的端口号【篇一： sip 协议详解 超全超清】目录第 3 章 协议3.1.4 sip 协议的应用3.2 协议消息3.2.1 消息类型3.2.2 消息结构3.3 基本消息流程3.3.1 sip 用户注册流程3.3.2 成功的sip 用户呼叫流程3.3.3 成功的sip 中继呼叫流程3.3.4 成功的sip-t中继呼叫流程第 3 章 sip 协议3.1 概述3.1.1 基本概念会话启动协议sip ( session initiation protocol )是由 ietf 提出并主持研究的一个在ip 网络上进行多媒体通信的应用层控制协议，它被用来创建、修改、和终结一个或多个参加者参加的
2、会话进程。这些会话包括internet 多媒体会议、internet 电话、远程教育以及远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动，统称为多媒体会话。参加会话的成员可以通过组播方式、单播联网方式或者两者结合的方式进行通信。sip 协议是一个正在发展和不断研究中的协议。一方面，它借鉴了其他 internet 标准和协议的设计思想，在风格上遵循因特网一贯坚持的简练、开放、兼容和可扩展等原则，并充分注意到因特网开放而复杂的网络环境下的安全问题。另一方面，它也充分考虑了对传统公共电话网的各种业务，包括in 业务和 isdn 业务的支持。利用带有会话描述的sip 邀请消息来创建会话，以使
3、参加者能够通过 sip 交互进行媒体类型协商。它通过代理和重定向请求用户当前位置，以支持用户的移动性。用户也可以登记它们的当前位置。sip 协议独立于其他会议控制协议，它在设计上独立于下面的传输层协议，因此可以灵活方便地扩展其他附加功能。sip 作为一个应用层的多媒体会话信令协议，可以被用来发起一个会话进程、在会话中邀请其他参加者加入会议，会话本身可以通过基于组播协议的会话通告协议( sap )、电子邮件、网页通告、以及轻量级号薄访问协议(ldap )等方式预先通告各个可能的参加者。sip 协议支持别名映射、重定向服务、 isdn 和 in 业务。它支持个人移动(personal mobili
4、ty )，即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。总的来说，会话启动协议能够支持下列五种多媒体通信的信令功能：? 用户定位：确定参加通信的终端用户的位置；用户通信能力协商：确定通信的媒体类型和参数；用户意愿交互：确定被叫是否乐意参加某个通信；建立呼叫：包括向被叫“振铃 ”，确定主叫和被叫的呼叫参数；呼叫处理和控制：包括呼叫重定向、呼叫转移、终止呼叫等等。sip 协议可以通过mcu ( multipoint control unit )、单播联网方式、或组播方式创建多方会话，支持pstn 和因特网电话之间的网关功能。sip 协议可以与其他用于建立呼叫的信令系统或协议结合
5、使用，它在设计上充分考虑了对其他协议的可扩展性。譬如，sip 协议支持的主叫可以识别出h.323 协议支持的被叫，通过h.245 网关利用h.225.0协议向被叫发起并建立呼叫；另外，一个sip 主叫可以识别出pstn 上的被叫及其电话号码，通过与 pstn 相连的网关向被叫发起并建立呼叫。sip 协议不提供发言控制(floor control )、投票等会议控制功能，也不规定如何管理一个会议。但是sip 协议可被用来引发这些会议控制协议。sip 协议本身不具备资源预留功能，但可以向被邀请者们传达这方面的信息。3.1.2 相关术语1. 呼叫一个呼叫是由一个公共源端所邀请的在一个会议中的所有参加
6、者组成，由一个全球唯一的call-id 进行标识。例如：由同一个源邀请的一个会议的所有参加者构成一个呼叫；点到点 ip 电话会话是一种最简单的会话，它映射为单一的sip 呼叫。通常情况下，呼叫由主叫方创建，但是更一般说来，呼叫可由并不参与媒体通信的第三方创建，此时会话的主叫方和会话的邀请方并不相同。对于多播会议来说，一个用户可由不同的人邀请参加同一会议，则每一个邀请应视作不同的呼叫。对于基于mcu 的会议，每个参与者使用一个呼叫邀请自己加入mcu 。2. 事务sip 是一个客户/服务器协议。客户和服务器之间的操作从第1 个请求至最终响应为止的所有消息构成一个sip 事务。一个正常的呼叫一般包含
7、三个事务。其中，呼叫启动包含两个操作请求：邀请（invite ）和证实（ack）,前者需要回送响应，后者只是证实已收到最终响应，不需要回送响应。呼叫终结包含一个操作请求：再见（bye ）。3. sip url为了能正确传送协议消息，sip 还需解决两个重要的问题。一是寻址，即采用什么样的地址形式标识终端用户；二是用户定位（下面介绍）。sip 沿用www 技术解决这两个问题。寻址采用sip url （ uniform resource locators ），按照rfc2396规定的uri 导则定义其语法，特别是用户名字段可以是电话号码，以支持 ip 电话网关寻址，实现ip 电话和 pstn 的互
8、通。sip url 的一般结构为：sip ：用户名：口令主机：端口；传送参数；用户参数；方法参数；生存期参数；服务器地址参数？头部名=头部值“ sip 表示需采用”sip 协议和所指示的端系统通信。“用户名 ”可以由任意字符组成，一般可取类似与e-mail 用户名形式，也可以是电话号码（softx3000 目前用户名是电话号码）。“主机 ”可为主机域名或ipv4 地址。“端口 ”指示请求消息送往的端口号，其缺省值为5060，即公开的sip 端口号。“口令 ”可以置于sip url 中，但一般不建议这样做，因为其安全性是有问题的。“传送参数”指示采用tcp 还是 udp 传送，缺省值为udp 。
9、“用户参数”， sip url 的一个特定功能是允许主机类型为ip 电话网关，此时，用户名可以为一般的电话号码。由于bnf 语法表示无法区分电话号码和一般的用户名，因此，在域名后增加了“用户参数”字段。该字段有两个可选值：ip 和电话，当其设定为“电话 ”时，表示用户名为电话号码，对应的端系统为ip 电话网关。“方法参数”指示所用的方法（操作）。“生存期参数”指示 udp 多播数据包的寿命，仅当传送参数为udp 、服务器地址参数为多播地址时才能使用。“服务器地址参数”指示和该用户通信的服务器的地址，它覆盖“主机字段中的地址，通常为多播地址。“传送参数”、 “生存期参数”、 “服务器地址参数”和
10、 “方法参数”均属于 url 参数，只能在重定向地址，即后面所说的contact 字段中才能使用。 下面给出若干个sip url 的示例：sip; 55500200191.169.1.112;55500200 为用户名，191.169.1.112 为 ip 电话网关的ip 地址。sip; 55500200127.0.0.1:5061; user=phone;55500200 为用户名，127.0.0.1 为主机的ip 地址， 5061 为主机端口号。用户参数为“电话 ”，表示用户名为电话号码。sip: alice; method=register;alice 为用户名， 为主机域名。方法参数为
11、“登记 ”。4. 用户定位用户定位基于登记。sip 用户终端上电后即向登记服务器( softx3000 )登记，sip 专门为此定义了一个“登记 ”( register )请求消息，并规定了登记操作过程。5. 定位服务(location service )sip 重定位服务器或代理服务器用来获得被叫位置的一种服务，可由定位服务器提供，但sip 协议不规定sip 服务器如何请求定位服务。在华为 u-sys 解决方案中，softx3000 兼任定位服务器的角色。6. 代理，代理服务器(proxy 、 proxy sever )作为一个逻辑网络实体代表客户端转发请求或者响应，可以同时作为客户端和服务
12、器端。代理服务器有三种形态：stateless 、 stateful和 call stateful ，其可以采用分支、循环等方式向多个地址尝试转发请求。代理服务器的主要功能：路由、认证鉴权、计费监控、呼叫控制、业务提供等。在华为u-sys 解决方案中，softx3000 兼任代理服务器的角色。7. 重定向服务器(redirect server )重定向服务器将请求中的目的地址映射为零个或多个新的地址，然后返回给客户端，客户端直接再次向这些新的地址发起请求。重定向服务器并不接收或者拒绝呼叫，主要完成路由功能，与注册过程配合可以支持sip 终端的移动性。在华为u-sys 解决方案中，softx30
13、00 兼任重定向服务器的角色。8. 注册员(registrar )注册员为接收注册请求的服务器，通常与proxy 或者 redirectserver 共存。注册员需要将注册请求中的地址映射关系保存到数据库中，供后续的相关呼叫过程使用，同时可以提供定位服务。在华为 u-sys 解决方案中，softx3000 兼任注册员的角色。9. 用户助理(user agent )用来发起或者接收请求的逻辑实体称为user agent 。10. 用户助理客户(user agent client )发起请求的一方称为uac ( user agent client )，举例sip phone就是 uac 的一种实际
14、形态。11. 用户助理服务器(user agent server)接收请求的一方称为uas ( user agent server )，举例softx3000就是 uas 的一种实际形态。注意： uac 和 uas 的划分是针对一个事务而言的。3.1.3 协议栈结构sip 协议栈结构如所示。【篇二：图解sip 穿透 nat 的问题】图解 sip 穿透 nat 的问题nat 是指网络地址转换。它是这样一种技术，在 internet 公网的ip 不够的情况下，让公司或者家庭的多台电脑，共用一个公网的ip地址上网。常见的宽带路由器，就有这样的功能。如下面的示意图。rtp 协议rtp 即实时传输协议(
15、real-time transport protocol )。 rtp 是传输语音、视频图像等实时数据的协议。使用rtp 传输时，需要知道对方的 ip 地址和端口。sip 协议sip 协议，就是帮助呼叫双方，找到对方的ip 地址和端口，及协商多媒体的类型和格式等信息。如图。你与朋友打电话，你的ip 是1.2.3.4 ， rtp 端口是 8000。朋友的ip 是 193.226.0.1 ，用的 rtp 端口是 9000 。 这样，知道了双方的ip 地址与端口，双方就能够通信。sip+rtp 穿透问题sip穿透nat时，遇到的问题，实际上不是sip穿不过nat,本质上是 rtp 的问题，是rtp
16、的数据穿不过nat 。 sip 设备要在sip 消息包中，声明它所使用的rtp 端口。当sip 设备在 nat 后面时，它难以准确地预知nat 分给它的公网的rtp 端口；也就是说，sip 设备难以知道它使用rtp 端口( nat 公网 ip 上分给 rtp 的端口)是多少。对 sip 服务的运营商来说，如果中转语音数据，则这个问题就比较好解决。如使用sip 会话边界控制器sbc 。 用 sip sbc 来中转语音、视频数据流，因为sbc 总是在公网的ip 地址上运行，则sip 设备把rtp 数据发送到公网上的sbc 上，是不会有问题的。skype 解决 nat 穿透的方法skype 解决 n
17、at 穿透的方法很聪明，它是利用在公网上运行的skype 软件，来中转在nat 后面的 skype 软件语音数据流。也就是说， 如果你使用skype 软件且用的是公网ip 地址，可能你的电脑在中转其它的skype 用户的语音数据，而你自己并不知道。【篇三：sip 协议讲解】sip 协议讲解sip 工作架构原理简介rtp/rtcpsip/sdpudp/tcp ip 图1 协议结构图sip 协议是一种会话建立和控制的信令协议，sip 协议本身不能实现多媒体的业务，sip 协议和 sdp 协议，媒体流rtp/rtcp协议配合完成完整的多媒体会话业务。sip session 建立流程1.invite
18、bobieee.org 2. invite bobieee.org 3. bob 4. 6. ack 7. invite bob 8. invite bobsip redirect location servers (ieee.org) 3 sip proxy 2 5 6 7 (sjsu.edu) 11 10 12 9 8 () 4 sip proxy9. ringing ok 10. ringing ok 11. ack 12. ack5. bob moved. temporarily contact bob1rtp media sip client sip client (user age
19、nt server) 图 2 会话建立流程图sip 协议介绍sip 基本概念session: : 会话是媒体流数据和他们发送者和接收者的集合的概念由sdp 中的 session id 定义 dialog: 对等sip 实体间的sip 信令连接关系，由from tag, to tag,call id 唯一标识 user agent client (uac): ：创建新的sip 请求的逻辑实体useragent server (uas) ：接收 sip 请求并回应响应的逻辑实体proxy ：在 uac 和 uas 之间路由sip 消息的网络实体sip 消息 sip 消息分为从客户机到服务器的请求消
20、息以及从服务器到客户机的响应消息。两种类型的消息结构相似，虽然语义不尽相同。两种消息都有一个起始行(start line ) ; 一个或多个头字段( head fields ) ; 一个空行( empty line )表示头部的结束；还包括一个可选择的消息体( message-body )。 generic-message = start-line * message-header crlf message-body start-line = request-line / statusline 请求消息request 中请求行：request-line = method sprequest-u
21、ri sp sip-version crlf 请求方法（method ）有六种：register 用来登记；invite,ack,cancel 用来建立对话；bye 用来结束对话；options 用来咨询服务器的能力。request-uri: 是 sip 或sips uri ,也支持“tel ” ur代表request所请求的用户 或服务器。 它的初始值可以被设成与to field 中 uri 一致；一个比较特殊的情况是 register ，它是被设成所要登记地址的location service 的域。在呼叫寻址的过程中可以改写 ,在寻址过程中有详细介绍。sipversion ：表示 req
22、uest 和 response 所使用的sip 版本。 响应消息response 中状态行：status-line = sip-version sp status-codesp reason-phrase crlf 状态码（status-code ）有： 1xx:provisional - request received, continuing to process the request; 2xx: success - the action was successfully received, understood, and accepted; 3xx: redirection - fur
23、ther action needs to be taken in order to complete the request; 4xx: client error - the request contains bad syntax or cannot be fulfilled at this server;5xx: server error - the server failed to fulfill an apparently valid request; 6xx: global failure - the request cannot be fulfilled at any server.
24、 消息头字段（head fields ）： header = header-namehcolon header-value *（comma header-value） （字段值，参数名， 参数值大小写无关）（请求消息必须包括via， to， from ， cseq ，call-id ， max-forwards 六个字段） via: sip/2.0/udp;branch=z9hg4bknashds8 ;received=192.0.2.1 via head field via 头字段保存所经过sip 网元的主机名或网络地址（可能还有端口号），消息中的所有via 头字段对请求消息而言，从下至上依
25、次表示到当前所在sip 网元为止，请求消息所经过的路径；对响应消息而言，从上至下依次表示从当前网元开始，响应所应遵循的路径。uac 在发出请求时，他在其请求中插入via 字段，该字段包含uac 的 主机名或网络地址，在消息的传递过程中经过的每个sip 网元均在其转发的请求中插入via 字段。同时当sip 网元收到上一跳sip 网元的请求消息时，在上一跳sip 网元所插入的via 字段中加入received 参数，代表所收到来自上一跳 sip 网元数据包的实际源地址（对于上一跳sip 网元具有多主机 地址即 multi-homed host 时，可能会混淆所用的网络接口）。见 rfc3261 p
26、180 。 在 sip 网元（ uac 或 proxy ）发出或转发请求消息时，在其插入的via 字段中必须包含branch 参数，该参数用于标识此请求消息所创建的事务。ua 所发送的所有request 的 branch参数必须在时间和空间上都唯一；这里也有一个例外，cancel 以及非 2xx response 的 ack 。对于 cancel 来讲，与它所cancel 的request 的 branch 参数一致；此外，当invite 请 求其 finalresponse 是 non-2xx 响应时，对应该response 的 ack 与此invite 请求的 branch 参数一致。因而
27、，cancel 以及非 2xxresponse 的 ack 与其所 cancel 的 request 或对应的invite 属于同一个事务。见rfc 3261 p39 p122 branch 参数可以用做loopdetection ，这时参数必须被分成两部分：第一部分符合一般的原则（对于 rfc3261 ， z9hg4bk ），第二部分被用来实现 loopdetection 以用来区分loop 和 spiral 。 loop 和 spiral 均指 proxy收到一个请求后转发，然后此转发的请求又重新到达该proxy ，区别是 loop 中请求的request-uri 以及其他影响proxy
28、处理的头字段均不变，而spiral 请求中这些部分必需有某个发生改变，spiral 发生的典型情况是request-uri 发生改变。proxy 在插入 via 字段前，其branch 参数的 loop detection 部分依据以下元素编码：to tag ，from tag ， call-id 字段， request-uri ， topmost via 字段， cseq 的序号部分（即与request method 无关），以及proxy-require 字段， proxy authorization 字段。注意：request method 不能用于计算 branch 参数，比如canc
29、el 以及非 2xx response 的 ack 与其所 cancel 的 request 或对应的invite 属于同一个事务，即其branch 参数相同。见rfc3261 p22 p25 p39 p95 p105 此外 via 字段还包含sip 协议版本以及消息传输所用的传输协议。maxforwards: 70 max-forwards head field 表示 request 到达 uas 的跳数的限制。是一个整数，经过每一跳时减去一。如果max-forwards 已经是零，可是request 还没有到达目的地，则就会产生一个483（too many hops） 响应。 to: bo
30、bsip:bob to head field 预置 request 所希望的的 ” logical ” recipien（t register 事务除外），它可能 是，也可能不是 request 的最终 recipient 。 to head field 在 register 事 务中表示要在location server 中登记谁的地址，即地址绑定中的address-of-record （ vs. contact address ）。 to head field 可以 有一个 tag 参数， to tag 代表 dialog 的对等参与者（ peer ）。在uac 发出一个初始dialog
31、的请求（如invite ）时，即发出out-of-dialog 请求时，由于dialog 还没有建立，不含to tag 参数。当uas收到 invite 请求时，在其发出的2xx 或 101-199 响应中设置to tag参数， 与 uac 设置的 from tag 参数以及call-id （呼叫唯一标识）一起作为一个dialog id （对话唯一标识，包含to tag ， from tag ，call-id ）的一个部分。rfc3261 规定只有invite 请求与 2xx 或 101199 响应可以建立dialog （由 101-199 响应创建的dialog 称为early dialog
32、 ）。见rfc3261 p70 见 rfc3261 p36 ， p159 ， p178from: alice sip:alice;tag=1928301774 from headfield 是 request 发起者的logical 标识 （ register 事务除外）fromhead field 。 在 register 事务中表示谁负责这次登记，如果由发起者负责该字段也就是地址绑定中的address-of-record （ vs.contact address ）。 from head field 与 to head field 类似，包含一个 uri 以及可选的display name
33、 ，但 from head field 不能是 ua的主机 ip 地址或主机名，因为from 字段只能是逻辑名（ from 字段用于 sip 元素决定对该请求采用何种处理规则，例如对from 字段代表的用户进行自动拒绝）。from 字段必须包含tag 参数，在uac发出一个out-of-dialog 请求（对话建立请求）时，必须设置一个唯一的 tag 参数，作为dialog id 的一个部分。 见 rfc3261 p37 ，p159 ， p172 call-id: a84b4c76e66710 call-id head field 是一个邀请 （invitation） 或来自同一个uac 用户
34、的所有登记请求（registeration ，包括更新登记，取消登记）以及由此产生的一组响应的唯一标识。一个邀请可以建立多个dialog （当被叫用户有多个联系方式时），这成为 forking ，因而 call-id 只是一次呼叫邀请的唯一标识，call-id 与 uac 在 发出请求中设置的from tag 字段以及uas 在其相映中设置的to tag 字段三 者一起作为一个dialog-id 。在一个 dialog 中，所有的requests 和 responses 的 call-id 必须一致 同一 ua 的每一个register 的 call-id 必须一致。见 rfc3261p37
35、， p159 ， p166 cseq: 314159 invite cseq head field 用于在同一个 dialog 中标识及排序事务（transaction ）以及区分新的请求与请求的重发。（请求的重发-retransmission 与 re-request 不同，前者消息完全相同，后者则与原请求不同。例如re-invite 能用于改变媒体会话的参数；在原请求产生4xx 响应时，按照响应内容再re-request ，见 rfc3261p45 ）。 cseq 包括顺序号和方法（method ），方法必须和它所对应的 request 相匹配。对于out-of-dialog 的非 reg
36、ister request ，取值任意。对于 dialog 内的每一个新的request (如 bye,re-invite,option )， cseq 的序号加1 。但是对于cancel,ack 除外。对于 ack 而言， cseq 的序号必须与其所对应的request 相同。对于cancel 而言， cseq 的序 号也必须与其cancel 掉的 request 相同。注意：在同一个对话中的uac 和 uas 分别维护自己的cseq 序号，他们发出请求的cseq 序号是不相关的。见rfc3261 p218 见rfc3261 p38 ， p159 ， p170 ， p218 contact:
37、 sip:alice contact head field 对于非 register 事务， contact header field 主要提供了uac 或 uas 的 直接联系sip uri ， uac 在发出的对话建立(out-of-dialog ) invite 请求 的contact 字段中提供自己的直接联系sip uri ，在 uas 收到该请求后在 其发出响应的contact 字段中提供自己的直接联系sip uri ，这样在建立 对话后，ua 间可以通过对方的直接联系sip uri 绕过 proxy直接发送请求。 对于 register 事务，表示地址绑定中的contactaddr
38、ess ( vs. address-of-record ) content-type: application/sdp content-type header field 主要表示发给接收器的消息体的媒体类型。如果消息体不是空的，则 content-typeheader field 一定要存在。如果content-type header field 存在，而消息体是空的，表明该类型的媒体流长度是0。content-length:142 content-length header field 表示消息体的长度。是八位组的十进制数。(alices sdp not shown) 消息体 sip me
39、ssage body ：编码方式主要是由头部确定，现在为一般为sdp 。 sip 通过offer/answer 模型来进行ua 间的 sdp 会话描述交互：a) ua 发出会话描述，称为offer ，它包含会话描述的提议，代表期望建立的通讯方式 ( aduio,video,games )，通讯方式的参数(如codextypes )以及用于接收answer 方 媒体的地址。b) 另一方 ua 接到offer ，并用另一个会话描述予以响应，代表此ua 接受的通讯方式，参 数以及用于接收offer 方媒体的地址。c) ua 双方会话描述的offer/answer 交互在一个建立的对话内进行，当一个invite 请求 建立多个对话时，每个对话的ua 间都要有offer/answer 交互。 d) 会话描述 sdp 只能由 invite ， response ， ack 的消息体携带，sdp 的offer/answer 交互有以下几种方式：i. invite 携带 sdp 消息体发出offer ， 2xx response 携带 sdp 消息体 answer ii. 2xx response 携 带 sdp 消息体发出offer ， ack 携带 sdp 消息体 answer _