————sip协议详解————超全超清

————sip协议详解————超全超清内容摘要：

类型的消息体长度为 0 （如一个空的声音文件）。 ContentType 字段的示例： ContentType: 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  UserAgent UserAgent 头字段包含有发起请求的用户终端的信息。 显示用户代理的 软件版本信息可能会令用户在使用有安全漏洞的软件易受到外界攻击，因此，应该使 UserAgent 头字段成为可选配置项。 举例： UserAgent: Softphone  Expires Expires 头字段指定了消息（或消息内容）多长时间之后超时。 举例： Expires: 5  AcceptLanguage AcceptLanguage 头字段用在请求消息中，表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言类型。 如果 消息中没有 AcceptLanguage头字段，则服务器端认为客户端支持所有语言。 举例： AcceptLanguage: 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、 CHAPPASSWORD、 CARDDIGEST 等认证方式。 DIGEST 为 HTTPDIGEST 认证方式。 目前 SoftX3000 只支持HTTPDIGEST 方式。 以后为了实现 Uniphone 的卡号呼叫还会加入卡号认证的 CARDDIGEST 方式。 USERNAME：被认证的用户的用户名。 REALM：用于标识发起认证过程的域。 NONCE：由发起认证过程的实体产生的加密因子。 RESPONSE：终端在收到服务器的认证请求后根据服务器端产生的 NONCE、用户名、密码、 URI 等信息经过一定的算法生成的一个字符串。 该字符串中包含了经过加密后的用户密码。 （在认证过程中处理用户密码之外其他信息都会通过 SIP 消息以明文的方式在终端和服务器端进行传递。 ） URI：发起的呼叫请求消息的 RequestUR I。 由于终端在收到认证请求后需要重新向服务器端发起请求（其中带有认证响应信息）。 该请求消息在经过网络服务器时某些字段包括 Request－ URI 都有可能被修改。 认证头域的 URI 参数用于传递终端发起请求时原始消息的 RequestURI 用于对认证信息进行认证，这样才能保证认证过程的正确性。 CNONCE：如果在服务器端超时后终端才向服务器返回了带有认证响应的新的请求消息，则服务器端需要重新产生 NONCE 重新对用户进行认证。 其中NONCE 中带有新的 NONCE，老的 NONCE 会通过 CNONCE 参数返回给终端。 ALGORITHM：用于传递生成 RESPONSE 的算法。 举例： Authorization: DIGEST USERNAME=6540012, REALM=, NONCE=202061722310491179922, RESPONSE=b7c848831dc489f8dc663112b21ad3b6, URI=sip: (3) 请求消息示例 下面是 SIP 请求消息编码的示例： INVITE sip: SIP/ From: sip:。 tag=1ccb6df3 To: sip: CSeq: 1 INVITE CallID: 20973e49f7c52937fc6be224f9e52543@sx3000 Via: SIP/:5061。 branch=z9hG4bkbc427dad6 Contact: sip::5061 Supported: 100rel,100rel MaxForwards:70 Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE, NOTIFY,MESSAGE,REFER ContentLength:230 ContentType: application/sdp v: 0 o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 s: Sip Call c: IN IP4 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:”。 SIP 版本号为。 第二行： From 字 段。 指 明 请 求 发 起 方 的 地 址 为“ sip:”。 标记为“ 1ccb6df3”，用于共享同一SIP 地址的不同用户用相同的 CallID 发起呼叫邀请时，对用户进行区分。 第三行： To 字 段。 指 明 请 求 接 收 方 的 地 址 为“ sip:”。 从 From 和 To 字段，我们可以看出： IP 地址为 的 SoftX3000 控制下的终端 44510000 拨打 IP 地址为 SoftX3000控制下的 66500002终端。 终端类型可以为 SIP、 IAD/AG 下挂的 ESL 等。 第四行： Cseq 字段。 用于将 INVITE 请求和其触发的响应、对应的 ACK、CANCEL 请求相关联。 第五行： CallID 字段。 该字段唯一标识一个特定的邀请，全局唯一。 CallID 为“ 20973e49f7c52937fc6be224f9e52543@sx3000”， sx3000 为发起呼叫的SoftX3000 的域名， 20973e49f7c52937fc6be224f9e52543 为本地标识。 第六行： Via 字段。 该字段用于指示该请求历经 的路径。 “ SIP/”表示发送的协议，协议名为“ SIP”，协议版本为 ，传输层为 UDP；“ :5061”表示发送方 SoftX3000 IP 地址为 ，端口号为 5061；“ branch=z9hG4bkbc427dad6”为分支参数， SoftX3000 并行分发请求时标记各个分支。 第七行： Contact 字段。 指示其后的请求（如 BYE 请求）可以直接发往sip::5061，而不必借助 Via 字段。 第八行： 100rel 扩展，该字段为 100 类响应消息的可靠传输提供了相应的机制。 第九行： MaxForwards 字段。 表示该请求到达其目的地址所允许经过的中转站的最大值为 70。 第十行： Allow字段。 给出 IP 地址为 的 SoftX3000 支持的请求消息类型 列表。 第十一～十二行： ContentLength 字段，表示消息长度为 230 个字节。 第十三行： ContentType 字段，表示消息中携带的消息体是单消息体且为 SDP。 第十四行：空行，表示下面为 SDP 会话描述。 第十五行： SDP 协议版 本号，目前为 0 版本。 第十六行：会话拥有者 /创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号。 “ HuaweiSoftX3000”为用户名，用户名是用户在发起主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“ ”。 第一个“ 1073741831”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网络类型、地址类型、地址）构成会话的全球唯一的标识符。 第二个“ 1073741831”为版本号，指该会话公告的版本。 供代理服务器检测同一会话的若干个公告哪一个是 最新的公告。 其基本要求是会话数据修改后，其版本号应递增。 “ IN”指网络类型，为文本串形式，目前规定的“ IN”为 Inter。 “ IP4”指地址类型，为文本串形式，目前已定义的有“ IP4”和“ IP6”两种。 “ ”为创建会话的主机的 IP 地址。 对于 IP4 地址类型，可以是域名全称或点分十进制 IP4 地址表示形式。 对于 IP6地址类型，可以是域名全称或压缩文本 IP6 地址表示形式。 第十七行：会话名。 每个会话描述必需有一个且只有一个会话名。 第十八行：连接数据。 网络类型和地址类型目前的定义值仅限于 IN 和 IP4。 “ ”为 SoftX3000（ IP 地址： ）控制下的终端的 IP地址（终端类型为 SIP、 电话或 IAD/AG 下挂的 ESL 电话）。 第十九行：时间描述，给出会话激活的时间区段，允许会话周期性发生。 “ 0”表示起始时间。 该字段的格式为 t： 起始时间 终止时间。 其中起始时间和终止时间值为 NTP（ Network Time Protocol）时间值的十进制表示，单位为秒。 第二十行：媒体级描述，该部分给出只适用于该媒体流的信息。 “ audio”表示媒体 类型为音频。 目前定义的媒体类型有 5 种：音频、视频、应用、数据和控制。 “ 30000”指明媒体流发往的传送层端口，即终端的 UDP 端口号（终端类型为 SIP、 电话或 IAD/AG 下挂的 ESL 电话）。 “ RTP/AVP”为传送层协议，其值和“ c”行中的地址类型有关，对于 IP4 来说，大多数媒体业务流都在 RTP/UDP 上传送，已定义如下两类协议： RTP/AVP，音频 /视频应用文档，在 UDP 上传送； Udp， UDP 协议。 “ 8 0 4 18”对于音频和视频来说，就是RTP 音频 /视频应用文档中定义的媒体静荷类型。 表示会话中 所有这些格式都可能被用到，但第一个格式是会话的缺省格式。 该行总体表示，缺省 A 律 PCM 编码单信道音频信号，其在 RTP 音频 /视频应用文档中的静态静荷类型号为 8 ，该信号发往 UDP 端口 30000。 第二十一～二十四行： rtpmap 属性行，指明从 RTP 静荷类型至编码的映射关系。 该行的格式为： a: rtpmap:静荷类型 编码名 /时钟速率 [/编码参数 ]。 其中， 编码参数 指的就是音频信道数，对于视频信号尚无编码参数。 2. 响应消息 (1) 响应消息结构 如 图 34 所示是 SIP 响应消息的格式，由起始行、消息头和消息体组成。 通过换行符区分消息头中的每一行参数。 对于不同的响应消息，有些参数可选。 图 34 SIP响应消息结构 (2) 响应消息参数 响应消息参数请参考“请求消息参数”一节。 (3) 响应消息示例 下面是 SIP 响应消息编码的示例： SIP/ 180 Ringing From: si。