SIP交互流程

一、 SIP(Session Initiation Protocol)

会话初始协议（Session Initiation Protocol）是一种信令协议，用于初始、管理和终

止网络中的语音和视频会话，具体地说就是用来生成、修改和终结一个或多个参与者之间的会话。SIP的业务模式是一个点对点协议，其中有两个要素——SIP用户代理和SIP网络服务器。用户代理是呼叫的终端系统元素，而SIP服务器是处理与多个呼叫相关联信令的网络设备。用户代理本身具有一客户机元素（用户代理客户机UAC）和一服务器元素（用户代理服务器UAS）。客户机元素初始呼叫而服务器元素应答呼叫。这允许点到点的呼叫通过客户机-服务器协议来完成。下图是SIP业务的网络结构和各个参与者的关系。

SIP是互联网工程任务组（IETF）多媒体数据和控制体系结构的一个组成部分，因此

它与IETF的许多其他协议都有联系，例如RTP（实时传输协议）和SDP协议。SIP与许多其它的协议协同工作，仅仅涉及通信会话的信令部分(control message)。SIP报文内容传送会话描述协议(SDP)，SDP协议描述了会话所使用流媒体细节，如：使用哪个IP端口，采用哪种编解码器等等。SIP的一个典型用途是：SIP“会话”传输一些简单的经过封包的实时传输协议流。RTP本身才是语音或视频的载体

二、 业务流程和协议流程

这里介绍了注册和呼叫流程，其他场景需要了解，博客地址，比较详细。并有场景

的抓包截图等。SIP协议也是简单的讲解请求和应答消息种类，和各个头域讲解，详细的SIP协议请查看文档rfc3261。

1．注册流程：

注册流程图如下图，举例用sip客户端在机器上，以1001号码，向上的Freeswitch注册。 抓包截图如下图

客户端第一次发送的REGISTER包体内容如下图， expries=3600

服务器返回的401包体内容如下图

客户端带着验证信息项服务器发送REGISTER包体内容如下图 服务器给客户端返回注册成功200OK包体内容如下图

2．注销流程：

客户端注销如下图，举例用上的SIP客户端注销。用户号码是1000。 注销抓包截图如下

客户端向服务器发送的注销REGISTER包体信息如下图，expries=0;

服务器向客户端返回确认消息200OK的包体如下图

3． 基本呼叫建立过程:

呼叫流程如下图，举例上以1001号码注册到服务器，上以1000号码注册到服务器上，1001呼叫1000。

呼叫过程抓包流程如下图

1001发送向服务器发送INVITE请求的包体内容如下

Max-Forwards: 70 Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 736 INVITE Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE Supported: replaces,norefersub,100rel User-Agent: Twinkle/ 305 v=0 s=- t=0 0 m=audio 8000 RTP/AVP 98 97 8 0 3 101 a=rtpmap:98 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 服务器返回给用户1001,100 Trying消息体内容如下

SIP/ 100 Trying Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 737 INVITE Content-Length: 0 服务器向被叫1000转送INVITE请求消息包内容如下

Max-Forwards: 69

Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces

Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, , message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 242

X-FS-Support: update_display,send_info v=0

s=FreeSWITCH t=0 0

m=audio 19014 RTP/AVP 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20

被叫1000向服务器发送100 Tring 消息体内容如下

SIP/ 100 Trying Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470 Content-Length: 0 被叫1000向服务器发送180 Ringing的消息体内容如下

SIP/ 180 Ringing Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470 User-Agent: X-Lite release stamp 82158 Allow-Events: talk, hold Content-Length: 0

服务器向主叫1001发送183消息体内容入下，（180不带SDP消息体，183带SDP消息

体，可以看到SDP中的地址是说明服务器中间做了媒体转发，不是两个客户端点对点发送媒体流）

SIP/ 183 Session Progress

Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 737 INVITE Accept: application/sdp

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces

Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, , message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 218 v=0

s=FreeSWITCH t=0 0

m=audio 31502 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20

被叫端接通电话，向服务器发送200OK消息的内容如下

SIP/ 200 OK Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, OPTIONS, MESSAGE Content-Type: application/sdp Supported: replaces User-Agent: X-Lite release stamp 82158 Content-Length: 201 v=0 s=X-Lite release stamp 82158 t=0 0 m=audio 62266 RTP/AVP 8 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv

服务器向被叫端发送ACK确认信息，消息体内容如下

Max-Forwards: 70 Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470 Content-Length: 0 服务器将200OK转发给主叫，消息体内容如下

SIP/ 200 OK Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 737 INVITE Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, , message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 218 v=0 s=FreeSWITCH t=0 0 m=audio 31502 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 通话建立，主叫向服务器发送ACK确认信息，消息体内容如下

Max-Forwards: 70 Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 737 ACK User-Agent: Twinkle/ 0 4． 会话更改流程：

在双方通话过程中，一方可以更改通话使用的媒体信息，如：收发媒体流的IP和

PORT，通话过程所使用的媒体格式等。通过再次发送INVITE或UPDATE消息体，携带新的SDP消息。场景难触发，消息体内容没有什么特殊，在这里就不贴了。

