SIP请求和响应

sip请求

基本类:INVITE,ACK,BYE,CANCEL,REGISTER,OPTIONS
扩展类:INFO,MESSAGE,SUBSCRIBE,NOTIFY,UPDATE,REFER,PUBLISH,PRACK
(RFC3261)

请求主要用途
INVITE会话建立和会话属性的修改
ACK对INVITE的最终响应的确认
BYE会话释放
CANCEL取消尚未完成的请求(被叫摘机前,也就是通话接通)
REGISTER注册
OPTIONS查询服务器能力
请求主要用途
INFO传递额外的消息请求,如放音提示、二次收号、会议相关控制信息
MESSAGE发送短消息
SUBSCRIBE发送订阅请求,一般和NOTIFY联用
NOTIFY发送订阅通知,内容使用xml格式编码
UPDATE发起更新请求,一般用于SDP更新
REFER只是请求来自第三方,发送者指引接收者访问请求中标识的资源
PUBLISH发布网元状态信息,消息体采用xml格式编码
PRACK确认100Tring除外的所有临时响应,表示收到临时响应

分析

头域作用
Request-URI消息的目的URI
Record-Route经过的网元把自己的地址写进该头域,方便后续的消息转发
Route下一跳强制转发的地址,优先级最高
Via经过的网元地址,方便后续的消息进行转发
Contact节点的联络地址
PathP-CSCF的地址,方便被叫侧的S跳过I,直接找P

类型

INVITE

用于会话的建立和修改

  • 初始INVITE:会话建立时,主叫发送的第一条消息,请求行的Request-URI通常使用被叫的Tel-URI,并携带主叫的SDP信息(媒体信息)。接收端(不一定是被叫,指收到sip消息的对端)收到INVITE消息后必须返回100(trying)临时响应,标识接收端正在进行处理。
  • Re-INVITE:会话进行中用于修改会话属性。(接通后)
    区别:初始INVITE没有带to-tag(被叫接收到INVITE后在返回消息中添加),而Re-INVITE有to-tag

OPTIONS

用于查询UA或服务器的能力及发现其可用性,并不用于创建会话。成功类响应可以包含Allow,Accept,Accept-Encoding,Accept-Language和Supported头域,说明能力集

SUBSCRIBE

用于订阅状态事件。Event标识关键参数,取值为reg标识注册事件,取值为presence标识呈现状态的订阅。Expires取值不为0表示订阅时长,0表示取消订阅

MESSAGE

针对IMS的短消息业务。在即时消息中,User-Agent头域取值为im。成功响应包括200和202。如果时最终接收者,返回200;如果时存储转发服务器,返回202(Accepted)

REFER

请求另一个UA访问URI或URL资源。内容由Refer-To头域指定,且为必须,格式一般为URI或URL(sip,sips,http,pres。ps:如果为sip或sips,可以实现呼叫转移服务)。

SIP响应

状态码含义

1XX临时响应, 表示请求消息正在被处理。
2XX成功响应, 表示请求已被成功接收。
3XX重定向响应, 表示需采取进一步以完成该请求。
4XX客户端错误。
5XX服务器端错误。
6XX全局故障。

类型

1XX

响应码含义作用
100Trying表示已经收到了请求,正在处理
180Ringing表示被叫侧振铃
181Call is Being Forwarded表示被叫侧启用了呼转业务,正在转接
182Queued被叫暂时不能接听呼叫,服务器决定将呼叫排队等候。当被叫恢复接收呼叫,则会返回合适的最终响应
183Session Progress用于提示会话建立的进度,并携带SDP进行媒体协商。VoLTE/VoNR呼叫流程中的183可用于触发专载(Qos流)建立

2XX

响应码含义作用
200OK表示请求已经处理成功和完毕
202Accepted表示请求已接受

3XX

响应码含义作用
300Multiple Choices请求的地址有多个选择,当服务器侧不能或不愿转发时可回复该状态码
301Moved Permanently根据Request-uri无法找到用户,改用Contact头域地址来寻址
302Moved Temporarily要求发送方的Request-uri使用Contact头域中的地址
305Use Proxy请求的资源必须通过Contact头域中的proxy来访问
380Alternative Service呼叫不成功,但可以尝试另外的服务。例如返回380触发CSFB

4XX

