VOLTE问题分类指导手册.xlsx

149.3KB 132下载 1157浏览 5评分

常见问题分类

问题大类	问题分项	问题描述	分析要点
端到端问题	（2G返回4G）收到paging过晚，导致接续超时	终端eSRVCC后从2G返回4G，后续起呼被叫没有收到PS paging，随后收到CS paging时间过晚（接近10s），随后被叫CSFB，但由于总接续时间过长，出现主叫超时（30s）CANCLE的未接通情况。	1)此类问题可看eSRVCC后返回4G，被叫收到BYE并回复481的时间，如果起呼发生在收到BYE消息之前，多为这类问题； 2）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话； 3）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 4）提供问题点的RSRP及SINR值。
端到端问题	（2G返回4G）收到上一次（上几次）的invite等SIP消息	终端eSRVCC后从2G返回4G，主叫起呼发起invite，但被叫先收到BYE消息和上一次的invite消息（从CALL ID区分），随后才收到本次的Invite,被叫随后直接回复CANCLE造成未接通。	1)此类问题可看eSRVCC后返回4G，发起新的呼叫，此时BYE消息和前一次的invite几乎是不间断都发下来的，再之后才收到本次invtie，通过CALL ID去区分不同会话的SIP消息； 2）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话； 3）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 4）提供问题点的RSRP及SINR值。
专载异常问题	切换过程中专载被MME释放（NAS消息基站没收到）	主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，导致专载被释放，终端回复invite580，呼叫未接通，具体原因如下：终端建立专载成功，回复重配完成并上发NAS确认消息，但基站CTS信令显示NAS消息没有收到，造成切换中MME发给目标小区的HandoverRequest消息里面e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。	1）此类问题发生在呼叫建立阶段，切换和专载建立同时进行； 2）出现专载释放的终端回复的是invite580错误，另一个终端收到invite503错误； 3）需要结合CTS查看NAS消息基站是否收到，查看是否切换流程在前，MME收到NAS消息再后； 4）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 5）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
	切换过程中专载被MME释放（NAS消息基站已收到）	主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，导致专载被释放，终端回复invite580，呼叫未接通，具体原因如下：终端建立专载成功，回复重配完成并上发NAS确认消息，基站CTS信令显示NAS已收到并上发给MME，但由于切换流程在前，MME收到NAS消息之前，MME已经发给目标小区的HandoverRequest消息，里面e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。	1）此类问题发生在呼叫建立阶段，切换和专载建立同时进行； 2）出现专载释放的终端回复的是invite580错误，另一个终端收到invite503错误； 3）需要结合CTS查看NAS消息基站是否收到，查看是否切换流程在前，MME收到NAS消息再后； 4）分析中应包含主叫和被叫，终端LOG和CTS信令表现。
	专载建立失败	在呼叫会话建立过程中，在接通之前，主叫后者被叫收到invite500错误消息，原因为Server Internal Error 500，导致会话中断，导致未接通事件。（需核查SIP500前基站侧有无context 释放信令）
	核心网未下发专载建立请求	主叫起呼后，主叫或被叫没有收到核心网下发的E_RAB SETUP REQUEST，导致的未接通。	1）查看CTS中基站是否收到专载建立请求，收到是否下发； 2）提供问题点的RSRP及SINR值； 3）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 4）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