5． 正常呼叫释放过程：

流程图如下图，被叫端先停止通话，举例上的客户端先停止通话，向服务器发送BYE。

抓包如下图；

发送BYE的消息体内容如下

Max-Forwards: 70 Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 738 BYE User-Agent: Twinkle/ 0

服务器向发送200OK确认信息，包体内容如下

SIP/ 200 OK Call-ID: ihvgztnhipwftni@zj-B85M-D3H CSeq: 738 BYE（针对什么请求的响应） Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Content-Length: 0 服务器向转发BYE消息体内容如下

Max-Forwards: 70 Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Reason: ;cause=16;text=\"NORMAL_CLEARING\" Content-Length: 0 向服务器发送200OK确认消息的消息体内容如下

SIP/ 200 OK Call-ID: d37fdc79-15e9-1235-ad86-5200bcb470 User-Agent: X-Lite release stamp 82158 Content-Length: 0 6． 被叫忙呼叫释放：

流程图如下，举例上用1001注册成功，呼叫正在通话的上的1000。

其他的请求和响应的包体都一样，下面是被叫端返回用户忙包体信息如下

SIP/ 486 Busy Here（返回码和原因） Call-ID: 0ffad52d-168c-1235-ad86-5200bcb470 （回复的请求） User-Agent: X-Lite release stamp 82158 Content-Length: 0 7．被叫无应答流程一：

主叫在呼叫被叫过程中，未收到200OK，主叫挂断着同电话，向服务器发送Cancel

消息。

这里之贴出Cancel消息体和服务器返回的487消息体，内容如下

Max-Forwards: 70 Call-ID: xwzhthujzqebpfo@zj-B85M-D3H CSeq: 87 CANCEL User-Agent: Twinkle/ 0 SIP/ 487 Request Terminated Call-ID: xwzhthujzqebpfo@zj-B85M-D3H CSeq: 87 INVITE Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, , message-summary, refer Content-Length: 0 8．被叫无应答流程二：

主叫呼叫被叫，被叫响铃但不解通电话，过30秒后，返回请求超时。

9．遇忙呼叫前转： 10．无应答呼叫前转流程： 11．呼叫保持： 12．呼叫等等：

三、 SIP消息类型

SIP消息采用文本方式编码，分为两类：请求消息和响应消息。 1. 请求消息

用于客户端为了激活按特定操作而发给服务器的SIP消息，包括 INVITE， ACK，OPTIONS，BYE，CANCEL和REGISTER消息等，各消息功能如所示。

表3-1 请求消息

请求消息 消息含义 发起会话请求，邀请用户加入一个会话，会话描述含于消息体中。对于两方呼叫来说，主叫方在会话描述中指示其能够接受的媒体类型及其参数。被叫方必需在成功响应消息的消息体中指明其希望接受哪些媒体，还可以指示其行将发送的媒体。 如果收到的是关于参加会议的邀请，被叫方可以根据Call-ID或者会话描述中的标识确定用户已经加入该会议，并返回成功响应消息。 INVITE ACK BYE CANCEL REGISTER OPTIONS 证实已收到对于INVITE请求的最终响应。该消息仅和INVITE消息配套使用。 结束会话 取消尚未完成的请求，对于已完成的请求（即已收到最终响应的请求）则没有影响 注册 查询服务器的能力 2. 响应消息

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

表3-2 响应消息

序号 状态码 消息功能 信息响应（呼叫进展表示已经接收到请求消息，正在对其进行处理 响应） 100 1xx 180 181 182 成功响应 2xx 200 重定向响应 300 301 3xx 302 303 305 380 客户出错 400 401 402 403 404 405 406 4xx 407 408 410 413 414 415 416 420 421 OK 表示需要采取进一步动作，以完成该请求 多重选择 永久迁移 临时迁移 见其它 使用代理 代换服务 表示请求消息中包含语法错误或者SIP服务器不能完成对该请求消息的处理 错误请求 无权 要求付款 禁止 没有发现 不允许的方法 不接受 要求代理权 请求超时 消失 请求实体太大 请求URI太大 不支持的媒体类型 不支持的URI方案 分机无人接听 要求转机 试呼叫 振铃 呼叫正在前转 排队 表示请求已经被成功接受、处理 序号 423 480 481 482 483 484 485 486 487 488 491 493 状态码 间隔太短 暂时无人接听 呼叫腿/事务不存在 相环探测 跳频太高 地址不完整 不清楚 线路忙 终止请求 此处不接受 代处理请求 难以辨认 消息功能 服务器出错 500 501 502 5xx 503 504 505 513 全局故障 600 6xx 603 604 606 表示SIP服务器故障不能完成对正确消息的处理 内部服务器错误 没实现的 无效网关 不提供此服务 服务器超时 SIP版本不支持 消息太长 表示请求不能在任何SIP服务器上实现 全忙 拒绝 都不存在 不接受 请求消息和响应消息都包括SIP头字段和SIP消息字段。 在SIP消息中加入SDP消息正文部分。

