SIP基本知识讲解及常见案例v1.0.doc

WCDMA-CS 数据配置规范内部公开资料编码产品名称MSOFTX300/UMG8900使用对象技术服务工程师产品版本（MSOFTX3000）R006C05及以后版本编写部门核心网产品技术服务部资料版本1.0SIP基础知识及常见案例拟 制：核心网产品LMT日 期：审 核：日 期：审 核：日 期：批 准：日 期：华 为 技 术 有 限 公 司版权所有 侵权必究修订记录日期修订版本描述作者2009-09-011.0初稿完成LiuXin1/29/2020华为机密，未经许可不得扩散第2页, 共32页目 录第1章 SIP协议的基本概念及其在网络中的位置61.1 什么是SIP61.2 SIP在网络中的位置61.3 SIP协议的典型应用71.4 SIP协议的主要网络实体7第2章 SIP的主要消息92.1 概述92.2 SIP消息类型92.2.1 请求消息92.2.2 请求消息样例102.2.3 响应消息112.2.4 响应消息样例14第3章 SIP的分层结构143.1 事务层153.2 事务子层16第4章 MSOFTX3000的SIP的常用流程174.1 基本移动始发SIP-I出局呼叫流程174.2 基本SIP-I入局移动终结呼叫流程184.3 发生SIP局间切换流程194.4 发生SIP局间后续切换流程204.5 移动始发呼叫TS61传真流程214.6 移动始发呼叫TS62传真流程224.7 移动终结TS61传真流程234.8 移动终结TS62传真流程24第5章 MSOFTX3000的SIP的常见案例255.1 SIP出入局编解码打包时长不一致导致单通255.1.1 问题现象255.1.2 原因分析255.1.3 处理过程265.2 带外DTMF方式导致SIP呼叫失败265.2.1 问题现象265.2.2 原因分析275.2.3 处理过程275.3 网关未配置相应的编解码导致SIP呼叫失败285.3.1 问题现象285.3.2 原因分析285.3.3 解决方案295.4 SIP的相关IP分域设置305.4.1 问题现象305.4.2 原因分析305.4.3 解决方案315.5 SIP不能发送*#等号码出局315.5.1 问题现象315.5.2 原因分析315.5.3 解决方案315.6 与西门子NGN通过SIP-I对接的两个配置问题315.6.1 问题现象315.6.2 原因分析315.6.3 解决方案321/29/2020华为机密，未经许可不得扩散第5页, 共32页关键词：摘 要：缩略语清单：参考资料清单：SIP协议专题-20050112-A.docWG000204 SIP-I Based Nc ISSUE1.0.pptWG000204 SIP协议基础 ISSUE1.0.ppt第1章 SIP协议的基本概念及其在网络中的位置1.1 什么是SIPSIP 是 Session Initialization Protocol （会话初始协议）的缩写；IETF制订的多媒体通信系统框架协议之一，它被用来创建、修改、和终结一个或多个参加者参加的会话进程。这些会话包括Internet多媒体会议、Internet电话、远程教育以及远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动，统称为多媒体会话。简单的呼叫流程和ISUP非常类似有关SIP的完整定义最早出现在 1999 年公布的RFC 2543 中；当前SIP详细定义于RFC 3261 (June 2002)1.2 SIP在网络中的位置在TCP/IP五层模型中属于应用层协议；在OSI七层模型中属于Session层协议SIP 单独不能完成多媒体呼叫，必须要与其他协议一起才能组建完整的多媒体通信系统，与RTP/RTCP、SDP、 MGCP 、DNS等协议配合共同完成多媒体会话过程.1.3 SIP协议的典型应用SIP协议的典型应用IP电话（VoIP）：Windows Messenger 4.6及之后版本都集成了对SIP的支持移动游戏，即时通信，视频与协调SIP扩展应用 3G WCDMA IMS，NGN Softswitch,WCDMA-CS,CDMA-CS，这些扩展应用的常见组网场景如下图：1.4 SIP协议的主要网络实体SIP 在网络中存在多种逻辑实体，不同实体作用互不相同，不同的逻辑实体可以存在于同一个物理实体之上l SIP Endpoints: 又称作用户助理（User Agent）分为User Agent Client (UAC)和User Agent Server （UAS）User Agent Client (UAC) 负责发起SIP请求; 举例SIP Phone就是UAC的一种实际形态。 User Agent Server （UAS）负责对接收到的请求产生响应（接收、拒绝、重定向）, 例SoftX3000就是UAS的一种实际形态l SIP Proxies: 作为一个逻辑网络实体代表客户端转发请求或者响应，可以同时作为客户端和服务器端。代理服务器有三种形态：Stateless、Statefull和Call Stateful，其可以采用分支、循环等方式向多个地址尝试转发请求。代理服务器的主要功能：路由、认证鉴权、计费监控、呼叫控制、业务提供等。在华为解决方案中，SoftX3000兼任代理服务器的角色l SIP RedirectServer:重定向服务器,将请求中的目的地址映射为零个或多个新的地址，然后返回给客户端，客户端直接再次向这些新的地址发起请求。重定向服务器并不接收或者拒绝呼叫，主要完成路由功能，与注册过程配合可以支持SIP终端的移动性。在华为解决方案中，SoftX3000兼任重定向服务器的角色l SIP Registrars: 注册员为接收注册请求的服务器，通常与Proxy或者Redirect Server共存。注册员需要将注册请求中的地址映射关系保存到数据库中，供后续的相关呼叫过程使用，同时可以提供定位服务。在华为解决方案中，SoftX3000兼任注册员的角色1/29/2020华为机密，未经许可不得扩散第32页, 共32页第2章 SIP的主要消息2.1 概述SIP消息是基于文本的协议（UTF-8 字符集），与E-mail 和 HTTP类似，便于跟踪和调试。SIP 消息 用于从Client到Server的请求和从Server到Client的响应SIP 消息的通用语法 Start-Line (Request-Line/Response-Line) *Message Header CRLF Message-Body2.2 SIP消息类型消息分为两类：请求和响应请求和响应在形式上的区别仅在消息的第一行, 请求的第一行为请求行，响应的第一行为状态行2.2.1 请求消息用于客户端为了激活按特定操作而发给服务器的SIP消息，包括INVITE， ACK，OPTIONS，BYE，CANCEL和REGISTER消息等，各消息功能如表2-1所示。表2-1 请求消息图2-2 请求消息图2-3 消息含义INVITE发起会话请求，邀请用户加入一个会话，会话描述含于消息体中。对于两方呼叫来说，主叫方在会话描述中指示其能够接受的媒体类型及其参数。被叫方必需在成功响应消息的消息体中指明其希望接受哪些媒体，还可以指示其行将发送的媒体。如果收到的是关于参加会议的邀请，被叫方可以根据Call-ID或者会话描述中的标识确定用户已经加入该会议，并返回成功响应消息。ACK证实已收到对于INVITE请求的最终响应。该消息仅和INVITE消息配套使用。BYE结束会话CANCEL取消尚未完成的请求，对于已完成的请求（即已收到最终响应的请求）则没有影响REGISTER注册OPTIONS查询服务器的能力2.2.2 请求消息样例图2-4 请求消息样例第一行：请求起始行。INVITE请求消息。请求URI， SIP版本号为2.0。SIP URL的一般结构为：SIP：用户名：口令主机：端口；传送参数；用户参数；方法参数；生存期参数；服务器地址参数？头部名头部值第二行：Via字段。该字段用于指示该请求历经的路径。“SIP/2.0/UDP”表示发送的协议，协议名为“SIP”，协议版本为2.0，传输层为UDP；Via头域中的Branch ID，SIP协议中的事务为Client和Server间一次请求和最终响应的交互第三行：Max-Forwards字段。表示该请求到达其目的地址所允许经过的中转站的最大值为70第五行：From字段。指明请求发起方的地址。标记TAG为用于共享同一SIP地址的不同用户用相同的Call-ID发起呼叫邀请时，对用户进行区分。第六行：To字段。指明请求接收方的地址。第七行：Call-ID字段。该字段唯一标识一个特定的邀请，全局唯一。第八行：Cseq字段。用于将INVITE请求和其触发的响应、对应的ACK、CANCEL请求相关联。第九行：Contact字段。指示其后的请求（如BYE请求）可以直接发往Contact后面地址，而不必借助Via字段。第十行：Content-Type字段，表示消息中携带的消息体是单消息体且为SDP。第十一行：空行，表示下面为SDP会话描述。第十二行：SDP协议版本号，目前为0版本。第十三行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户主机地址）以及会话标识和会话版本号第十四行：会话名。每个会话描述必需有一个且只有一个会话名第十五行：连接数据。一般为SoftX3000（IP地址：16）控制下的UMG的IP地址或SIP、H.323终端的IP地址第十六行：时间描述， “0”表示起始时间。NTP十进制表示，单位为秒。第十七行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为音频。“RTP/AVP”为传送层协议，后面的数字是媒体静荷类型。第十八二十行：rtpmap属性行，指明从RTP静荷类型至编码的映射关系。2.2.3 响应消息用于对请求消息进行响应，指示呼叫的成功或失败状态。不同类的响应消息由状态码来区分。状态码包含三位整数，状态码的第一位用于定义响应类型，另外两位用于进一步对响应进行更加详细的说明。各响应消息分类和含义如表2-2所示。表2-2 响应消息图2-6 序号图2-7 状态码图2-8 消息功能1xx信息响应（呼叫进展响应）表示已经接收到请求消息，正在对其进行处理100试呼叫180振铃181呼叫正在前转182排队2xx成功响应表示请求已经被成功接受、处理200OK3xx重定向响应表示需要采取进一步动作，以完成该请求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服务器超时505SIP版本不支持513消息太长6xx全局故障表示请求不能在任何SIP服务器上实现600全忙603拒绝604都不存在606不接受2.2.4 响应消息样例具体的含义请参考请求消息章节第3章 SIP的分层结构此章节比较抽象，技术支持工程师可以不必详细钻研SIP协议是一个分层的协议，根据各层的功能不同，可分为如下层次，语法层，传输层，事务层，事务子层，语法层主要对消息进行编码，传输层SIP协议可以承载在底层UDP、 TCP和SCTP，目前MSOFT支持UDP和SCTP(R8C2),这两层此文不做详细介绍 ，主要介绍事务层，事务子层3.1 事务层SIP协议中的事务为Client和Server间一次请求和最终响应的交互(包括临时响应）SIP协议中的事务以Via头域中的Branch ID作为标识, 一个会话中可能存在多于一个的事务SIP协议中的事务可分为INVITE事务和非INVITE事务INVITE事务中包含三次握手过程INVITE事务的三次握手机制由INVITE、最终相应码、ACK组成（如下图所示）若请求返回成功，则ACK属于单独的事务如请求返回失败，则ACK属于INVITE事务的一部分，INVTE事务可以存在临时响应（1xx）非INVITE事务只有两次握手过程非INVITE事务的两次握手机制由请求消息和最终响应码组成（如下图所示）非INVITE事务不存在临时响应，UAS应该以最快速度返回响应一个正常的呼叫一般包含三个事务。其中，呼叫启动包含两个：邀请（Invite）和证实（ACK），前者需要回送响应，后者只是证实已收到最终响应，不需要回送响应。呼叫终结包含一个：再见（Bye）3.2 事务子层Dialog :(会话)一个端到端的呼叫的建立是由INVIE、200OK和ACK三条信令的交互而形成的通过1xx或2xx所确定的Call-ID 、Local Tag 、和Remote Tag可以确定通信的双方Via头域中的BranchID确定一个事务，而Call-ID 、Local Tag 、和Remote Tag确定一个会话，一个会话由一个INVITE事务发起，并且包含多个对话内事务Session:Session指主被叫之间的音频视频通信，处理信令层次的Dialog外，负责媒体信息的协商Session也有一个创建、修改、终结的过程Session只能由INVITE创建；INVTE事务在创建Dialog的同时，也创建了一个Session。Session修改是通过Re-INVITE/UPDATE消息中携带的SDP消息体来完成的Session的终结和Dialog的终结方法相同, BYE和CancelBYE建立通信后，通信中的任何一方都可以通过发送BYE请求来结束SessionCANCEL在呼叫还没正式建立之前，UAC可以通过发送Cancel请求来终止Session第4章 MSOFTX3000的SIP的常用流程4.1 基本移动始发SIP-I出局呼叫流程图4-1 基本移动始发SIP-I出局呼叫流程1.移动始发呼叫，MSC-S收到SETUP消息后先建立接入侧端点T1，然后建立网络侧端点T2，T2建立后MSC-S发送封装了IAM的INVITE消息出局。2.MSC-S收到携带SDP的可靠183消息后，通过MOD操作指示网关更新T2端点的承载信息。3.MSC-S收到被叫振铃的180消息后转换成ALERTING消息发给接入侧。4.MSC-S收到被叫应答的200消息后转换成CONNECT消息发给接入侧。5.通话接通后，主被叫进行正常通话。MGW之间的Nb口上直接传递RTP流。4.2 基本SIP-I入局移动终结呼叫流程图4-2 基本SIP-I入局移动终结呼叫流程1.MSC-S收到GMSC-S的INVITE消息后，先发送SETUP消息到接入侧，然后建立网络侧端点T2和接入侧端点T1。T2端点建立后发送携带SDP的183消息到GMSC-S。2.MSC-S收到接入侧的ALERTING消息，此时指示通过T2端点进行播放回铃音的操作。同时，将ALERTING消息转化为180消息发送到GMSC-S。3.MSC-S收到接入侧的CONNECT消息，此时指示T2端点停止播放回铃音的操作。同时，将CONNECT消息转化为200消息发送到GMSC-S。4.通话接通后，主被叫进行正常通话。MGW之间的Nb口上直接传递RTP流。4.3 发生SIP局间切换流程图4-3 发生SIP局间切换流程1. BSC向MSC-A发起切换请求，MSC-A判断是局间切换，需要通过E接口MAP信令通知MSC-B发起局间切换。MSC-B接收切换请求后，需要先指示网关新建立接入侧承载端点T4，然后向目的BSC B发起切换请求，BSC B回送响应后，MSC-B需要通过E接口MAP信令通知MSC-A正在处理切换接入请求。2.此后，MSC-A需要通过收到的切换号码选择SIP中继出局（使用INVITE消息发起新的呼叫），并指示网关新建出局侧承载端点T3，此时承载端点T2和T3单向连接，T1和T2双向连接。3.MSC-B收到MSC-A的切换入局呼叫，需要指示网关新建端点T5。然后MSC-B回送183,180消息完成基本SIP呼叫的接续。4.当MSC-A收到接续的180消息后，需要给接入侧BSC-A回送Handover Command。5.当BSC-B上报Handover Detect给MSC-B后，MSC-B需要通过E接口MAP信令MAP Process Access Signalling Req告知MSC-A开始接入无线信道。此时，MSC-A需要通知网关修改承载拓扑，使得承载端点T2和T3双向连接，T1和T2单向连接。6.当BSC-B上报Handover Complete给MSC-B后，MSC-B需要通过E接口MAP信令MAP Send End Signalling Req告知结束切换处理并发送200响应消息完成切换入局中继呼叫的建立。7.当MSC-A接收到MAP Send End Signalling Req需要指示网关释放T1承载端点，并向MSC-B发送ACK。4.4 发生SIP局间后续切换流程图4-4 发生SIP局间后续切换流程1.BSC-A向MSC-B发起切换请求，MSC-B判断是切回操作，需要通过E接口发送MAP Prepare Subsequent Handover Req给MSC-A。2.MSC-A判断切回操作，先指示网关建立接入侧承载端点T6, 此时承载端点T6和T2单向连接，T3和T2双向连接。然后需要向切回的接入侧BSC-B发送Handover Request。3.BSC-B回应Handover Request Ack后,MSC-A需要通过E接口发送MAP Prepare Subsequent Handover Resp给MSC-B。4.MSC-B收到MAP Prepare Subsequent Handover Resp后，需要向接入侧BSC-A发送Handover Command指示。5.MSC-A收到BSC-B上报的Handover Detect，需要通知网关修改承载拓扑，使得承载端点T6和T2双向连接，T3和T2单向连接。6.MSC-A收到BSC-B上报的Handover Complete后，MSC-A需要通过E接口MAP信令MAP Send End Signalling Resp告知MSC-B已经切回。7.此后，MSC-B需要指示网关释放T4承载端点资源。同时，需要MSC-A发起释放局间创建的SIP中继呼叫包括指示网关释放T3,T5端点Notes：局间后续切换回第三方MSC可以包括两部分处理，先切回，再由MSC-A发起新的切换请求到第三方。因此，局间后续切换回第三方处理可参见上述章节描述4.5 移动始发呼叫TS61传真流程图4-5 移动呼叫始发TS61流程1.移动用户发起的语音呼叫建立成功后，移动用户通过MODIFY发起TS61传真，携带数据业务BC。2.MSC判断为数据业务，则通过re-INVITE消息发起TS61传真流程，可以携带2198冗余、clearmode、G.711a、G.711u等编解码（具体携带视网关的支持情况），如果携带G.711a、G.711u，则需要在SDP中携带“a=fax”、“a=modem”属性行。3.MSC收到后向局的200 OK后，根据SDP中的编解码发起承载修改，并向BSC回modify complete。随后重新向BSC发起指配，修改接入侧承载。4.6 移动始发呼叫TS62传真流程图4-6 移动呼叫始发TS62流程1.移动用户发setup消息给MSC，携带数据业务BC。MSC查询用户是否签约TS62，如果签约则需要建立接入侧承载，承载建立完成后向BSC发起指配。2.MSC收到接入侧的指配完成指示后，建立网络侧端点T2，并通过INVITE消息发起TS62传真流程，可以携带2198冗余、clearmode、G.711a、G.711u等编解码（具体携带视网关的支持情况），如果携带G.711a、G.711u，则需要在SDP中携带“a=fax”、“a=modem”属性行，并在SIP-I中携带TMR/USI指示为数据业务。3.MSC收到后向局的183消息后，根据SDP中的编解码发起承载修改。4.7 移动终结TS61传真流程图4-7 移动终结TS61流程1.移动终结语音呼叫建立成功后，MSC收到re-INVITE，携带SDP，SDP为2198冗余、clearmode、G.711a、G.711u传真（对于G.711a、G.711u传真，则需要在SDP中携带“a=fax”、“a=modem”属性行）；2.MSC判断为TS61传真业务，等待移动用户的modify消息发起TS61传真业务；3.移动用户通过MODIFY发起TS61传真，携带数据业务BC。4.MSC判断为数据业务，修改接入侧承载T1，然后修改网络侧端点T2，接入侧承载修改完成后向BSC发起重新指配请求，然后向对局回200 OK。4.8 移动终结TS62传真流程图4-8 移动终结TS62流程1.移动终结语音呼叫建立成功后，MSC收到re-INVITE，携带SDP，SDP为2198冗余、clearmode、G.711a、G.711u传真（对于G.711a、G.711u传真，则需要在SDP中携带“a=fax”、“a=modem”属性行）；2.MSC判断为TS61传真业务，等待移动用户的modify消息发起TS61传真业务；3.移动用户通过MODIFY发起TS61传真，携带数据业务BC。4.MSC判断为数据业务，修改接入侧承载T1，然后修改网络侧端点T2，接入侧承载修改完成后向BSC发起重新指配请求，然后向对局回200 OK。第5章 MSOFTX3000的SIP的常见案例5.1 SIP出入局编解码打包时长不一致导致单通5.1.1 问题现象一个呼叫通过NGN到MSC，再从MSC到NGN之间都走SIP协议，呼叫出现单通现象（被叫听不到主叫，主叫可以听到被叫）。NGN为国际关口局，NGN和MSC通过SIP中继对接，NGN和MSC都是我司产品。对MSC来说此呼叫出入局为同一局向（NGN）5.1.2 原因分析分析SIP入局收到的INVITE消息，发现SDP的G711A没有携带打包时长，默认是20ms。再看MSC向MGW下发的ADDREQUEST以及MGW返回的ADDREEPLY消息，发现选择的编解码为G711A，打包时长为20ms，经过分析，入局选择的编解打包时长是从对局消息中得到的。此时MGC给MGW下发的ADDREQUEST如下图所示：(20ms)分析SIP出局发出的INVITE消息，发现SDP的G711A携带了打包时长并为5ms，此时MSC向MGW下发的ADD REQUEST以及MGW返回的ADD REEPLY消息选择的编解码为G711A，打包时长为5ms。经过分析，出局选择的编解码打包时长是从局向配置的编解码的打包时长得到的（ADD CODECCFG）。此时MGC给MGW下发的ADD REQUEST如下图所示：(5ms)对MSC来说，此SIP汇接呼叫出局和入局选择是同一种编解码G711A，但是打包时长不一致，入局是默认的20ms，出局是局向上配置的5ms。经过MGW确认，此时MGW不支持出入局为同一个局向时出入局选择了同一种编码但是编码打包时长不一致的情况。5.1.3 处理过程建议NGN将G711A编解码的打包时长改为5ms。 如果NGN不能修改，那么再通过MOD CODECCFG命令将MSC此局向上的G711A编解码的打包时长改为20ms。5.2 带外DTMF方式导致SIP呼叫失败5.2.1 问题现象TMF 呼叫失败，connect完成以后，MSC发Start_DTMF_Reject，原理值cause-value:interworking-unspecified1。内部消息里有失败原因statusCode:sip-ie-status-code-405-method-not-allowed (405)5.2.2 原因分析查看消息跟踪发现局间DTMF传递方式为带外DTMF且失败原因为：statusCode:sip-ie-status-code-405-method-not-allowed (405)。分析此原因值可知：对于SIP中继的带外DTMF，3000采用INFO消息进行传递 但是从对局发过来INVITE消息可以看到，对局是不支持INFO消息的 因此会导致DTMF失败。而使用INFO消息传送DTMF是华为的私有协议，我们与友商设备对接时，一般设置为带内DTMF。建议改带外DTMF为带内DTMF5.2.3 处理过程使用MOD SIPTG修改带外DTMF为带内DTMF5.3 网关未配置相应的编解码导致SIP呼叫失败5.3.1 问题现象从SIP局向过来的呼叫不能成功，我们用500拆线，原因值是network out of order, ADD_reply里面的是remote codec unsupported codec=6, Package time=205.3.2 原因分析观察SIPSL下发的PB消息可以看到，PB消息中包括了G729编解码。但是使用LST CODECCAP察看网关编解码能力集，并没有配置支持NGN(G729编解码能力包含于NGN选项中)，因此在PB的时候，网关上报不支持编解码。5.3.3 解决方案在网关上使用SET CODECCAP命令，把NGN选上。5.4 SIP的相关IP分域设置5.4.1 问题现象客户要求如下组网，即IP1.1和IP1.2互通，IP2.1和IP2.2互通。如下图：这样能否实现？是不是通过设置两个域，将IP分到两个平面，这时MSX能否支持？怎么设置？会不会出现这样的情况：MSS KHBR分配了IP1.1，MSS BRN分配了IP2.2从而导致呼叫不通？ADD OFC里面就有IP domain，而ADD GWADDR有domain，是否通过这两个参数就可以把域关联起来了？这样的话在OFC表加两个局向，GWADDR表就加上两个IP，可以视为两个域了？然后在ADD SRT把两个局向配个负荷分担是否就满足需求了？5.4.2 原因分析MSC支持对UMG上设置不同的IP域，MSC需要在