无线覆盖问题	非弱信号，但异频重定向	终端上报异频测报，由于邻区漏配，PCI未知导致基站下发重定向RELEASE，会导致未接通或掉话事件。（给出应添加邻区）	1）终端上报A3事件，但PCI在邻区列表中不存在（重配消息中可以看到已配置的邻区PCI），基站下发RELEASE消息，携带原因值为REDIRECTION,同时还携带目标频点； 2）记录源小区，目标小区的eNB ID,PCI等信息； 3）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 4）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
	弱信号，未eSRVCC	终端处于弱信号区，达到了B2门限，但终端没有进行进行eSRVCC，导致异系统重定向掉话或者RSRP/SINR差掉话： 1）终端没有上报B2：看基站是否下发到2G的切换配置，导致终端未测量到合要求的2G小区，所以未上报B2，终端如果RSRP达到-122，触发异系统重定向，导致掉话。 2）终端上报B2，但B2测报中目标小区的NCC、BCC与后台配置不一致，导致无法eSRVCC，触发异系统重定向，导致掉话。（需核查是否4G邻区漏配拖弱、需核查2G邻区参数配置是否正确）	1）发现邻区漏配的，记录源小区，目标小区的eNB ID,PCI等信息； 2）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 3）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
	非弱信号，强干扰	RSRP>-110，但SINR较差（SINR<-3），导致会话中断，产生未接通、掉话事件。（给出小区底噪统计指标）	1）发现邻区漏配的，记录源小区，目标小区的eNB ID,PCI等信息 2）检查是否存在模3干扰，是否重叠覆盖干扰； 3）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 4）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
	RRC重建，整体弱信号SINR差，专载建立失败	通话过程中，无线环境差，通常RSRP<-115，或SINR<-3，或RSRP和SINR同时较差，造成RRC重建，专载建立失败。（需核查是否邻区漏配拖弱）	1）查看重建立的原因； 2）提供问题点的RSRP及SINR值， 3）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 4）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
	非弱信号，但接入异常	此类问题多伴随在eSRVCC切换失败之后，当eSRVCC切换失败后，终端会重新发起invite，尝试恢复4G的会话，但在终端重新接入4G小区的过程在，出现RRC建立成功后，链路立刻又被基站的释放，且是终端不停尝试接入几个不同小区都出现被释放，导致掉话。	1）查看CTS基站释放的原因，并查看小区是否异常； 2）检查是否存在模3干扰，是否存在强干扰。
eSRVCC问题	Alerting中eSRVCC失败导致的未接通	被叫已振铃，此时主叫或被叫达到了eSRVCC切换条件并进行切换，切换后会话中断，未能接通。	1）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 2）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
eSRVCC问题	eSRVCC回落2G切换失败	终端上报B2并收到基站的mobility命令，但2G侧无响应导致掉话，通常2G侧没有信令，或者收到RR HANDOVER COMMAND但终端没有回复RR HANDOVER COMPLETE。（需核查2G邻区参数配置是否正确）	1）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 2）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
CSFB问题	核心网15s超时，发起CSFB，被叫回落失败	核心网15s超时，发起CSFB，被叫回落2G失败	1）分析中应包含主叫和被叫，终端LOG和CTS信令表现； 2）分析中说明上一次呼叫是正常、未接通、掉话、通话中eSRVCC，并且说明是VoLTE、CSFB通话。
	起呼后，被叫直接CSFB，回落失败	起呼后，被叫直接CSFB，回落2G失败
	主叫CSFB回落失败	主叫CSFB回落失败

VOLTE语音呼叫流程