四、 消息结构

1. 请求消息 (1) 请求消息结构

如所示是SIP请求命令的格式，由起始行、消息头和消息体组成。通过换行符区分消息头中的每一条参数行。对于不同的请求消息，有些参数可选。

图3-3 SIP请求消息结构

(2) 请求消息参数

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

Call-ID

该字段用以唯一标识一个特定的邀请或标识某一客户的所有登记。需要注意的是，一个多媒体会议可能会有多个呼叫，每个呼叫有其自己的Call-ID。例如，某用户可数次邀请某人参加同一历时很长的会议。用户也可能会收到数个参加同一会议或呼叫的邀请，其Call-ID各不相同。用户可以利用会话描述中的标识，例如SDP中的o（源）字段的会话标识和版本号判定这些邀请的重复性。 Call-ID的一般格式为： Call-ID：本地标识@主机

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

其中，为主机的IP地址，为全局唯一的本地标识。 From

所有请求和响应必须包含此字段，以指示请求的发起者。服务器将此字段从请求消息复制到响应消息。 该字段的一般格式为：

From:显示名;tag=xxxx

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

From字段的示例： To

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

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

注意，在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/UDP 由点发出的请求消息路径外部地址为的网络地址翻译点后，到达代理服务器。后者注意到前站发送地址和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字段的示例： 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字段的示例为： 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 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的算法。 举例：

(3) 请求消息示例

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

CSeq: 1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e523@sx3000 Supported: 100rel,100rel Max-Forwards:70

Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,

NOTIFY,MESSAGE,REFER Content-Length:230

Content-Type: application/sdp v: 0

s: Sip Call 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版本号为。

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

第三行：To字段。指明请求接收方的地址为。 从From和To字段，我们可以看出：

IP地址为的SoftX3000控制下的终端拨打IP地址为的SoftX3000控制下的终端。终端类型可以为SIP、、IAD/AG下挂的ESL等。

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

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

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

第七行：Contact字段。指示其后的请求（如BYE请求）可以直接发往，而不必借助Via字段。

第八行：100rel扩展，该字段为100类响应消息的可靠传输提供了相应的机制。 第九行：Max-Forwards字段。表示该请求到达其目的地址所允许经过的中转站的最大值为70。

第十行：Allow字段。给出IP地址为的SoftX3000支持的请求消息类型 列表。 第十一～十二行：Content-Length字段，表示消息长度为230个字节。

第十三行：Content-Type字段，表示消息中携带的消息体是单消息体且为SDP。 第十四行：空行，表示下面为SDP会话描述。 第十五行：SDP协议版本号，目前为0版本。

第十六行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号。“HuaweiSoftX3000”为用户名，用户名是用户在发起主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个为版本号，指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目前规定的“IN”为Internet。“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) 响应消息结构

如所示是SIP响应消息的格式，由起始行、消息头和消息体组成。通过换行符区分消息头中的每一行参数。对于不同的响应消息，有些参数可选。

图3-4 SIP响应消息结构

(2) 响应消息参数

响应消息参数请参考“请求消息参数”一节。 (3) 响应消息示例

下面是SIP响应消息编码的示例：

SIP/ 180 Ringing Cseq:1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e523@sx3000 Require:100rel RSeq:1

Content-Length:157

Content-Type:application/sdp v=0

s=Sip Call t=0 0

m=audio 30016 RTP/AVP 8 a=rtpmap:8 PCMA/8000

第一行：SIP协议，版本号为。状态码为180。“Ringing”为注释短语。表示向被叫送振铃。

第二行、第三行：请参考“请求消息示例”小节。

第四行：Cseq字段。用于将INVITE请求和其触发的响应、对应的ACK、CANCEL请求相关联。该响应消息和上文中的请求消息Cseq字段相同，均为“1 INVITE”，表明该响应消息由上文中的请求消息触发。

第五～第十一行：请参考“请求消息示例”小节。 第十二行：空行，表示下面为SDP会话描述。 第十三行：SDP协议版本号，目前为0版本。

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

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

第十六行：连接数据。网络类型和地址类型目前的定义值仅限于IN和IP4。为SoftX3000（IP地址：）控制下的终端的IP地址（终端类型为SIP、电话或IAD/AG下挂的ESL电话）。

第十七行：时间描述，给出会话激活的时间区段，允许会话周期性发生。

第十八行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。“30016”指明媒体流发往的传送层端口，即终端的UDP端口号（终端类型为SIP、电话或IAD/AG下挂的ESL电话）。“RTP/AVP”为传送层协议，其值和“c”行中的地址类型有关，对于IP4来说，大多数媒体业务流都在RTP/UDP上传送，已定义如下两类协议：RTP/AVP，音频/视频应用文档，在UDP上传送；Udp，UDP协议。“8”就是RTP音频/视频应用文档中定义的媒体静荷类型。

第十九行：rtpmap属性行，指明从RTP静态类型之编码的映射关系。RTP静态类型“8”对应的编码为PCMA。