响应码含义作用
400Bad Request请求消息语法错误
401Unauthorized要求用户进行鉴权
403Forbidden服务端支持这个请求,但拒绝执行
404Not FoundRequest-uri的域找不到
405Method Not Allowed服务器支持Request-Line中的方法,但Request-URI中的地址不允许应用这个方法。应答必须包括一个Allow头域,这个头域包含了指定地址允许的方法列表。
406Not Acceptable内容无法接收的错误
407Proxy Authentication Required和401类似,但要求用户首先在Proxy进行鉴权
408Request Timeout请求超时
413Request Entity Too Large请求的实体超过了服务器希望或能够处理的大小
414Request-URI Too Large请求的request-uri超过了服务器能处理的长度
415Unsupported Media Type请求的媒体格式不支持
416Unsupported URI Scheme不支持的URI scheme
420Bad Extension请求中有不支持的扩展,响应消息应包含Unsupported头域列出不支持的扩展
421Extension Required服务器端要求提供特定的扩展来处理这个请求
422Session Interval Too Small会话间隔太小
423Interval Too Brief请求中设置的资源刷新时间过短
480Temporarily Unavailable临时不可达
481Call/Transaction Does Not Exist请求没有和现有的对话或事务匹配
482Loop Detected检测到环路
483Too Many Hops请求中Max-forwards头域值为0
484Address IncompleteRequest-uri不完整
485AmbiguousRequest-uri不明确
486Busy Here被叫忙
487Request Terminated表明INVITE请求被BYE或CANCEL终止
488Not Acceptable HereSDP媒体类型或编码检查失败
489Bad Event订阅流程中订阅的错误的事件,即无法识别订阅请求中event头域的取值
491Request Pending同一对话中,接收到的请求有一个依赖的请求正在处理
493Undecipherable请求中包含了加密的MIME,无法解密

5XX

响应码含义作用
500Server Internal Error服务器内部错误,不能继续处理请求
501Not Implemented服务器没有实现相关的功能
502Bad Gateway错误的网关
503Service Unavailable由于服务器过载或其他原因导致服务器不可用
504Server Time-out服务器端超时
505Version Not Supported不支持的SIP版本
513Message Too Large请求消息长度超过了服务器的处理能力

6XX

响应码含义作用
600Busy Everywhere成功到达被叫,但被叫忙,不打算接听电话。如果被叫不希望提供拒绝的原因,可使用603。通常只有被叫知道没有其他方式(例如转语音邮箱)能够访问它时才使用600,否则该用486
603Decline成功到达被叫,但被叫明确不想应答,且不希望提示拒绝的原因
604Does Not Exist Anywhere经验证Request
606Not Acceptable成功找到被叫,但SDP中的一些信息如请求的媒体、地址类型等对端不接受。

Record-Route、Route、Via、Contact、Path使用场景

  • Record-Route和Route:Route是优先级最高的路由方式。有route,下一跳的地址必须为route指示的地址。Record-Route从名字可以看出是记录的route地址,在响应中完整返回给请求方。在下次请求或响应(对象都是上次的被请求方)时,会将Record-Route顺序翻转作为Route(不是所有的经过的网元都会将自己写入Record-Route,像被叫侧的I-CSCF完成的功能为找到被叫侧的S-CSCF的地址,那么在后续的环节中I-CSCF希望自己被忽略,就不会把自己写入Record-Route)
  • Path:必须经过的代理信息,一般为P-CSCF的地址。用于呼叫过程中,被叫侧的S-CSCF通过该头域的地址,将后续的消息跳过被叫侧的I-CSCF,直接发送给P-CSCF
  • Contact :标明直接联系请求发送方或响应应答方的URI地址,方便之后的消息能正确路由。URI地址后可能会携带上UE的能力信息
  • Via:每经过一个网元,该网元将自己的地址+branch,以via头域添加进消息中,成为最顶上(所有via中最上面的位置)的via。消息的响应根据via来路由。最顶上的via是下一跳的地址,抵达该地址后,会自动抹除掉最顶上的via。(感觉有点类似堆栈)branch是请求过程中由网元随机生成的。因此每一次请求经过的网元可以相同,但via的branch绝对不会一模一样。同一个请求的响应的via是一模一样的

SIP的松散路由和严格路由

  • 针对Request-URI和Route Header的路由,可以分为松散和严格路由。如果携带“lr“,可以视为松散路由,否则为严格路由。
  • 严格路由要求每一跳的节点必须根据Route重写Request-URI。松散则不要求改变
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值