序号	消息解释
1	主叫发INVITE消息，触发主叫RRC建立过程，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码等。
2	主叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载。例如在本例中，信令无线承载SRB-ID=2;QCI=9的默认承载的eps-BearerID=5,DRB-ID=3;QCI=5的SIP信令承载的eps-BearerID=6,DRB-ID=4
3	核心网侧收到主叫的INVITE消息以后，给主叫发送INVITE的应答消息，INVITE 100.表示正在处理中。
4	核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户
5	被叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载
6	核心网在QCI5 RB承载上，给被叫用户发送INVITE消息
7	被叫对INVITE消息的响应
8	被叫方通知主叫方，自己所支持的媒体类型和编码。
9	主叫建立QCI1的数据无线承载，用于承载语音数据，使用UM方式。例如本例中，eps-BearerID=7，DRB-ID=5。关键参数包括头压缩参数，TTI Bundling，SPS。DRX参数也会按照语音业务的要求进行重新配置。
10	被叫建立QCI1的数据无线承载。例如本例中QCI1承载的eps-BearerID=7，DRB-ID=5。
11	核心网通知主叫终端的SM层，建立qci=1的承载,例如：eps-BearerID=7
12	主叫收到被叫的INVITE 183消息
13	核心网通知被叫终端的SM层，建立qci=1的承载
14	主叫收到INVITE 183消息以后，发送确认消息PRACK，启动资源预留过程，
15	被叫收到主叫的PRACK以后，返回PRACK 200响应，启动资源预留过程，
16	主叫收到被叫的PRACK 200以后，发送UPDATE消息，标明资源预留成功。
17	被叫收到主叫的UPDATE消息后，得知主叫UE的资源预留成功。被叫发送UPDATE 200，标明被叫资源预留成功，
18	被叫发送INVITE 180，被叫振铃，主叫放回铃音
19	被叫摘机，被叫向主叫发送INVITE 200.
20	主叫给IMS服务器发ACK，证实已经收到IMS对于INVITE请求的最终响应。核心网IMS服务器发ACK消息给被叫，证实对于INVITE请求的最终响应。
21	主叫挂机，发BYE,请求结束本次会话。IMS服务器给被叫发送BYE,请求结束本次会话。
22	被叫挂机，回BYE 200消息，核心网IMS服务器给主叫发BYE 200，标明会话结束。
23	通过RRCConntctionReconfiguration消息和去激活EPS专用承载消息，主叫删除QCI=1的数据无线承载。
24	被叫删除QCI=1的数据无线承载。

主被叫对照分析

	VOLTE主叫信令解析：	对关键流程解释：		VOLTE被叫信令解析：	对关键流程解释：
上	INVITE	主叫发INVITE消息，触发主叫RRC建立过程，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码等。之后2条信令的是进行鉴权请求.
上	Service Request
上	RRC Connection Request
下	RRC Connection Setup
上	RRC Connection Setup Complete 1
下	Security Mode Command
上	Security Mode Complete
下	RRC Connection Reconfiguration	主叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载。例如在本例中，信令无线承载SRB-ID=2；QCI=9的默认承载的eps-BearerID=5,DRB-ID=3;QCI=5的SIP信令承载的eps-BearerID=6,DRB-ID=4。
上	RRC Connection Reconfiguration Complete 2
下	INVITE 100 3	核心网侧收到主叫的INVITE消息以后，给主叫发送INVITE的应答消息，INVITE100表示正在处理中。
下	RRC Connection Reconfiguration	主叫建立QCI1的数据无线承载，用于承载语音数据，使用UM方式。例如本例中，eps-BearerID=7,DRB-ID=5.关键参数包括头压缩参数,TTI Bundling.SPS.DRX参数也会按照语音业务的要求进行重新配置。	下	Paging 4	核心网侧向处于空闲态的被叫发送INVITE消息，由于被叫处理空闲状态，所以核心网侧触发寻呼消息，寻呼处于空闲状态的的被叫用户。
上	RRC Connection Reconfiguration Compete 9		上	Service Request
下	Activate Dedicated EPS Bearer Context Request 11	核心网通知主叫终端的SM层，建立QCI=1的承载，例如：eps-BearerID=7.	上	RRC Connection Request
上	Activate Dedicated EPS Bearer Context Accept		下	RRC Connection Setup
上	UL Information Transfer		上	RRC Connection Setup Complete
			下	Security Mode Command
下	DL Information Transfer		上	Security Mode Complete
下	Modify EPS Bearer Context Request		下	RRC Connection Reconfiguration	被叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载.
上	Modify EPS Bearer Context Accept		上	RRC Connection Reconfiguration Complete 5
上	UL Information Transfer		下	INVITE 6	核心网在QCI5 RB承载上，给被叫用户发送INVITE消息。
			上	INVITE 100 7	被叫对INVITE消息的响应
			上	INVITE 183 8	被叫方通知主叫方，自己所支持的媒体类型和编码
			下	RRC Connection Reconfiguration	被叫建立QCI1的数据无线承载。例如本例中QCI1承载的eps-BearerID=7,DRB-ID=5.
			上	RRC Connection Reconfiguration Compete 10	被叫建立QCI1的数据无线承载。例如本例中QCI1承载的eps-BearerID=7,DRB-ID=5.
