SIP协议培训教材.ppt

2020 2 15 RFC2543 SIP协议 2002年8月 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 SIP概要 1 定义 SIP SessionInitiationProtocol 是一种用来建立 更新和终止多媒体会话或呼叫的应用层控制协议 可用来初始化会话 然后邀请成员加入这些已建立和广播的会话 SIP明确地支持名字映射和重定向服务 支持ISDN操作和智能网电话 IntelligentNetworktelephony 用户服务 2 SIP支持五种建立和终止多媒体通信的方式 Userlocation 决定通信的终端 Usercapabilities 决定使用的媒体和媒体参数 Useravailability 决定被叫方加入通信的意愿 willingness Callsetup ringing 在被叫方和呼叫方建立呼叫参数 Callhandling 包括传输和中断呼叫 3 名词解释 2020 2 15 SIP概要 SIPSERVER 不同类型的SIPserver的特征总结 propertyredirectserverproxyserveruseragentserverregistrar alsoactsasaSIPclientnoyesnonoreturns1xxstatusyesyesyesyesreturns2xxstatusnoyesyesyesreturns3xxstatusyesyesyesyesreturns4xxstatusyesyesyesyesreturns5xxstatusyesyesyesyesreturns6xxstatusnoyesyesyesinsertsViaheadernoyesnonoacceptsACKyesyesyesno 2020 2 15 SIP基本功能和操作 主叫方和被叫方由SIP地址标定 当进行一个SIP呼叫时 主叫方首先定位合适的server 然后发送一个SIP请求 最普通的SIP操作是邀请invitation SIP请求不是直接到达被叫方 而是可以被重定向或者可以在proxy引发一系列新的SIP请求 users可以在SIPservers注册它们的位置 2020 2 15 SIPAddressing SIP地址所标记的是主机上的使用者 SIPURL的格式类似与telnetURL 例如 user host user部分是一个用户名或一个电话号码 host部分要么是个域名 要么是个数字形式的网络地址 被叫方在REGISTER时将自己绑定到这个地址上 呼叫方使用SIP地址与被叫方建立实时通信 SIP地址必须包括主机名 可以包括用户名 端口号和参数等 采用与mailto http 等类似的格式 是为了扩展在网页 邮件等的应用 2020 2 15 LocatingaSIPServer 一个client希望发送请求时 它要么发送请求到一个本地配置好的与Request URI无关SIPproxyserver上 要么将请求发送到Request URI中定义的IP地址和端口上 对于后一种情况 client必须决定协议和将请求发送到哪个端口和IP地址 Client可以通过DNS来查找server 除非另外标明 否则client都应该按照Request URI中列出的端口号来访问server 如果没有提供端口号 则使用默认值5060 如果Request URI指明了协议 TCP或者UDP client就使用指定的协议 如果没有提供协议 则使用UDP 如果失败 或者client不支持UDP 则使用TCP Client应该能够解析明确的网络提示 例如ICMP消息 而不是只能依赖超时信息 例如 如果client发现server不可到达 它应该按照接到请求返回400类的错误来处理 2020 2 15 SIPTransaction 一旦SIPserver能够确定 client就可以向其发送SIP请求或收到响应 一个请求 包括重发的请求 和相关的响应合起来称做一个SIP事务 对于一个请求的所有响应都包含相同的Call ID CSeq To 和From头域的值 但可能在to头域中添加了tag参数 这种机制可以区分出不同的事务 接在INVITE请求后的ACK请求不包括在同一个事务中 因为ACK在传送时可能会经过不同的路径 如果使用TCP协议 同一个事务的请求和响应会在同一个TCP连接中被传送 同一个client发给同一个server的不同SIP请求可以使用同一个TCP连接 也可以使用新的TCP连接 SIP消息体的格式和操作与传输协议无关 2020 2 15 SIPInvitation 一个成功的SIP邀请 INVITATION 包括两个请求 INVITE请求和其后的ACK请求 INVITE请求被叫者加入到一个指定的会议中或建立双方通话 被叫方同意加入呼叫后 主叫方发送ACK确认它收到了对方的同意信息 如果主叫方不再希望加入通话 就会不发送ACK 而是发送BYE 一个典型的INVITE请求包含了一个会话描述 sessiondescription 给被叫者提供了加入会话的足够的信息 对于多方通话来说 SD列举了媒体的类型和格式和媒体数据的返回地址 如果被叫方希望加入会话 它就会返回一个包含了同样SD的响应 在多方会话中 被叫者应该只返回一个SD如果它不能接受呼叫者提出的媒体类型或者它希望加入单方呼叫 2020 2 15 图1 Figure1 ExampleofSIPproxyserver 2020 2 15 图2 Figure2 ExampleofSIPredirectserver 2020 2 15 LocatingaUser 被叫者可能会有几个不同的终端号码 这些不同的定位可以动态地向SIPserver注册 一个locationserver也可以使用一个或多个协议算法来决定可能会在哪个终端找到被叫用户 因为用户可能同时注册了多个主机信息或者locationserver没有准确的信息 在这些情况下 locationserver可以返回多个定位 对于多个定位的处理方式 SIPredirectserver 返回给client一个Contact头域 包含了定位的列表 SIPproxyserver 连续地或并发地向这些地址发送请求 直到返回了一个2xx响应 表示呼叫成功 或者一个6xx响应 表示被叫者拒绝 如果一个proxyserver向前传递SIP请求 它必须将它自己的地址加入到via头域的最上方 via头域保证了响应能够沿相同的路径返回呼叫方 从而保证了呼叫能够穿透防火墙 并避免了请求环路 在响应回来的路上 每一个主机都必须从via头域中删除自己的地址 一个SIP呼叫请求可能会经过多个SIPproxy 如果一个proxy向多个定位发送了请求 那么UA可能会接到多个相同Call ID的请求 那么UA必须返回相同状态码的响应 2020 2 15 ChanginganExistingSession 在某些环境中 可能会需要改变已存在的会话的参数 这就需要在再次发送相同的Call ID 单消息体不同或头域不同的INVITE过程中实现 这个重发的INVITE必须有更高的序列号 例如 双方已经在通话 然后希望加入第三方 转换成多方通话 那么已经在通话的一方用新的多播地址邀请第三方 并且同时要用新的多播SD和旧的Call ID向第二方重新发INVITE消息 2020 2 15 RegistrationServices REGISTER请求允许client让proxy或redirectserver知道用什么地址可以找到它 在注册时 client就将自己的SIP地址和自己的IP地址绑定到一起 2020 2 15 SIP协议特点 最小限度的状态保存一个会议会话或呼叫会涉及到一个或多个SIP请求 响应事务 Proxyservers不需要为呼叫保存状态 然而 它们可以保存SIP事务的状态 为了提高效率 server可以保存locationserver请求的结果 底层协议不限定Lower Layer ProtocolNeutralSIP对其下面的传输层和网络层协议只做了最小限度的假定 底层可以提供数据包或者字节流 可靠服务或不可靠服务 在网络传输中 SIP可以用UDP和TCP传输协议 使用UDP的应用程序可以更精确地控制信息和重传定时 可以提供并行的搜索 而不需要使用每一个传出的请求的TCP连接状态 可以使用多播 而TCP使得信息可以更方便地穿透防火墙 当使用TCP时 SIP可以使用一个或多个连接来访问用户或更新现存会议的参数 同一个SIP呼叫的不同SIP请求可以根据需要使用不同的TCP连接或使用一个持久的连接 SIP也可以直接使用ATMAAL5 IPX framerelay或X 25协议 UA应该SHOULD可以使用UDP和TCP传输 而Proxy registrar 和redirectservers必须MUST使用UDP和TCP 基于文本SIP是基于文本的 全部使用ISO10646的UTF 8编码 这样就可以很容易地使用Java Tcl和Perl等语言 调试起来也很方便 而且更重要的是 增强了SIP的灵活性和可扩展性 由于SIP是用来初始化多媒体会议 而不是传输媒体数据的 因此一般认为在基于文本的协议上增加其他的开销是没有什么意义的 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 SIPURL 在SIP消息中SIPURLs可以指明SIP请求的发起者originator From 当前目的地址currentdestination Request URI 和最终接收者finalrecipient To 并且可以指定重定向地址redirectionaddresses Contact SIP URL sip userinfo hostporturl parameters headers userinfo user password user unreserved escaped digits 1 DIGIT 2020 2 15 SIPURL 续 telephone subscriber global phone number local phone numberglobal phone number 1 phonedigit isdn subaddress post dial local phone number 1 phonedigit dtmf digit pause character isdn subaddress post dial isdn subaddress isub 1 phonedigitpost dial postd 1 phonedigit dtmf digit pause character phonedigit DIGIT visual separatorvisual separator pause character one second pause wait for dial toneone second pause p wait for dial tone w dtmf digit A B C D SIPURL语法 telephonesubscriber下表总结了SIPURL的用处和默认值 defaultReq URIToFromContactexternaluser xxxxxpassword xxxxhostmandatoryxxxxxport5060 xxxxxuser paramipxxxxxmethodINVITExxmaddr param xxttl param1xxtransp param xxheaders xx 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 SIP消息概要 与HTTP不同的是 SIP可以使用UDP 当在TCP或UDP上进行传输时 多个SIP事务可以使用同一个TCP连接或UDP包 但是UDP包的长度 包括包头 不能超过最大传输单元 默认为1500字节 这个1500字节是为了适应典型的以太网MTU SIP消息要么是client到server的请求 要么是server到client的响应 SIP message Request Response不论是请求还是响应消息都使用generic message格式 RFC822 24 来传输消息体 两种类型的消息都包括一个start line 一个或多个头域 一行空行 carriage returnline feed CRLF 标志头域的结束 和可选的消息体 为了避免和HTTP相似名称的混淆 SIP使用entity头域来描述消息体 generic message start line message headerCRLF message body start line Request Line Status Linemessage header general header request header response header entity header 最前面的空行必须被忽略 换句话说 如果请求或响应消息开始于一个或多个CRLF CR 或者LFs 这些字符都必须被忽略 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 请求 Request Request Line general header request header entity header CRLF message body Request Line MethodSPRequest URISPSIP VersionCRLFMethod INVITE ACK OPTIONS BYE CANCEL REGISTER 其中INVITE和ACK用于建立呼叫 完成三次握手 或者用于建立以后改变会话属性 BYE用以结束会话 OPTIONS用于查询服务器能力 CANCEL用于取消已经发出但未最终结束的请求 REGISTER用于客户出向注册服务器注册用户位置等消息 Request URI指明了请求的目的地址 可能会被proxy改写 Proxy和redirectservers可以根据Request URI的信息和请求的头域来处理请求 并有可能会重写Request URI SIP Version SIP 2 0 2020 2 15 响应 Response Status Line general header response header entity header CRLF message body Status Line SIP versionSPStatus CodeSPReason PhraseCRLFStatus Code Informational 1xx Success 2xx Redirection 3xx Client Error 4xx Server Error 5xx Global Failure 6xx extension codeextension code 3DIGITReason Phrase 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 头域定义 参见SIP协议中的HEADER应用 PPT 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 状态码定义 与HTTP 1 1比较 与HTTP一致 是HTTP的扩展 但不包括所有的HTTP状态码 增加了x80响应码 定义了新类6xx 为每一个状态类都定义了默认值 x00 1xx Informational 收到请求 正在处理请求 2xx Success 行为已经成功地接收 理解和处理了 3xx Redirection 完成请求还需要更进一步的操作 4xx ClientError 请求包含了错误的语法或在这个server上不能完成 5xx ServerError server不能完成一个正确的请求 6xx GlobalFailure 任何server都不能完成这个请求 2020 2 15 状态码定义 1xx 1xx 报告信息信息类的响应指明联系的server或者proxy正在进行更深入的操作 还无法返回明确的应答 Client应该等待更进一步的响应 而server也应该在后续时间内主动返回明确的应答信息 如果server预计它需要花费200ms以上的时间来得到最终结果的话 那么它应该先返回1xx响应 server可以发送一条以上的1xx响应 而不必考虑其次序 而client收到此响应也不必回复ACK eerver可以自由地重传此类响应 而client也可以自由地重发请求 只是为了查询server当前执行的状态 100 Trying正在进行某个没有详细说明的动作 但是还没有定位用户 180 Ringing被叫UA 已注册 已经被定位 正在联系被叫UA 181 CallIsBeingForwardedproxy使用此状态码表示呼叫正在向前传递 182 Queued被叫方暂时不可用 但被叫方决定将呼叫放入队列而不是丢弃 一旦被叫方可用 就会返回最终结果 在返回此状态的响应时 还可以附加一些说明 例如 现在已经有5个队列在排队 大概需要等待15分钟 等等 server也可以发送多个182响应以更新状态报告 2020 2 15 状态码定义 2xx 2xx 请求已成功完成 必须终止搜索 200 ok返回此状态码响应对于不同的方法有不同的意义 BYE 呼叫终止 消息体为空 CANCEL 搜索取消 消息体为空 INVITE 被叫同意加入 消息体为被叫的能力特性 OPTIONS 被叫同意提供它的能力特性 这些特性在消息体中提供 REGISTER 注册成功 client根据Content Type处理消息体内容 2020 2 15 状态码定义 3xx 3xx 重定向报告用户的新位置 或者报告可以满足呼叫的可选服务 应该终止目前的搜索 如果需要的话可以让发起者开始新的搜索 任何一个3xx的响应都不能suggest请求中的via字段里的任何地址 为了避免循环 UAC或者proxy必须检查重定向服务器返回的地址是否被更改了 300 多重选择请求中的地址决定了会有几种选择 每种选择都有自己的定位 用户可以选择一个合适的终端通信并将请求重定向到那个定位 响应应该包括一个消息体 其中包含了资源特性列表 那些选择也应该列在contact头域中 SIP响应可以包含几个contact头域或者在一个contact头域中列出几个地址 301 MovedPermanently根据请求URI中列出的地址可能永远也找不到该用户 cilent端应该重试contact头域中列出的新地址 呼叫方应该更新本地的地址本和新的用户定位 302 MovedTemporarilyClient应该根据contact头域中的新地址重发请求 重定向的周期由expires头域指定 如果没有提供明确的时间 就表示这个地址只适用于本次呼叫 不能保存待用 305 UseProxyContact头域中给定的proxy必须可以用请求的资源 希望接收方通过proxy重复这个请求 305响应必须只能由UAS产生 380 AlternativeService呼叫不成功 但是有可选择的服务列在响应的消息体中 此类消息体还没有定义 2020 2 15 状态码定义 4xx 4xx RequestFailure请求失败4xx响应是从特定的server发来的明确的失败响应 Client不应该在修正之前再重试同一个请求 然而发给不同的server的同一个请求可能会成功 400 BadRequest由于错误的语法 请求不能被理解 401 Unauthorized请求需要用户认证 402 PaymentRequired保留以后使用403 ForbiddenServer理解了请求 但是拒绝完成 认证也无济于事 请求不应该再次发送 404 NotFound表示Server有确定的信息表明Request URI中的用户不存在 如果Request URI中指明的域和请求的接收者所在的域不匹配时也会产生这种错误状态 405 MethodNotAllowed在Request Line中列出的方法不被Request URI指明的对方所接受 响应必须包含一个allow头域 列出对指定的地址可用的方法 406 NotAcceptable请求指定的资源只能产生特殊的响应消息体 其中包含请求的accept头域指明的 但不支持的内容特性 407 ProxyAuthenticationRequired类似401 但是指明client必须先通过proxy认证自己 Proxy必须返回Proxy Authenticate头域 在此头域中指明可接受的认证的机制和参数 Client可以重复发送包含Proxy Authorization头域的请求 这个状态码用于通信通道的组件 例如电话网关 的应用程序 而不是需要认证的被叫方 2020 2 15 状态码定义 4xx 续 408 RequestTimeoutServer不能在expires中规定的时间内产生响应 例如用户定位操作 Client可以重复发请求 409 Conflict由于和资源的现状冲突 请求不能完成 如果REGISTER请求的参数和现存的冲突就会返回这种状态 410 GoneServer上需要的资源不再可用 而且不知道向前传递的地址 这种状况被看作是永久性的 如果server不知道 或者无法决定这种状况是否是永久性的 就应该返回404错误 411 LengthRequiredserver拒绝接受没有定义Content Length的请求 Client可以加上正确的Content Length头域再次发送请求 413 RequestEntityTooLargeServer拒绝处理请求 因为请求实体的长度超出server能够接受的程度 Server应该关闭连接 阻止client的后续请求 如果这种状况是临时的 server应该在返回的响应中包含Retry After头域指出关闭是暂时的 一段时间后client可以再试 414 Request URITooLongServer拒绝处理请求 因为Request URI太长 超出server能够解释的范围 415 UnsupportedMediaTypeServer拒绝处理请求 因为被请求的资源不支持请求的消息体的格式 Server应该返回Accept Accept Encoding和Accept Language头域 列出支持的格式 420 BadExtensionServer不理解Require头域中的协议扩展 480 TemporarilyUnavailable被叫终端已经成功联系上 但是被叫方目前不可用 例如 没有登录或者登录方式不能和呼叫方通信 响应可以指明一个更好的重试时间 user可能对于其它地方方式 例如语音邮件 来说是可用的 因此 这种响应不会终止任何搜索 这种理由应该给出更精确的被叫方不可到达的原因 其值可以由UA设置 486错误可以用于呼叫失败的更精确的理由 如果重定向server发现了Request URI指定的用户 但是目前没有可到达的向前传输的定位的话 也返回这种错误 2020 2 15 状态码定义 4xx 续 481 CallLeg TransactionDoesNotExist在两种情况下返回这种错误 server收到一个BYE请求 但此请求不匹配任何已存在的callleg 或者server收到CANCEL请求 但不匹配任何现存的事务 server简单地丢弃未知事务的ACK 482 LoopDetectedServer收到一个via头域中包含了自己地址的请求 483 TooManyHopsServer收到via入口 跳数 多与Max Forwards头域中规定的个数的请求 484 AddressIncompleteServer收到请求 其to地址或者Request URI中地址不完整 485 Ambiguous在请求中提供的被叫方地址不明确 响应可以在Contact中包括一系列可能的明确的地址 但是提供太多的选择可能会破坏用户或组织的私有关系 因此 如果请求地址不明确 必须配置server去响应404状态 或者禁止列出可能的选择 例如请求的URL为lee 则返回的响应是 485AmbiguousSIP 2 0Contact CarolLeeContact PingLeeContact LeeM Foote486 BusyHere被叫终端已成功联系上 但被叫方目前不愿或不能接受呼叫 响应可以指明更合适的再次呼叫时间 但不会中断任何搜索 如果client知道没有其它的终端可以接收这次呼叫的话 应该使用600状态 BusyEverywhere 2020 2 15 状态码定义 5xx 5xx ServerFailure5xxServer端发生不明确的错误 如果有其它未试过的定位 则不能中断搜索 500 ServerInternalErrorServer遇到了意外 阻止它完成请求 Client可以得到详细的错误状态 在几秒钟之后重试 501 NotImplementedServer不支持必须的功能来完成请求 当server不能识别请求的方法并且不支持方法时响应501 502 BadGatewayServer在充当网关或proxy时 由下一步的server收到不可用的响应 503 ServiceUnavailableServer目前不能处理请求 可能是因为暂时的拥塞等 这暗示着这只是临时的情况 经过一段延迟情况会有好转 如果能预测到延迟的时间 可以用Retry After头域通知对方 如果没有接到这种通知 client必须把此错误当500处理 注意 503状态的存在并不意味着当拥塞发生时 server必须要使用503 一些server可能希望简单地拒绝连接 504 GatewayTime out作为网关的server在限定时间内没有从locationserver收到需要的响应 505 VersionNotSupportedServer不支持或者拒绝支持请求消息中使用的SIP协议版本 响应应包含一个描述为什么不支持此版本和支持什么版本的消息体 格式未定 留以后扩展 2020 2 15 状态码定义 6xx 6xx GlobalFailures6xx响应表明server对client有了确定的信息 而不是Request URI中一个指定的地址而已 对这个client的更进一步的搜索注定都要失败 应该终止正在执行的搜索 600 BusyEverywhere已成功到达被叫方 但被叫方忙并且步愿意此时接受呼叫 响应可以指明一个更好的重试时间 如果被叫方不愿意说明拒绝的原因 可以反馈603响应 这种响应只用于client知道没有其它的终端 例如声音邮件 可以应答请求 否则 应该使用486响应 603 Decline被叫方已成功探测到 但是被叫方明确表示不愿意加入通话 响应可以指明更好的呼叫时间 604 DoesNotExistAnywhereServer有确定的信息表明被叫的用户不存在 向别的地方搜索该用户也不会有什么结果 606 NotAcceptableUA已经成功探测到 但是不支持会话的一些方面 例如需要的媒体 带宽或标记地址方式 606响应意味着用户希望通信但是不能充分支持会话描述 606响应可以在warning头域中包含一系列描述为什么不支持会话描述的原因 双方的沟通并不是频繁发生的 当一个新用户被邀请加入一个已存在的会议 双方沟通可能会不成功 这就需要邀请的发起人决定是否产生606响应 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 SIP消息体 1 消息体内容 请求可以包含消息体 在这个规范中 BYE请求不能包含消息体 ACK INVITE和OPTIONS中的消息体通常是会话描述 REGISTER请求的消息体使用还需要继续研究 对于响应消息来说 请求的方法和状态码决定了消息体的类型和含义 所有的响应都可以包含消息体 1xx响应的消息体包含了对请求的建议信息 对INVITE方法的2xx响应包含了会话描述 3xx响应的消息体可以包含可选目的地址或服务的描述 对于400和400以上响应的消息体可以包含附加的 可阅读的失败原因信息 建议1xx 300和更大值的响应为text plain或text html类型 2 消息体类型由Content Type头域定义 3 消息体长度由Content Length头域定义 2020 2 15 紧凑格式 紧凑模式当带着认证口令和复杂的会话描述的SIP信令在UDP上传输时 很可能请求或响应的长度超过了MTU 为了解决这个问题 对下列的头域采取了使用缩写的比较紧凑的格式 Clients可以在一个请求中同时使用紧凑格式和正常格式 server必须能接受请求的两种格式 proxy可以在两种格式中相互转换 但不能改变跟在认证后面的域 2020 2 15 目录 SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 2020 2 15 SIPClients和SIPServer 请求 Server对请求做出适当的响应之后 会抛弃以后再来的同样请求的复制品 因此 多个请求的copy并不会影响server的状态 在收到client发来的CANCEL请求后 有状态记录的proxy会向每一个还没得到最终结果的分支发送CANCEL 当一个UA收到请求时 会将Call ID取出来和正在处理的呼叫相比较 如果有相同的Call ID 就会进一步比较to头域中的tag参数 如果tag值不同 则表示是同一个SIP地址的两个用户发来的请求 UA就会丢弃后来的请求 如果请求的from头域 包括tag参数值 相同 server就会比较cseq值 如果和已存的序列号相同 则表示是重传的请求 否则表示是新的请求 如果新的请求和以前的请求的callleg不相同 则会新建一个callleg 处理新的呼叫 如果Call ID不相同 server就会返回一个与请求有相同to头域的响应 不过会在to头域后加上tag标签 但是如果响应只有一个via头域时 tag值会被忽略 响应 Server在发出最终的响应之前可能会给几个临时的响应 如果记录状态的proxy useragentserver redirectserver或者registrar不能在200ms内返回最终的结果 那么它应该尽快返回一个临时的1xx响应 但是不记录状态的proxy不能返回临时响应 返回的响应应该与请求有相同的To From Call ID Cseq头域值和第一个Via头域的branch参数 2020 2 15 UDP和TCP 单点传送UDP Unicast 响应是按照via头域中的地址传送的 而不是按照from头域中的地址传送 多点传送UDP Multicast 请求可以是多点传送的 多点传送的请求的Request URI可能会跟主机无关 Client收到一个多播的查询时 并不需要将Request URI的主机名部分和自己所在的域相比较 如果请求是通过多播发来的 那么响应也会用多点传送方式发送出去 收到多播请求后 server必须返回2xx和6xx响应 server不会处理经过多播传来的CANCEL请求 以免会漏掉其它的请求 而proxy和UAC在收到第一个2xx或6xx响应后 就应该向多播点传送CANCEL TCP 一个TCP连接可以传递一个或多个SIP事务 一个事务包括请求和一个 或多个 最终响应和零个 或多个 临时响应 Client在收到第一个最终响应之前都应该保持TCP通道的连接 如果短于这个时间 对端就会按照收到CANCEL请求来处理 而server在发送完它的最后一个响应之前都应该保持TCP通道的连接 之后就可以根据自己的需要决定TCP通道是否关闭 但是一般来讲 都是由client决定是否关闭TCP通道 2020 2 15 BYE CANCEL OPTIONS REGISTER请求的可靠性 UDP Client对于BYE CANCEL OPTIONS 或者REGISTER请求的重传时间是基于指数增长的 开始于T1秒间隔 以后每个包的间隔都乘2 直到间隔达到T2秒为止 这就是说 第一个包发送出去以后 等待T1秒发送第二个重传的包 然后下一个重传要等2 T1秒 再下一个要等4 T1秒 以此类推 直到时间间隔达到T2值 然后以后的重传都要等T2秒间隔 如果client收到临时响应 它还是要重传请求 不过每次都是等待T2秒 当client发了11个包以后 或者收到一个最终的响应 然后就会终止重传 默认的T1和T2值是500ms和4s Clients也可以使用一个更大的值 但是不能使用更小的值 server收到重传的请求以后也会重传响应 在server发送了最终的响应以后 不知道client是否收到响应 因此它会将最终结果至少保持10 T2秒 在proxy链上的每一个proxy都可以发出CANCEL请求 server收到第一个CANCEL时就会立即做出反应 而不是要等到最终的结果 TCP 使用TCP连接不需要重传机制 2020 2 15 INVETE请求的可靠性 1 在接到邀请请求后 server可能会花很多的时间 甚至几十秒来决定结果 server可能在忙 2 如果电话用户界面是模拟的或者需要接到PSTN 那么呼叫者这里就会有振铃音 一旦被叫方摘机 呼叫方就需要知道语音话路已经建立 振铃音停止 3 Client需要终止传递的请求 例如它不再需要等待连接或搜索成功的情况 server就必须等待几个重传间隔时间来确定是终止呼叫还是重传数据丢失 如果在呼叫方放弃呼叫的很短时间内呼叫就成功的话 被叫方仍会做出摘机的反应 TCPUA使用TCP时不能重传请求 但是在收到ACK之前重传响应的算法同UDP 2020 2 15 INVETE请求的可靠性 续 2020 2 15 ACK请求的可靠性和ICMP处理 ACK请求不会引起响应 ACK只是在INVITE请求的响应到达后产生的通知收到响应的请求 这是和传输协议无关的 注意ACK请求的传输路径可能会和INVITE请求的路径不同 也可能会导致打开一个新的TCP连接 ICMP处理 在使用UDP协议时可能会收到ICMP信息 对于请求来说 主机 网络 端口或协议不能到达的错误会按照400类响应处理 而对于响应 这些错误可能会引起server终止响应的重传 源不能到达 Sourcequench 的ICMP信息被忽略 TTL超时错误被忽略 参数错误被当做400类响应处理 2020 2 15 目录 SIP介绍SIPURLSI