zoukankan      html  css  js  c++  java
  • SIP协议参数详情

    SIP消息结构

    请求消息和响应消息都包括SIP消息头字段和SIP消息体字段;

    SIP消息头主要用来指明本消息是有由谁发起和由谁接受,经过多少跳转等基本信息;

    SIP消息体主要用来描述本次会话具体实现方式;

    请求消息格式

    SIP请求消息的格式,由SIP消息头和一组参数行组成

    消息体定义:
      Call-ID:头字段是用来将消息分组的唯一性标识
      From:头字段是指示请求发起方的逻辑标识,它可能是用户的注册地址。From头字段包含一个URI和一个可选的显示名称
      CSeq:头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成,请求方法必须与对应的请求消息类型一致
      Max-Fowords:头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值,每经过一跳,这个值就被减一。如果在请求消息到达目的地之前该值变为零,那么请求将被拒绝并返回一个483(跳数过多)错误响应消息。
      Via:头字段定义SIP事务的下层(传输层)传输协议,并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后,才能在请求消息中加入Via头字段值。
      expires:参数指出了该值中包含的URI地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数,那么URI地址的有效期由Expires头字段值来确定。

    SIP请求消息实例:

    INVITE sip:0109@127.0.0.1:5060;User=phone SIP/2.0
    Call-ID:01E04633512400000@127.0.0.1
    Via:SIP/2.0/UDP 127.0.0.1:5061
    From:<sip:010203@127.0.0.1:5061;User=phone>;tag=29005358336B534F610A000
    To:<sip:0109@127.0.0.1:5060;User=phone>
    Contact: sip:010203@127.0.0.1:5061
    CSeq:1 INVITE
    Max-Forwards:70
    Content-Type: application/SDP
    Content-Length:168
    
    v=0
    o=UserA 2890844526 2890844526 IN IP4 here.com
    s=Session SDP
    c=IN IP4 192.0.0.1
    t=0 0
    m=audio 49172 RTP/AVP 0 8
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=sendonly

    INVITE消息是其中一种SIP请求消息。
    第一行由消息头和对端SIP实体的URI(通用资源标识)以及SIP版本号码组成。
    SIP URI是电话URI,附在IP地址上,表示对端和端点收发SIP消息的端口的域。
    “From”、“To”和“Contact”这三个SIP消息头属于电话URI。
    当背靠背用户代理发出呼叫时,“From”消息头中的URI填写在“Via”消息头里。
    请求消息类型填写在CSeq消息头里,并且当该SIP端点发送一个请求,号码就相应递增。
    SIP协议版本为SIP/2.0。其中SDP被加入到INVITE消息内容里,在消息头里的Content-Length说明了SDP内容的长度。

    INVITE请求消息详解:

    INVITE sip:marconi@radio.org SIP/2.0

       请求方法、请求地址(Request-URI)、SIP版本号(目前都是SIP/2.0)
      请求地址一般就是被叫方地址,跟MSN中好友eMail地址类似

    Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b

      SIP版本号(2.0)、传输类型(UDP)、呼叫地址、
      branch是一随机码,它被看作传输标识
      Via字段中地址是消息发送方或代理转发方设备地址,一般由主机地址和端口号组成
      传输类型可以为UDP、TCP、TLS、SCTP

    Max-Forwards: 70

      最大跳跃数,就是经过SIP服务器的跳跃次数,主要是防止循环跳跃
      每经过代理服务器,该整数减一

    To: G. Marconi <sip:Marconi@radio.org>
    From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

      表示请求消息的发送方和目标方
      如果里面有用户名标签,地址要求用尖括号包起来
      对于INVITE消息,可以在From字段中包含tag,它也是个随机码

    Call-ID:123456789@lab.high-voltage.org

      呼叫ID是由本地设备生成的,全局唯一值。每次呼叫该值唯一不变
      对于用户代理发送INVITE消息,本地将生成From tag和Call-ID全局唯一码,被叫方代理则生成To tag全局唯一码。这三个随机码做为整个对话中对话标识(dialog indentifier)在通话双方使用。

    CSeq: 1 INVITE

      CSeq,又叫命令队列(Command Seqence),每发送一个新的请求,该数自动加1
      * 以上几个字段是所有SIP消息体所必须的,其它头字段有些是可选的,有些在特定请求也是必须

    Subject: About That Power Outage...
    Contact: <sip:n.tesla@lab.high-voltage.org>

      Contact是INVITE消息所必须的,它用来路由到被叫设备地址,也称为用户代理(UA)

    Content-Type: application/sdp
    Content-Length: 158

      最后两位附属字段说明消息体类型以及字段长度

    v=0   

      SDP版本号,目前都是0

    o=Tesla 28908445262890844526 INIP4 lab.high-voltage.org   

      主叫源地址,类型等
    s=Phone Call

    响应消息结构

    SIP响应消息实例:

    SIP/2.0 200 OK
    Content-Type:application/SDP
    Via:SIP/2.0/UDP 127.0.0.1:5061
    Call-ID:01EF351F8140000000000@127.0.0.1
    CSeq:1 INVITE
    From:<sip:010203@127.0.0.1:5061;User=phone>;tag=29005358336B534F610A000
    To:<sip:0109@127.0.0.1:5060;User=phone>;tag=5358336B534F2900CD1B0000
    Contact:<sip:0109@127.0.0.1:55061>
    Content-Length:156
    
    v=0
    o=HuaweiSoftX3000 1073741824 1073741824 IN IP4 127.0.0.1
    s=Sip Call
    c=IN IP4 110.111.112.113
    t=0 0
    m=audio 5060 RTP/AVP 0
    a=rtpmap:0 PCMU/8000

    200 OK消息是SIP响应消息的一种。
    第一行由SIP版本号和200响应消息组成。
    SIP URI是电话URI,附在IP地址上,表示对端和端点收发SIP消息的端口的域。
    “From”、“To”和“Contact”这三个SIP消息头属于电话URI。
    当背靠背用户代理发出呼叫时,“From”消息头中的URI填写在“Via”消息头里。
    请求消息类型填写在CSeq消息头里,并且当该SIP端点发送一个请求,号码就相应递增。
    SIP协议版本为SIP/2.0。把SDP加入到INVITE消息内容里,在消息头里说明内容的长度。

  • 相关阅读:
    CentOS 7下启动postfix服务报错:fatal: parameter inet_interfaces: no local interface found for ::1
    CentOS 7设置ulimit不生效的问题解决
    GitLab目录迁移方法
    GitLab查询当前版本
    CentOS 7安装Gitlab时报错:undefined method `downcase' for nil:NilClass
    .NET Core的依赖注入[1]: 控制反转
    .NET Core跨平台的奥秘[下篇]:全新的布局
    .NET Core跨平台的奥秘[中篇]:复用之殇
    .NET Core跨平台的奥秘[上篇]:历史的枷锁
    .NET Core多平台开发体验[4]: Docker
  • 原文地址:https://www.cnblogs.com/ljygirl/p/14330232.html
Copyright © 2011-2022 走看看