下	INVITE 183 12	主叫收到被叫的INVITE183消息。	下	Activate Dedicated EPS Bearer Context Request 13	核心网通知被叫终端的SM层，建立QCI=1的承载。
			上	Activate Dedicated EPS Bearer Context Accept	核心网通知被叫终端的SM层，建立QCI=1的承载。
			上	UL Information Transfer
上	PRACK 14	主叫收到INVITE183消息以后，发送确认消息PRACK，启动资源预留过程。	下	PRACK 14	主叫收到INVITE183消息后，发送确认消息PRACK，启动资源预留过程。
下	PRACK 200 15	被叫收到主叫的PRACK以后，返回PRACK200响应，启动资源预留过程，	上	PRACK 200 15	被叫收到主叫的PRACK以后，返回PRACK200响应，启动资源预留过程。
上	UPDATE 16	主叫收到被叫的PRACK200以后，发送UPDATE消息，标明资源预留成功。	下	UPDATE 16
下	UPDATE 200 17		上	UPDATE 200 17	被叫收到主叫的UPDATE消息后，得知主叫UE的资源预留成功。被叫发送UPDATE200，标明被叫资源预留成功。
下	DL Information Transfer
下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept
上	UL Information Transfer
下	INVITE 180 18	被叫发送INVITE180，被叫振铃，主叫放回铃音	上	INVITE 180 18	被叫发送INVITE180，被叫振铃，主叫放回铃音。
下	DL Information Transfer		下	DL Information Transfer
下	Modify EPS Bearer Context Request		下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept		上	Modify EPS Bearer Context Accept
上	UL Information Transfer		上	UL Information Transfer
下	INVITE 200 19	被叫摘机，被叫向主叫发送INVITE200.	上	INVITE 200 19	被叫摘机，被叫向主叫发送INVITE200.
			下	DL Information Transfer
			下	Modify EPS Bearer Context Request
			上	Modify EPS Bearer Context Accept
			上	UL Information Transfer
上	ACK 20	主叫给IMS服务器发送ACK，证实已经收到IMS对于INVITE请求的最终响应。核心网IMS服务器发ACK消息给被叫，证实对于INVITE请求的最终响应。	下	ACK 20	主叫给IMS服务器发ACK，证实已经收到IMS对于INVITE请求的最终响应。核心网IMS服务器发送ACK消息给被叫，证实对于INVITE请求的最终响应。
上	Measuerment Report
上	Measuerment Report
上	Measuerment Report
上	Measuerment Report

主叫信令流程解释

