SIP信令简介
注:内容为其他材料整理而来,内容可能有错误。若您发现错误,望留言指正,非常感谢!
1. 什么是 SIP 会话初始协议 session initiation protocol?
由互联网工程任务组制定的, 用于多方多媒体通信的框架协议。
它是一个基于文本的应用层控制协议, 独立于底层传输协议, 用于建立、修改和终止IP网络上的双方或多方多媒体会话。
2. 什么是信令?
信令是控制电路的信号,是终端和终端、终端和网络之间传递的一种消息,专门用来控制电路,建立、管理、删除连接,以使用户能够正常通过这些连接进行通信。
允许程控交换、网络数据库、网络中其它“智能”节点交换下列有关信息:
呼叫建立、监控(Supervision)、拆除(Teardown)、分布式应用进程所需的信息(进程之间的询问/响应或用户到用户的数据)、网络管理信息。
信令通常需要在通信网络的不同环节(基站、移动台和移动控制交换中心等)之间传输,各环节进行分析处理并通过交互作用而形成一系列的操作和控制,其作用是保证用户信息的有效且可靠的传输。
信令网关就是两个不同的网之间信令互通设备。
3. SIP 相关术语
3.1 呼叫
一个呼叫是由一个公共源端所邀请的在一个会议中的所有参加者组成,由一个全球唯一的Call-ID 进行标识。
3.2 事务
SIP是一个客户 /服务器协议。
客户和服务器之间的操作从第 1 个请求至最终响应为止的所有消息构成一个SIP事务 。
一个正常的呼叫一般包含三个事务。
其中,呼叫启动包含两个操作请求:邀请( Invite)和证实( ACK),前者需要回送响应,后者只是证实已收到最终响应,不需要回送响应。
呼叫终结包含一个操作请求:再见( Bye)。
3.3 SIP URL (Uniform Resource Locators)
为了能正确传送协议消息,SIP还需解决两个重要的问题。
- 寻址,即采用什么样的地址形式标识终端用户;
- 用户定位。
SIP沿用 WWW 技术解决这两个问题。
- SIP URL的一般结构为:
SIP: 用户名:口令 @ 主机:端口;传送参数:用户参数;方法参数;生存期参数;服务器地址参数?头部名=头部值
SIP:需采用SIP协议和所指示的端系统通信
用户名:由任意字符组成,一般可取类似于E-mail用户名形式,也可以是电话号码
口令:可置于SIP URL中,但一般不建议,因为其安全性是有问题的
主机:主机域名或IPv4地址
端口:请求消息送往的端口号,其缺省值为5060,即公开的SIP端口号
传送参数:采用TCP还是UDP传送,缺省值为UDP
用户参数:SIP URL的一个特定功能是允许主机类型为IP电话网关,此时,用户名可以为一般的电话号码。因此,在域名后,增加了“用户参数”字段。该字段有两个可选值:IP和电话,其设定为“电话”时,标识用户名为电话号码,对应的端系统为IP电话网关。
方法参数:所用的方法(操作)
生存期参数:UDP多播数据包的寿命,仅当缠讼参数为UDP、服务器地址参数为多播地址时才能使用。
服务器地址参数:和该用户通信的服务器的地址,覆盖“主机”字段中的地址,通常为多播地址。
传送参数、生存期参数、服务器地址参数和方法参数均属于URL参数,只能在重定向地址,及Contact字段中才能使用。
- SIP URL (Uniform Resource Locators)
用户定位:
基于等级,SIP用户终端上电后即向等级服务器等级,SIP专门为此定义了一个“登记”(REGISTER)请求消息,并规定了登记操作过程。
3.4 定位服务
SIP重定位服务器或代理服务器用来获得被叫位置的一种服务, 可由定位服务器提供, 但 SIP协议不规定 SIP服务器如何请求定位服务。
3.5 代理服务器
一个逻辑网络实体代表客户端转发请求或者响应,可以同时作为客户端和服务器端。
代理服务器有三种形态: Stateless、 Stateful 和 CallStateful,其可以采用分支、循环等方式向多个地址尝试转发请求。
代理服务器的主要功能: 路由、 认证鉴权、 计费监控、 呼叫控制、 业务提供等。
3.6 重定向服务器
重定向服务器将请求中的目的地址映射为零个或多个新的地址,然后返回给客户端,客户端直接再次向这些新的地址发起请求。重定向服务器并不接收或者拒绝呼叫,主要完成路由功能,与注册过程配合可以支持 SIP终端的移动性。
3.7 注册员
注册员为接收注册请求的服务器,通常与 Proxy 或者 Redirect Server 共存。注册员需要将注册请求中的地址映射关系保存到数据库中,供后续的相关呼叫过程使用, 同时可以提供定位服务。
3.8 用户助理
用来发起或者接收请求的逻辑实体称为User Agent。
4. SIP会话事务
5. SIP协议栈
SIP是应用层的控制协议,用来建立、修改和终止多媒体会话。
SIP本身不提供服务,只是作为一个部件与其他协议一起组成完成的多媒体构架。
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 协议的功能和实施并不依赖这些协议。[1]
6. SIP消息
SIP消息采用文本方式编码。
6.1 请求消息
| 请求消息 | 消息含义 |
| ---- | ---- | ---- |
| INVITE | 发起会话请求,邀请用户加入一个会话,会话描述含于消息体中。对于两方呼叫来说,主叫方在会话描述中指示其能够接受的媒体类型及其参数。 被叫方必需在成功响应消息的消息体中指明其希望接受哪些媒体,还可以指示其行将发送的媒体。如果收到的是关于参加会议的邀请,被叫方可以根据 Call-ID或者会话描述中的标识确定用户已经加入该会议,并返回成功响应消息。 |
| ACK | 证实已收到对于 INVITE 请求的最终响应。该消息仅和 INVITE 消息配套使用。 |
| BYE | 释放已建立的呼叫 |
| CANCEL | 取消尚未完成的呼叫请求,对于已完成的请求(即已收到最终响应的请求)则没有影响。 |
| REGISTER| 向SIP网络服务器登记用户位置信息 → 即注册认证 |
| OPTIONS| 查询服务器的能力 |
6.2 响应消息
请求消息和响应消息都包括SIP头字段和SIP消息字段。
在SIP消息中加入SDP消息正文部分。
序号 | 状态码 | 消息功能 |
---|---|---|
1xx | 信息响应(呼叫进展响应)0 | 表示已经接受到请求消息,正在对其进行处理 |
100 | 试呼叫 | |
180 | 振铃 | |
181 | 呼叫正在前转 | |
182 | 排队 | |
2xx | 成功响应 | 表示请求已经被成功接收、处理并被成功接受 |
200 | OK | |
3xx | 重定向响应 | 表示需要采取进一步动作,以完成该请求消息 |
300 | 多重选择 | |
301 | 永久迁移 | |
302 | 临时迁移 | |
303 | 见其他 | |
305 | 使用代理 | |
380 | 代换服务 | |
4xx | 客户出错 | 表示请求消息中包含语法错误或者SIP服务器不能完成对该请求消息的处理 |
400 | 错误请求 | |
401 | 无权 | |
402 | 要求付款 | |
403 | 禁止 | |
404 | 没有发现 | |
405 | 不允许的方法 | |
406 | 不接受 | |
407 | 要求代理权 | |
408 | 请求超时 | |
410 | 消失 | |
413 | 请求实体太大 | |
414 | 请求URI太大 | |
415 | 不支持的媒体类型 | |
416 | 不支持的URI方案 | |
420 | 分机无人接听 | |
421 | 要求转机 | |
423 | 间隔太短 | |
480 | 暂时无人接听 | |
481 | 呼叫腿/事务不存在 | |
482 | 相环探测 | |
483 | 调频太高 | |
484 | 地址不完整 | |
485 | 不清楚 | |
486 | 线路忙 | |
487 | 中止请求 | |
488 | 此处不接受 | |
491 | 待处理请求 | |
493 | 难以辨认 | |
5xx | 服务器出错 | 表示SIP服务器故障不能完成对正确消息的处理 |
500 | 内部服务器错误 | |
501 | 没实现的 | |
502 | 无效网关 | |
503 | 不提供此服务 | |
504 | 服务器超时 | |
505 | SIP版本不支持 | |
513 | 消息太长 | |
6xx | 全局故障 | 表示请求不能在任何SIP服务器上实现 |
600 | 全忙 | |
603 | 拒绝 | |
604 | 都不存在 | |
606 | 不接受 |
6.3 消息结构
请求消息和响应消息的格式,一般由起始行、若干个消息头和消息体构成。
SIP一般消息 = 起始行
*消息头
CELF(空行)
[消息体]
- 起始行 = 请求行、状态行(SIP请求消息起始行是请求行(Request-Line),响应消息起始行是状态行(Status-Line))
- 请求消息头至少包括 From, To, CSeq, Call-ID, Max-Forwards, Via六个头字段,它们是构建SIP消息基本单元
- 消息体一般采用SDP(Session Description Protocol)协议,会话描述协议
6.3.1 请求消息
SIP 请求命令的格式,由起始行、消息头和消息体组成。通过换行符区分消息头中的每一条参数行。对于不同的请求消息,有些参数可选。
请求消息结构[2]
起始行 | 命令名称 | 对端UPI | 版本 |
---|---|---|---|
消息头 | Call-ID: 本地标识@主机 | Call-ID: call-973636852-4@191.169.150.101 | 用以唯一标识一个特定的邀请或标识某一客户的所有登记,每个会议呼叫都有自己的Call-ID |
From:显示名 |
From: <sip :1000@191.169.200.61> ;tag=1c17691 | 指示请求的发起者 | |
To: 显示名 |
To: < Sip :1000@191.169.200.61> To: < sip :1001@191.169.200.61> ;tag=62beb3ca |
指明请求的接收者 | |
Cseq | Cseq: 1 INVITE | 命令序号,指明请求的接收者 | |
Via: 发送协议 发送方;隐藏参数;生存期参数;多播地址参数;接收方标记,分支参数 | Via: SIP /2.0/UDP softx3000.bell-telephone.com:5060 Via: SIP /2.0/UDP 10.0.0.1:5060;received=191.169.12.30 字段:Via: SIP /2.0/UDP191.169.1.116:5061;ttl=16; maddr=191.169.10.20;branch=z9hG4bkbc427dad6 |
指示路由。可以防止请求消息传送产生环路,并确保响应和请求消息选择同样的路径,以保证通过防火墙或满足其它特定的选路要求。 | |
Contact:地址;q参数;动作参数;时效参数;扩展属性 | Contact: < Sip :66500002@191.169.1.110:5061> ;q=0.7;expires=3600 | 用于 INVITE 、ACK 和 REGISTER 请求以及成功响应、呼叫进展响应和重定向响应消息,其作用是给出其后和用户直接通信的地址。 | |
Max-Forwards: 十进制整数 | Max-Forwards: 70 | 定义一个请求到达其目的地址所允许经过的中转站的最大值。主要是为了出现环路时不会一直消耗代理服务器的资源。该字段的初始值为 70。 | |
Allow: 十进制整数 | Allow: INVITE, ACK, OPTIONS, CANCEL, BYE | 给出代理服务器支持的所有请求消息类型列表。 | |
Content-Length: 十进制整数 | Content-Length: 349 | 表示消息体的大小,为十进制值。 | |
Content-Type: 十进制整数 | Content-Type: application/sdp | 表示发送的消息体的媒体类型。 | |
Supported | Supported: 100rel | SIP 协议中定义的 100 类临时响应消息的传输是不可靠的,100rel 扩展为 100 类响应消息的可靠传输提供了相应的机制。 | |
User-Agent | User-Agent: Softphone Beta1.5 | 包含有发起请求的用户终端的信息。 | |
Expires | Expires: 5 | 指定了消息(或消息内容)多长时间之后超时。 | |
Accept-Language | Accept-Language: en | 表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言类型。 | |
Authorization | Authorization:认证方式 USERNAME, REALM, NONCE, RESPONSE,URI, CNONCE, ALGORITHM | 包含某个终端的鉴权证书。 | |
…… | |||
消息体 | SDP | 会话描述协议 |
Call-ID:主机应为全局定义域名和全局可选路IP地址,此时,本地标识由在“主机”范围内唯一的URI字符组成。
From:显示名为用户界面上显示的字符,若系统不予显示,应置为“匿名(Anonymous)”。tag是全局唯一的16进制数字串标记,中间可带连字符“-”。当两个共享同一个SIP地址的用户实例通相同的Call-ID发起呼叫邀请时,就需用此标记予以区分。
To:需要用标记来区分来自不同实例的响应。To字段汇总的标记是由每个实例至于响应消息中的。
Cesq:客户在请求中应加入此字段,由命名名称和一个十进制序号组成,由请求客户选定,在Call-ID范围内唯一确定。重发请求的序号保持不变。服务器将请求中的 Cseq 值复制到响应消息中,用于将请求和其触发的响应相关联。ACK 和 CANCEL 请求的 Cseq 值(十进制序号)和对应的 INVITE 请求相同,BYE 请求的 Cseq 序号应大于 INVITE 请求。服务器必须记忆相同 Call-ID 的INVITE 请求的最高序号,收到序号低于此值的 INVITE 请求应在给出响应后予以丢弃。
Via:发起请求的客户必须将其自身的主机名或网络地址插入请求的 Via 字段,如果未采用缺省端口号,还需插入此端口号。在请求前传过程中,每个代理服务器必须将其自身地址作为一个新的 Via 字段加在已有的 Via 字段之前。如果代理服务器收到一个请求,发现其自身地址位于 Via 头部中,则必须回送响应“检测到环路”。
当请求消息通过网络地址翻译点(如防火墙)时,请求的源地址和端口号可能被改变,此时 Via 字段就不能成为响应消息选路的依据。为了防止这一点,代理服务器应校验顶端 Via 字段,如果发现其值和代理服务器检测到的前站地址不符,则应在该 Via 字段中加入“ receive ”参数,如此修改后的字段称为“接收方标记 Via 头部字段”。
Via字段格式介绍:发送协议的格式为: 协议名 /协议版本 /传送层,协议名和传送层的缺省值分别为 SIP 和 UDP。· 发送方为通常的发送方主机和端口号。 ·隐藏参数就是关键词 hidden,如有此参数,表示该字段已由上游代理予以加密,以提供隐私服务。 ·多播地址参数和接收方标记的意义如前所述。 ·生存期参数与多播地址参数配用。 ·分支参数用于代理服务器并行分发请求时标记各个分支,当响应到达时,代理可判定是哪一分支的响应。
Contact: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字段格式介绍:地址的表示形式和 To ,From 字段相同。q 参数,其取值范围为 [0,1],指示给定位置的相对优先级。数值越大,优先级越高。 ·动作参数仅用于REGISTER 请求。它表明希望服务器对其后至该客户的请求进行代理服务还是重定向服务。如果未含此参数,则执行动作取决于服务器的配置。 ·失效参数指明 URI 的有效时间,可用秒表示,也可用 SIP 日期表示。 ·扩展属性就是扩展名。
Max-Forward:请求每经过一个中转站,该值减 1。如果该值为 0 时该请求还没有到达其目的地址,服务器将回送“ 483” (Too Many Hops) 响应并终止这个请求。
Content-Length:应用程序使用该字段表示要发送的消息体的大小,而不考虑实体的媒体类型。如果使用基于流的协议(如 TCP 协议)作为传输协议,则必须使用此消息头字段。消息体的长度不包括用于分离消息头部和消息体的空白行。Content-Length值必须大于等于 0。如果消息中没有消息体,则 Content-Length 头字段值必须设为 0。
Content-Type:如果消息体不为空,则必须存在 Content-Type 头字段。 如果消息体为空且 Content-Type 头字段存在,则表示此类型的消息体长度为 0(如一个空的声音文件)。
Support:如果 UAC 支持该扩展, 则在发送的消息中增加Supported:100rel 头域和字段。
如果 UAS 支持该扩展,则在发送 100 类响应时增加 Require:100rel 头域和字段。 UAC 收到该响应消息后需要向 UAS 发送 PRACK 请求通知 UAS 已收到该临时响应。 UAS 向 UAC 发送对 PRACK 的 2XX 响应消息结束对该临时响应的确认过程。
如果某一 UA 想要在发送的临时响应消息中携带 SDP 消息体,那么 UAC 和 UAS都必须支持和使用 100rel 扩展以保证该消息的可靠传输。
Accept-Language:如果消息中没有 Accept-Language头字段,则服务器端认为客户端支持所有语言。
Authorization:终端收到认证请求消息后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的 RESPONSE ,并且通过新的请求消息发送给服务器端。
服务器端在收到带有认证响应的新的请求消息后首先检查 NONCE 的正确性。如果 NONCE不是本地产生,则直接返回失败。否则如果 NONCE是本地产生,但是认证过程已经超时,则服务器端会重新产生 NONCE 并重新发起对用户的认证过程。其中老的 NONCE 会通过CNONCE参数返回。
NONCE验证通过后服务器端会根据 NONCE、用户名、密码(服务器端可以根据本地用户信息获取用户的密码) 、URI 等采用和终端相同的算法生成 RESPONSE ,并且对此 RESPONSE和请求消息中的 RESPONSE进行比较,如果二者一致则用户认证成功,否则认证失败。
Authorization字段格式: ·HTTP-DIGEST认证方式。 ·USERNAME:被认证的用户的用户名。 ·REALM:用于标识发起认证过程的域。 ·NONCE:由发起认证过程的实体产生的加密因子。
RESPONSE :终端在收到服务器的认证请求后根据服务器端产生的 NONCE、用户名、密码、URI 等信息经过一定的算法生成的一个字符串。该字符串中包含了经过加密后的用户密码。(在认证过程中处理用户密码之外其他信息都会通过 SIP消息以明文的方式在终端和服务器端进行传递。)
URI:发起的呼叫请求消息的 Request-URI。由于终端在收到认证请求后需要重新向服务器端发起请求 (其中带有认证响应信息) 。 该请求消息在经过网络服务器时某些字段包括 Request- URI 都有可能被修改。认证头域的 URI 参数用于传递终端发起请求时原始消息的Request-URI用于对认证信息进行认证,这样才能保证认证过程的正确性。
CNONCE:如果在服务器端超时后终端才向服务器返回了带有认证响应的新的请求消息,则服务器端需要重新产生 NONCE重新对用户进行认证。其中 NONCE中带有新的 NONCE,老的 NONCE会通过 CNONCE参数返回给终端。
ALGORITHM:用于传递生成 RESPONSE的算法。
6.3.2 响应消息
SIP 响应消息的格式,由起始行、消息头和消息体组成。通过换行符区分消息头中的每一行参数。对于不同的响应消息,有些参数可选。
响应消息结构
起始行 | SIP/协议版本 | 状态码 | 描述性短语 |
---|---|---|---|
消息头 | Call-ID: 值 | ||
Form: 值 | |||
To: 值 | |||
Cseq: 值 | |||
Via: 值 | |||
Contact: 值 | |||
Max-Forwards: 值 | |||
Allow: 值 | |||
Content-Length: 值 | |||
Supported: 值 | |||
User-Agent: 值 | |||
Content-Type: 值 | |||
…… | |||
消息体 | SDP |
7. SIP监控域互联结构
控制协议网关在SIP监控域和非SIP监控域的设备之间进行网络传输协议、控制协议、设备地址的转换;
媒体网关是进行媒体传输协议、媒体数据编码格式的转换。
8. 联网结构
8.1 级联结构
8.1.1 信令级联结构
信令流逐级转发
8.1.2 媒体级联结构
8.2 互联结构
互联的系统平台及设备不应向对方的SIP端口发送应用无关消息,避免应用无关消息占用系统平台及设备的SIP消息处理资源。
8.2.1 信令互联结构
处于平级关系,共享对方SIP监控域的监控资源
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?
· 展开说说关于C#中ORM框架的用法!