上下行	VOLTE主叫信令解析：	对关键流程解释：
上	INVITE	主叫发INVITE消息，触发主叫RRC建立过程，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码等。
上	Service Request
上	RRC Connection Request
下	RRC Connection Setup
上	RRC Connection Setup Complete 1
下	Security Mode Command
上	Security Mode Complete
下	RRC Connection Reconfiguration	主叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载。例如在本例中，信令无线承载SRB-ID=2；QCI=9的默认承载的eps-BearerID=5,DRB-ID=3;QCI=5的SIP信令承载的eps-BearerID=6,DRB-ID=4。
上	RRC Connection Reconfiguration Complete 2
下	INVITE 100 3	核心网侧收到主叫的INVITE消息以后，给主叫发送INVITE的应答消息，INVITE100表示正在处理中。
下	RRC Connection Reconfiguration	主叫建立QCI1的数据无线承载，用于承载语音数据，使用UM方式。例如本例中，eps-BearerID=7,DRB-ID=5.关键参数包括头压缩参数,TTI Bundling.SPS.DRX参数也会按照语音业务的要求进行重新配置。
上	RRC Connection Reconfiguration Compete 9
下	Activate Dedicated EPS Bearer Context Request 11	核心网通知主叫终端的SM层，建立qci=1的承载，例如：eps-BearerID=7.
下	INVITE 183 12	主叫收到被叫的INVITE183消息。
上	Activate Dedicated EPS Bearer Context Accept
上	UL Information Transfer
上	PRACK 14	主叫收到INVITE183消息以后，发送确认消息PRACK，启动资源预留过程。
下	PRACK 200 15	被叫收到主叫的PRACK以后，返回PRACK200响应，启动资源预留过程，
上	UPDATE 16	主叫收到被叫的PRACK200以后，发送UPDATE消息，标明资源预留成功。
下	DL Information Transfer
下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept
上	UL Information Transfer
下	UPDATE 200 17	被叫收到主叫的UPDATE消息后，得知主叫UE的资源预留成功。被叫发送UPDATE200，标明被叫资源预留成功。
下	DL Information Transfer
下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept
上	UL Information Transfer
下	INVITE 180 18	被叫发送INVITE180，被叫振铃，主叫放回铃音
下	DL Information Transfer
下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept
上	UL Information Transfer
下	INVITE 200 19	被叫摘机，被叫向主叫发送INVITE200.
上	ACK 20	主叫给IMS服务器发送ACK，证实已经收到IMS对于INVITE请求的最终响应。核心网IMS服务器发ACK消息给被叫，证实对于INVITE请求的最终响应。
上	Measuerment Report
上	Measuerment Report
上	Measuerment Report
上	Measuerment Report
上	BYE 21	主叫挂机，发送BYE,请求结束本次会话。IMS服务器给被叫发送BYE,请求结束本次会话。
下	BYE 200 22	被叫挂机，回BYE200消息，核心网IMS服务器给被叫发送BYE200，标明会话结束。
下	RRC Connection Reconfiguration	通过RRC Connection Reconfiguration消息和去激活EPS专用承载消息，主叫删除QCI=1的数据无线承载。
上	RRC Connection Reconfiguration Complete
下	Deactivate EPS Bearer Context Request 23
上	Deactivate EPS Bearer Context Accept
上	ULInformation Transfer
下	RRCConnectionRelease

被叫信令流程解释

上下行	VOLTE被叫信令解析：	对关键流程解释：
下	Paging 4	核心网侧向处于空闲态的被叫发送INVITE消息，由于被叫处理空闲状态，所以核心网侧触发寻呼消息，寻呼处于空闲状态的的被叫用户。
上	Service Request
上	RRC Connection Request
下	RRC Connection Setup
上	RRC Connection Setup Complete
下	Security Mode Command
上	Security Mode Complete
下	RRC Connection Reconfiguration	被叫建立SRB2心理无线承载，QCI9默认承载和QCI5 SIP信令无线承载.
上	RRC Connection Reconfiguration Complete 5
下	INVITE 6	核心网在QCI5 RB承载上，给被叫用户发送INVITE消息。
上	INVITE 100 7	被叫对INVITE消息的响应
上	INVITE 183 8	被叫方通知主叫方，自己所支持的媒体类型和编码
下	RRC Connection Reconfiguration	被叫建立QCI1的数据无线承载。例如本例中QCI1承载的eps-BearerID=7,DRB-ID=5.
上	RRC Connection Reconfiguration Compete 10	被叫建立QCI1的数据无线承载。例如本例中QCI1承载的eps-BearerID=7,DRB-ID=5.
下	Activate Dedicated EPS Bearer Context Request 13	核心网通知被叫终端的SM层，建立QCI=1的承载。
上	Activate Dedicated EPS Bearer Context Accept	核心网通知被叫终端的SM层，建立QCI=1的承载。
上	UL Information Transfer
下	PRACK 14	主叫收到INVITE183消息后，发送确认消息PRACK，启动资源预留过程。
上	PRACK 200 15	被叫收到主叫的PRACK以后，返回PRACK200响应，启动资源预留过程。
下	UPDATE 16	主叫收到被叫的PRACK200以后，发送UPDATE消息，标明资源预留成功。
上	UPDATE 200 17	被叫收到主叫的UPDATE消息后，得知主叫UE的资源预留成功。被叫发送UPDATE200，标明被叫资源预留成功。
上	INVITE 180 18	被叫发送INVITE180，被叫振铃，主叫放回铃音。
下	DL Information Transfer
下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept
上	UL Information Transfer
上	INVITE 200 19	被叫摘机，被叫向主叫发送INVITE200.
下	DL Information Transfer
下	Modify EPS Bearer Context Request
上	Modify EPS Bearer Context Accept
上	UL Information Transfer
下	ACK 20	主叫给IMS服务器发ACK，证实已经收到IMS对于INVITE请求的最终响应。核心网IMS服务器发送ACK消息给被叫，证实对于INVITE请求的最终响应。
下	BYE 21	主叫挂机，发送BYE,请求结束本次会话。IMS服务器给被叫发送BYE，请求技术本次会话。
上	BYE 200 22	被叫挂机，回复BYE200消息，核心网IMS服务器给主叫发送BYE200，标明会话结束。
下	RRC Connection Reconfiguration	被叫删除QCI=1的数据无线承载。
上	RRC Connection Reconfiguration Complete
下	Deactivate EPS Bearer Context Request 24
上	Deactivate EPS Bearer Context Accept
上	ULInformation Transfer
下	RRCConnectionRelease

SIP消息

类别	描述	动作
1xx	信息	这表明调用之前完成也被称为临时响应的状态。
2xx	成功	请求已成功。如果这是一个邀请，确认应发送;否则，停止请求的重发。
3xx	重定向	服务器返回的可能位置。客户端应该重试另一个服务器的请求。
4xx	客户端错误	请求已经由客户端失败，原因是一个错误。客户端可以重试请求，如果它是根据响应拟订。
5xx	服务器故障	请求已经由该服务器失败，原因是一个错误。请求可以在另一台服务器退出。
6xx	全局失败	请求已失败。该请求不应该在这个或其他服务器再次尝试。

信息(1xx)
信息响应用于指示呼叫进程。通常情况下，响应是端对端（除100尝试）。信息的响应的主要目的是阻止INVITE请求的重发。
信息响应包括以下对策：
100 尝试
这种特殊的情况下的响应仅仅是一个逐跳请求。
它永远不会转发，不得包含邮件正文。
它被用于避免INVITE请求的重传。
180 响铃
此响应被用来指示一个INVITE已经接收由用户代理和警报正在发生。
181 呼叫被转发
此响应用于指示该呼叫已被转发到另一端点。
它发送的信息有可能会使用到呼叫者。
它给该呼叫者的状态，作为一个转发操作可以导致在呼叫同时较长时间来回答。
182 呼叫队列
此响应被用来指示该INVITE已经接收并且将在一个队列进行处理。
183 会话进度
它表明，有关会话的进度的信息可以存在于消息主体或媒体流。
不像100尝试响应，183端到端的响应，并建立一个对话。
一个典型的使用这种反应是为了让UAC通过网关进入PSTN听到手机铃声，忙音，或在通话录音通知。
成功(2xx)
此类反应是指用于指示一个请求已被接受。它包括以下对策：
200 OK
200OK用于接受会话邀请。
它表示成功完成的请求或接受。
202 接受
202接受表示该UAS已经接收并理解的请求，但该请求可能没有被授权或由服务器处理。
它是常用响应订阅，请参阅方法。
重定向(3xx)
通常，这些类响应由重定向服务器响应INVITE发送。它们也被称为类重定向响应。它包括以下对策：
300 多重选择
它包含多个联系人报头字段以指示该位置的服务已经在Request-URI返回SIP URI多个可能的位置。
301 永久移动
这种重定向响应包含与被叫方的新的永久URI一个Contact头字段。
地址可以保存并在今后的INVITE请求中使用。
302 临时移动
这个重定向响应包含一URI，它是当前有效的，但不是永久的。
即，位置是有效的指定的时间的持续时间。
305 使用代理
这个响应包含指向具有关于呼叫方的权威信息代理服务器的URI。
这种反应可以由UAS发出的来电筛选代理发送。
380 可替代服务
这个响应返回的URI，指示服务的被叫方希望的类型。
例如，一个通话可以被重新定向到一个语音信箱服务器。

本文档由 lyf 上传于

给文档打分:

热门文档