rfc7118_SIP Over WebSockets
SIP协议错误代码大全
SIP协议错误代码大全1. 1xx系列 - 信息响应1. 100 Trying - 接收方正在处理请求，但没有给出最终响应。
2. 180 Ringing - 接收方正在振铃。
3. 183 Session Progress - 接收方已经在处理请求，并且期望发送一个最终响应。
2. 2xx系列 - 成功响应1.200OK-请求成功，客户端应该进行下一步操作。
2. 202 Accepted - 已经接受请求，但尚未完成处理。
3. 3xx系列 - 重定向响应1. 300 Multiple Choices - 请求的地址有多个选择，用户可以选择其中一个。
2. 301 Moved Permanently - 所请求的资源已经永久移动到新位置。
3. 302 Moved Temporarily - 所请求的资源已经临时移动到新位置。
4. 305 Use Proxy - 所请求的资源必须通过代理访问。
4. 4xx系列 - 客户端错误响应1. 400 Bad Request - 客户端请求有语法错误。
2. 401 Unauthorized - 需要用户身份验证。
3. 403 Forbidden - 服务器禁止访问所请求的资源。
4. 404 Not Found - 所请求的资源不存在。
5. 408 Request Timeout - 请求超时。
6. 415 Unsupported Media Type - 不支持的媒体类型。
5. 5xx系列 - 服务器错误响应1. 500 Server Internal Error - 服务器内部错误。
2. 501 Not Implemented - 服务器不支持实现请求的功能。
3. 502 Bad Gateway - 服务器作为网关或代理，从上游服务器接收到无效响应。
4. 503 Service Unavailable - 所请求的服务暂时不可用。
5. 504 Server Timeout - 服务器在等待上游服务器的响应时超时。
httpstaus汇总
httpstaus汇总常见HTTP状态码1.2.3.4.5.6.7.8.9.10.11.12.100 Continue初始的请求已经接受，客户应当继续发送请求的其余部分101 Switching Protocols服务器将遵从客户的请求转换到另外⼀种协议200 OK⼀切正常，对GET和POST请求的应答⽂档跟在后⾯201 Created服务器已经创建了⽂档，Location头给出了它的URL。
202 Accepted已经接受请求，但处理尚未完成。
203 Non-Authoritative Information⽂档已经正常地返回，但⼀些应答头可能不正确，因为使⽤的是⽂档的拷贝204 No Content没有新⽂档，浏览器应该继续显⽰原来的⽂档。
如果⽤户定期地刷新页⾯，⽽Servlet可以确定⽤户⽂档⾜够新，这个状态代码是很有⽤的205 Reset Content没有新的内容，但浏览器应该重置它所显⽰的内容。
⽤来强制浏览器清除表单输⼊内容206 Partial Content客户发送了⼀个带有Range头的GET请求，服务器完成了它300 Multiple Choices客户请求的⽂档可以在多个位置找到，这些位置已经在返回的⽂档内列出。
如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently客户请求的⽂档在其他地⽅，新的URL在Location头中给出，浏览器应该⾃动地访问新的URL。
302 Found类似于301，但新的URL应该被视为临时性的替代，⽽不是永久性的。
303 See Other类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向⽬标⽂档应该通过GET提取304 Not Modified客户端有缓冲的⽂档并发出了⼀个条件性的请求（⼀般是提供If-Modified-Since头表⽰客户只想⽐指定⽇期更新的⽂档）。
中国电信SIP规范第一部分_总体要求
中国电信SIP协议规范——总体要求（试行）2004年4月发布 2004年4月试行中国电信集团公司发布前言SIP协议是下一代网络中的接口协议之一，属于应用控制协议。
本标准是以IETF和ITU-T的相关标准为基础，结合中国电信网络的实际情况，并综合中国电信集团公司对下一代网络的实验成果制定的。
它是中国电信在下一代网络建设中引进、测试和研发软交换设备、SIP终端设备以及其他基于SIP协议相关设备的规范和依据。
鉴于SIP协议应用范围广泛，项目组在编写时将整个协议规范分为3个分册：第一分册：《总体要求》第二分册：《协议细则》第三分册：《信令流程》本分册为《总体要求》分册本标准由中国电信集团公司提出。
本标准由中国电信集团公司归口。
本标准2004年4月首次发布。
本标准由中国电信集团公司负责解释。
目录1范围 (1)2术语说明 (1)3参考标准 (2)4符号及缩写 (5)5SIP网络系统结构 (6)5.1 系统框架 (6)5.2 实体说明 (7)5.3 接口说明 (7)5.3.1 NNI接口 (7)5.3.2 UNI接口 (8)5.3.3 其它接口 (8)6实体能力要求 (8)6.1 用户终端（User Terminal UA） (8)6.1.1 协议支持 (9)6.2 代理服务器（Proxy） (10)6.2.1 协议支持 (10)6.2.2 路由 (11)6.2.3 安全性 (12)6.3 注册服务器（Registrar） (13)6.3.1 协议支持 (13)6.3.2 功能要求 (13)6.3.3 注册及更新 (13)6.3.4 注销 (14)6.3.5 其他要求 (14)6.4 重定向服务器（Redirect Server） (14)6.5 SIP-ISUP互通单元 (15)7SIP网络与PSTN的互通 (15)7.1 网络互通模型 (15)7.1.1 PSTN用户-SIP用户 (16)7.1.2 SIP用户-PSTN用户 (17)7.1.3 PSTN用户-SIP网络-PSTN用户 (18)7.2 SIP-ISUP互通单元能力要求 (21)8业务和应用 (21)8.1 B2BUA (21)8.1.1 定义及实现 (21)8.1.2 呼叫和业务控制 (22)8.2 即时消息 (23)8.2.1 业务体系 (23)8.2.2 协议支持 (23)8.3 Presence (23)8.3.1 业务体系 (23)8.3.2 协议支持 (25)8.3.3 与其他业务相结合 (26)8.4 并行、串行寻址 (26)8.4.1 串行寻址： (26)8.4.2 并行寻址 (27)8.5 SIP用户的呼叫等待业务 (27)8.6 应用服务器和软交换之间的SIP接口 (28)8.7 SIP协议在业务控制方面的应用 (28)8.8 跨域智能业务的考虑 (28)8.9 软交换控制下的IAD用户对局间信令的要求 (29)8.10 语音提示音的播放 (29)8.11 媒体端口打开与计费点启动的考虑 (30)图表目录图 5-1 SIP网络系统逻辑结构示意 (7)图 7-1 PSTN用户-SIP用户 (16)图 7-2 SIP用户-PSTN用户 (17)图 7-3 PSTN用户-SIP网络-PSTN用户 (18)图 8-1基于SIP 的Presence 业务体系 (23)1范围本分册主要对SIP网络系统结构做出规定，对其中涉及到的接口以及相关实体的功能作出简要说明和要求。
IPTV机顶盒技术规范V2.2_修订版_090622
文件编号：SHDX/ZS/CZ/JG/005/B/2009中国电信上海公司IPTV机顶盒技术规范V2.2（修订版）1目的本规范是在中国电信集团公司发布的《IPTV机顶盒技术规范V2.0》的基础上，根据中国电信上海公司IPTV业务发展的需求以及IPTV运营的实际情况，进一步调整修订而成的。
本技术规范的增补、修订和解释权归中国电信上海公司所有。
如中国电信上海公司在此之前的文件与本技术规范有矛盾，按此技术规范执行。
本技术规范自发布之日起实施。
2适用范围本技术规范规定了IPTV终端的应用功能、操作要求、终端管理和接口要求等方面的内容。
本规范供中国电信上海公司引入机顶盒终端设备时参照执行。
同时，本规范也为终端厂商进行机顶盒终端设备开发制造提供依据。
3引用文件/标准下列标准所包含的条文，通过本技术要求的引用而构成本技术要求的条文。
在本技术要求出版时，所示版本均为有效。
所有标准都可能推出更新版本，使用本技术要求的各方应探讨使用下列标准最新版本的可能性。
GB13837-2003: 声音和电视广播接收机及有关设备无线电干扰特性限值和测量方法GB8898-2001: 音频、视频及类似电子设备安全要求RFC1889： A Transport Protocol for Real-Time ApplicationsSJ/T10730：电视广播接收机测量方法TR069：CPE WAN Management ProtocolYD/T 965-1998：电信终端设备的安全要求和试验方法YD/T 993-1998: 电信终端设备防雷技术要求及试验方法4定义/术语DHCP Dynamic Host Configuration Protocol 动态主机配置协议DNS Domain Name System 域名系统DRM Digital Rights Management 数字版权管理EPG Electronic Programmer Guide 电子节目单FTP File Transfer Protocol 文件传输协议HTML Hypertext Markup Language 超文本标记语言HTTP Hypertext Transfer Protocol 超文本传输协议HTTPS Hypertext Transfer Protocol Secure 安全超文本传输协议IGMP Internet Group Management Protocol 互连网组管理协议IP Internet Protocol 网络协议MAC Media Access Control 媒体访问控制层MPEG-4 Moving Picture Exp-erts Group 移动图像专家组定义NTP Network Time Protocol 网络时间协议OSD On-screen Display 屏幕视控系统OSS Operation Support System 运营支撑系统PPPoE PPP over Ethernet 基于以太网点对点协议RTCP Real-time Transport Control Protocol 实时传输控制协议RTP Real-time Transport Protocol 实时传输协议RTSP Real-time Transport Streaming Protocol 实时传输流媒体协议SIP Session Initiation Protocol 起始会话协议S/N Signal/Noise 信噪比SOAP imple Object Access Protocol 简单对象访问协议SSL Secure Socket Layer安全套接字层STB Set Top Box 机顶盒TCP Transmission Control Protocol 传输控制协议TFTP Trivial File Transfer Protocol 简单文件传输协议TS Transport Stream 传输流UDP User Datagram Protocol 用户数据报协议UPnP Universal Plug and Play 通用即插即用USB Universal Serial Bu 通用串行总线XML Extensible Markup Language 可扩展标记语言5机顶盒定义IPTV机顶盒终端是指具备网络接入和页面信息浏览、视音频播放等交互式应用功能，可直接连接电视机音响等播放设备的多媒体终端。
SIP协议介绍(RFC3261)
》由代理服务器并行分发的请求，其Cseq值相同。
20
主要头部字段
Via 》请求消息经过的路径，用于响应的发送。响应和请求必须走相同的路
径。Branch参数用于识别事务。
Max_Forward 》请求的最大转发次数 Contact 》后续请求发送的目的地 Record_Route 》用于标识prxoy，指定后续消息必须经过该proxy Route
17
SIP消息的格式
SIP 消 息＝ 起 始 行 *消 息 头 部（1 个 或 多 个 头 部） CRLF ( 空 行 ) 〖 消息体〗
18
SIP消息格式
请求的起始行 Request-Line = Method SP Request-URI SP SIP-Version CRLF 响应的起始行 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
协收到的协求消息协行协和协理后协协协其他的服协用于存放sip协重定向服协器或proxy提供用协一或者11sip接收sip协求把协求中的原地址映射协零个重定向服协器不协起自己的呼叫不协送协3xx协协行重定向12sipsipproxyserverredirectserverregisterserverserver可共存于一协协也可以分布在不同的物理协sip服协器完全是协协件协协可以根据需要proxyserverredirectserver角色不是固定不协的一个ua叫中可以是uac也可以是uasserver是一个sip协公共协源协信息咨协所采用的协协不是sip而是其lightdirectoryaccessprotoco呼叫和媒控制信息同协协送15sip协送和接收sip消息匹配事协状proxy外每个sip16sip2xx成功3xx重定向6xx全局协协ack用于invite的register注册17sipsip事协包括一协求和其中协包括invite事协协包括invite协求的2xxsipsip协求的起始行requestlinemethodsprequesturispsipversioncrlfsipversionspstatuscodespreasonphrasecrlf20协求的协协接收者totagfromtagcallid特定邀协或注的唯一协协cseq相同的callid协但不同协求方法协部或消息cseq序号invite协求相同bye协求的cseq协协大于invitecseq协相同
SIP协议中的媒体协商
Reliable Provisional Responses、
EarlyMedia扩展需求
• 扩展目的
– 传递可靠的呼叫进展 – 传递被叫侧的媒体描述
• 扩展方法
– 扩展消息 PRACK
• 为1xx响应提供消息确认
– 扩展消息头 RSeq／RAck
• 保证PRACK与对应的1xx匹配
– 1xx响应扩展消息头：RSeq – PRACK请求扩展消息头：RAck
• PRACK是1xx的“最终响应”
– 如果INVITE-1xx完成了Offer-Answer，PRACK-200PRACK可 以完成进一步的Offer-Answer
• PRACK－200PRACK是可靠传输的
– 如果可靠的1xx携带Answer，则必须建立Session
• 一次Offer-Answer结束了 • Early Session
ANM
200
INVITE ACK
200 INVITE
ACK
64 T1 ACM
ANM
CPG ?
如何传递呼叫中事件
STATE KEY LABORATORY TELECOMMUNICATION NETWORK
需求的分析（续）
UserA
INVITE SDP 100
– 增加消息
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
与传统Telephony业务互通的努力
• IETF
– Session Initiation Protocol for Telephones – 俗称 SIP-T
• ITU-T
爱立信交换机网元话单采集应急上传系统应用实践
第40卷第3期2019年9月山东通信技术S handong C o m m unication TechnologyV〇1.40No.3Sep.2019爱立信交换机网元话单采集应急上传系统应用实践郭洪新李涛(中国移动山东公司，济南250001)摘要：针对某运营商BOSS采集系统爱立信交换机网元故障后话单采集上传实时性无法得到有效保障这一短板，本文探 索出了一套基于曰常操作的爱立信交换机网元话单采集应急上传系统，根据职责分工、流程梳理、系统控制，在爱立信交换机网元出现故障时能够实现话单采集自动上传，保证了BOSS采集的实时性、准确性，为业务支撑系统计费的及时、准确提供了安全保障。
关键词：BOSS采集爱立信交换机话单应急上传1引言BOSS采集系统是运营商整个业务支撑系统中非 常重要的环节，不仅承担着传统语音、数据、智能网 等不同网元话单的采集，还负责漫游话单的上传及接 收、各类新业务平台话单的采集以及按需进行BOSS 各相关子系统的话单分发等任务。
确保话单采集的 实时、准确、稳定、安全，是保证整个BOSS系统业 务处理实时性、稳定性、准确性的重要前提，也是欠 费风险控制和收入保障的重要前提。
某运营商现有爱立信交换机网元257台，分布在 52个机房中，每年平均发生爱立信交换机网元及链路 故障近百起，造成延迟话单几十万条，造成话单的及 时性、准确性无法得到有效保障，存在很大的安全风 险。
某运营商对BOSS话单采集系统流程进行了分析，梳理了使用情况，总结出话单采集系统管理所面临的 困难，主要包括：(1 )采集、维护分工不清，出现问题没有快速应 急处理流程及方法；(2 )爱立信交换机网元出现故障时，只能由地市 网络部手工传送文件给地市业务支撑中心，后者再手工上传省公司话单采集服务器，处理时间较长，话单 及时性难以得到保障；(3 )地市业务支撑中心到省公司采集服务器传输 链路出现故障时，没有备用链路，导致话单文件无法 及时传送到采集服务器，只能发送邮件给省公司相关 人员处理，造成流程环节较多，话单及时率、完整性 无法得到保障。
环回口功能
路由器环回口的功能此类接口是应用最为广泛的一种虚接口，几乎在每台路由器上都会使用。
常见于如下用途。
1 作为一台路由器的管理地址系统管理员完成网络规划之后，为了方便管理，会为每一台路由器创建一个loopback 接口，并在该接口上单独指定一个IP 地址作为管理地址，管理员会使用该地址对路由器远程登录（telnet ），该地址实际上起到了类似设备名称一类的功能。
但是通常每台路由器上存在众多接口和地址，为何不从当中随便挑选一个呢？原因如下：由于telnet 命令使用TCP 报文，会存在如下情况：路由器的某一个接口由于故障down 掉了，但是其他的接口却仍旧可以telnet ，也就是说，到达这台路由器的TCP 连接依旧存在。
所以选择的telnet 地址必须是永远也不会down 掉的，而虚接口恰好满足此类要求。
由于此类接口没有与对端互联互通的需求，所以为了节约地址资源，loopback 接口的地址通常指定为32 位掩码。
2 使用该接口地址作为动态路由协议OSPF 、BGP的router id动态路由协议OSPF 、BGP 在运行过程中需要为该协议指定一个Router id，作为此路由器的唯一标识，并要求在整个自治系统内唯一。
由于router id 是一个32 位的无符号整数，这一点与IP 地址十分相像。
而且IP 地址是不会出现重复现象的，所以通常将路由器的router id 指定为与该设备上的某个接口的地址相同。
由于loopback 接口的IP 地址通常被视为路由器的标识，所以也就成了router id 的最佳选择。
3、使用该接口地址作为BGP 建立TCP 连接的源地址在BGP 协议中，两个运行BGP 的路由器之间建立邻居关系是通过TCP 建立连接完成的。
在配置邻居时通常指定loopback 接口为建立TCP 连接的源地址（通常只用于 IBGP ，原因同2.1 ，都是为了增强TCP 连接的健壮性）配置命令如下：router id 61.235.66.1interface loopback 0ip address 61.235.66.1 255.255.255.255router bgp 100neighbor 61.235.66.7 remote-as 200neighbor 61.235.66.7 update-source LoopBack0Loop口在实际中有非常广泛的应用，这个文章是是关于Loopback口使用的大全BGP Update-Source因为Loopback口只要Router还健在，则它就会一直保持Active，这样，只要BGP的Peer的Loopback口之间满足路由可达，就可以建立BGP 回话，总之BGP中使用loopback口可以提高网络的健壮性。
中国电信IP城域网设备测试规范-汇聚交换机v2.0
附件4：企业秘密中国电信IP城域网设备测试规范（汇聚交换机）（V2.0）中国电信集团公司二零零六年一月目录1. 概述 (1)1.1范围 (1)1.2引用标准 (1)1.3缩略语 (2)2. 测试环境和仪表 (3)2.1测试环境 (3)2.2测试仪表 (3)3. 测试内容 (4)4. 二层交换功能测试 (4)4.1基本功能测试 (4)4.1.1 超长帧转发能力 (4)4.1.2 异常帧检测功能测试 (5)4.1.3 广播抑制功能测试 (6)4.2镜像功能 (6)4.2.1 端口镜像功能测试 (6)4.2.2 流镜像功能测试 (7)4.3生成树协议测试 (8)4.3.1 标准生成树测试 (8)4.3.2 快速生成树测试 (9)4.3.3 多生成树测试 (10)4.4VLAN堆叠功能测试 (11)4.4.1 基本功能 (11)4.4.2 扩展功能 (12)4.5端口聚合 (14)4.5.1 聚合链路数量测试 (14)4.5.2 聚合效率测试 (15)4.5.3 聚合链路收敛时间测试 (16)4.6二层组播功能测试 (17)4.6.1 UNTAGGED端口IGMP SNOOPING功能测试 (17)4.6.2 TAGGED端口IGMP SNOOPING功能测试 (18)4.6.3 组播组加入/离开时间测试 (19)4.7P RIV ATE V LAN功能测试 (20)4.8V LAN交换功能测试 (21)5. 访问控制和QOS功能 (22)5.1访问控制表方向性测试 (22)5.2二层访问控制表测试 (23)5.2.1 MAC地址访问控制表测试 (23)5.2.2 VLAN访问控制表测试 (23)5.2.4 SVLAN访问控制表测试 (25)5.3三层访问控制表功能测试 (26)5.3.1 IP地址访问控制表功能测试 (26)5.3.2 四层端口访问控制表功能测试 (26)5.4访问控制表数量及性能测试 (27)5.5业务分级 (28)5.5.1 基于VLAN ID的业务分级 (28)5.5.2 基于四层端口的业务分级 (29)5.5.3 SVLAN内外层标签802.1P优先级映射 (30)5.6优先级队列 (31)5.6.1 严格优先级队列 (31)5.6.2 轮询队列 (31)5.7速率限制 (32)5.7.1 入方向速率限制功能测试 (32)5.7.2 出方向速率限制功能测试 (33)5.7.3 速率限制颗粒度及精确性测试 (34)6. 转发性能测试 (35)6.1MAC地址学习速度 (35)6.2MAC地址表容量 (35)6.3最大VLAN数量测试 (36)6.4单端口吞吐量和时延测试 (37)6.5板内交换性能测试 (38)6.6板间交换性能测试 (39)6.7综合转发性能测试 (40)7. 可靠性和安全性 (41)7.1设备可靠性 (41)7.1.1 主控板和交换矩阵冗余 (41)7.1.2 电源冗余 (42)7.1.3 业务卡热插拔 (42)7.1.4 设备重启动时间 (43)7.2网络安全 (44)7.2.1 端口地址数量限制 (44)7.2.2 设备防ARP攻击测试 (45)7.2.3 设备防ICMP攻击测试 (45)7.2.4 设备防BPDU攻击测试 (46)8. 运行维护和网络管理 (47)8.1运行维护功能测试 (47)8.1.1 远程认证管理 (47)8.1.2 SSH登录测试 (48)8.1.3 日志记录 (48)8.1.4 DHCP Option82功能测试 (49)8.2.1 SNMPv1、SNMPv2支持测试 (50)8.2.2 SNMPv3支持测试 (50)8.2.3 SNMP访问地址限制 (51)8.2.4 MIB View安全访问控制功能测试 (52)8.2.5 SNMP Trap功能测试 (52)8.3管理信息库 (53)8.3.1 端口MIB的功能测试 (53)8.3.2 VLAN MIB的功能测试 (53)8.3.3 CPU利用率、内存占用率的功能测试 (54)8.3.4 资源管理信息功能测试 (54)8.3.5 ACL管理信息功能测试 (55)8.3.6 QOS的管理功能测试 (55)8.3.7 二层组播MIB (56)8.3.8 SVLAN MIB (56)中国电信IP城域网设备测试规范-汇聚交换机1. 概述1.1 范围本规范主要参考我国相关标准、RFC标准、国际电信联盟ITU-T相关建议以及《中国电信城域网优化改造指导意见》、《中国电信城域网设备技术规范》编制。
SIP协议栈
SIP协议栈协议名称：SIP（Session Initiation Protocol）协议栈协议描述：SIP协议栈是一种用于建立、修改和终止多媒体味话的通信协议。
本协议旨在为实时通信提供一种灵便、可扩展和互操作的解决方案。
SIP协议栈是基于文本的协议，使用请求-应答模型进行通信。
协议内容：1. 协议概述SIP协议栈是一种应用层协议，用于在IP网络上建立、修改和终止多媒体味话。
它提供了一种可扩展、灵便且易于实现的解决方案，支持语音、视频、即时消息和其他多媒体应用。
2. 协议架构SIP协议栈由以下几个组件构成：- SIP用户代理（User Agent，UA）：用户终端设备或者应用程序，用于发起和接受SIP请求。
- SIP代理服务器（Proxy Server）：用于转发、路由和处理SIP请求。
- SIP注册服务器（Registrar Server）：用于管理用户的注册信息。
- SIP重定向服务器（Redirect Server）：用于重定向SIP请求。
- SIP会话边界控制器（Session Border Controller，SBC）：用于处理SIP请求和响应的边界设备。
3. 协议消息格式SIP协议使用文本格式的请求和应答消息进行通信。
请求消息包括请求行、消息头和消息体，应答消息包括状态行、消息头和消息体。
消息头包含各种标识和参数，用于指定请求或者应答的属性和行为。
4. 协议流程SIP协议栈的典型流程如下：- 用户代理向注册服务器发送注册请求，以注册用户的位置信息。
- 注册服务器将用户的位置信息存储在注册表中。
- 当用户代理需要建立会话时，它向代理服务器发送INVITE请求。
- 代理服务器根据路由规则将INVITE请求转发给目标用户代理。
- 目标用户代理接受INVITE请求，并发送200 OK应答。
- 用户代理之间通过交换ACK和应答消息来建立会话。
- 会话结束时，用户代理发送BYE请求，双方发送200 OK应答，会话终止。
鼎信MTG1000 媒体中继网关用户手册说明书
MTG1000媒体中继网关用户手册V2.1深圳鼎信通达科技有限公司地址：广东省深圳市南山区常兴路国兴大厦六楼邮编：518052电话：+86 755 2645 6664传真：+86 755 2645 6659邮箱：*****************,*******************网址：修正记录目录1.设备介绍 (1)1.1概述 (1)1.2外观描述 (2)1.2.1前视图 (2)1.2.2后视图 (3)1.2.3 RJ-48c线序 (3)1.3功能和特点 (4)1.3.1支持的协议 (4)1.3.2 系统功能 (4)1.3.3 支持的工业标准 (4)1.3.4 硬件说明 (4)2.参数配置 (5)2.1 登陆 (5)2.1.1查看或更改设备IP (5)2.1.2登录 (5)2.2 Web界面结构和导航树 (6)2.3 运行信息 (8)2.4.1 系统信息 (8)2.3.2 E1/T1状态 (9)2.3.3 PSTN中继状态 (10)2.3.4 IP中继状态 (11)2.3.5 PRI呼叫统计 (12)2.3.6 SS7呼叫统计 (13)2.3.7 SIP呼叫统计 (13)2.3.8 H.323呼叫统计 (13)2.4网络配置 (14)2.5 PRI配置 (15)2.5.1 PRI 参数 (15)2.5.2 PRI中继 (16)2.6 SS7配置 (17)2.6.1 SS7中继 (17)2.6.2 SS7链路 (19)2.6.3 SS7电路 (19)2.6.4 SS7电路维护 (20)2.7 PSTN分组配置 (22)2.7.1 E1/T1参数 (22)2.7.2编解码分组 (23)2.7.3拨号规则 (23)2.7.4拨号超时 (25)2.7.5 PSTN规则 (26)2.7.6 PSTN分组 (27)2.7.7 PSTN分组管理 (27)2.8 SIP配置 (28)2.8.1 SIP参数 (28)2.8.2 SIP中继 (29)2.9 H.323配置 (31)2.9.1 H.323参数 (31)2.9.2 H.323中继 (32)2.10 IP分组配置 (33)2.10.1 IP规则 (33)2.10.2 IP分组 (34)2.10.3 IP分组管理 (35)2.11呼叫路由 (35)2.11.1路由参数 (35)2.11.2 PSTN->IP路由 (36)2.11.3 PSTN->PSTN路由 (37)2.11.4 IP->PSTN路由 (39)2.11.5 IP->IP路由 (40)2.12号码变换 (42)2.12.1 PSTN->IP被叫号码 (42)2.12.2 PSTN->IP主叫号码 (44)2.13语音&传真 (46)2.14维护 (47)2.14.1 参数管理 (47)2.14.2 SNMP参数 (48)2.14.3 数据备份 (49)2.14.4 数据还原 (49)2.14.5 版本信息 (49)2.14.6 软件升级 (50)2.14.7密码修改 (50)2.14.8 重启设备 (50)3.常见问题 (51)3.1 如果修改或忘记了IP地址如何重新获得？ (51)3.2 设备物理连接正常，但网络不通或网络通信不正常 (51)3.3 设备不能注册 (51)4. 术语 (52)1.设备介绍1.1概述MTG1000 是一款基于嵌入式操作系统针对运营商和呼叫中心设计的媒体中继网关，它是语音IP化改造和NGN解决方案的重要组成部分，它位于IP语音网络的边缘接入层，连接PSTN和VoIP网络，实现IP到TDM转换功能。
sip over websocket
Network Working Group I. Baz Castillo Internet-Draft J. Luis Millan Intended status: Standards Track XtraTelecom S.A. Expires: March 16, 2012 V. Pascual Acme Packet September 13, 2011 WebSocket Transport for Session Initiation Protocol (SIP)draft-ibc-rtcweb-sip-websocket-00AbstractThis document specifies a WebSocket subprotocol for a new transportin SIP (Session Initiation Protocol). The WebSocket protocol enables two-way realtime communication between clients (typically web-basedapplications) and servers. The main goal of this specification is to integrate the SIP protocol within web applications.Status of this MemoThis Internet-Draft is submitted in full conformance with theprovisions of BCP 78 and BCP 79.Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF). Note that other groups may also distributeworking documents as Internet-Drafts. The list of current Internet- Drafts is at /drafts/current/.Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."This Internet-Draft will expire on March 16, 2012.Copyright NoticeCopyright (c) 2011 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Baz Castillo, et al. Expires March 16, 2012 [Page 1]Internet-Draft SIP over WebSocket September 2011 the Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 43. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 6 4.1. Via Transport Parameter . . . . . . . . . . . . . . . . . 6 4.2. SIP URI Transport Parameter . . . . . . . . . . . . . . . 64.3. Sending Responses . . . . . . . . . . . . . . . . . . . . 75. The WebSocket SIP Subprotocol . . . . . . . . . . . . . . . . 86. WebSocket Client Usage . . . . . . . . . . . . . . . . . . . . 96.1. WebSocket Disconnection . . . . . . . . . . . . . . . . . 107. WebSocket Server Usage . . . . . . . . . . . . . . . . . . . . 117.1. SIP Proxy Considerations . . . . . . . . . . . . . . . . . 118. WebSocket Connection Keep Alive . . . . . . . . . . . . . . . 129. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 159.3. INVITE dialog through two proxies . . . . . . . . . . . . 1810. Security Considerations . . . . . . . . . . . . . . . . . . . 2311. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11.1. Registration of new Via transports . . . . . . . . . . . . 24 11.2. Registration of new SIP URI transport . . . . . . . . . . 2411.3. Registration of the WebSocket SIP subprotocol . . . . . . 2412. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Baz Castillo, et al. Expires March 16, 2012 [Page 2]Internet-Draft SIP over WebSocket September 2011 1. IntroductionIntegrating the SIP protocol [RFC3261] within modern web-basedapplications has been a hard task historically due to thespecification complexity and inherent limitations in web browsers and HTTP protocol [RFC2616]. The arrival of WebSocket[I-D.ietf-hybi-thewebsocketprotocol] and [RTC-Web] (Real TimeCollaboration on the World Wide Web) provides a two-way communication technology for web-based applications along with multimediacapabilities for audio and video sessions in web browsers, makingfeasible the requeriments of the SIP protocol.This specification defines a new WebSocket subprotocol fortransporting SIP messages between a WebSocket client and server, anew transport for the SIP protocol and procedures for SIP proxieswhen behaving as a bridge between WebSocket and other SIP transports. No changes have been made to the SIP protocol [RFC3261].Baz Castillo, et al. Expires March 16, 2012 [Page 3]Internet-Draft SIP over WebSocket September 2011 2. ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].Baz Castillo, et al. Expires March 16, 2012 [Page 4]Internet-Draft SIP over WebSocket September 2011 3. ScopeThe WebSocket protocol is mostly suitable for web-based applications running in a web browser. Other applications running out of webbrowsers do not have the constraints of web applications sincetypically they can directly access to the transport layer.In the same manner, the WebSocket protocol adds a network overheadsince it works as an intermediary layer between the transport andapplication layers. There is no benefit on using SIP over WebSocket transport between two SIP nodes when none of them runs within a webbrowser. Even more, the WebSocket protocol is not symmetric sincejust a WebSocket client can open a connection to a WebSocket server(a WebSocket client does not listen for incoming connections).Given these arguments, this specification is mostly focused onintegrating the SIP protocol within web-based applications or anyclient application using the WebSocket protocol. Other aspects such as DNS NAPTR/SRV resolution for SIP over WebSocket transport are not covered by this specification since they are mainly useless given the WebSocket protocol nature.This document just covers SIP as a signalling protocol, leavingmultimedia capabilities integration for a separate document once[RTC-Web] (Real Time Collaboration on the World Wide Web) becomes astandard.Baz Castillo, et al. Expires March 16, 2012 [Page 5]Internet-Draft SIP over WebSocket September 2011 4. SIP WebSocket TransportWebSocket [I-D.ietf-hybi-thewebsocketprotocol] is a reliable protocol and therefore the WebSocket subprotocol for a SIP transport definedby this document is also a reliable transport. Thus, client andserver transactions using WebSocket transport MUST follow theprocedures and timer values for a reliable transport as defined in[RFC3261].4.1. Via Transport ParameterVia header fields carry the transport protocol identifier. Thisdocument defines the value "WS" to be used for requests over plainWebSocket protocol and "WSS" for requests over secure WebSocketprotocol (in which the WebSocket session is established on top of TLS [RFC5246] over TCP transport).The updated augmented BNF (Backus-Naur Form) [RFC5234] for thisparameter is the following (the original BNF for this parameter canbe found in [RFC3261]):transport = "UDP" / "TCP" / "TLS" / "WS" / "WSS"/ other-transportThe following are examples of Via header fields using "WS" and "WSS": Via: SIP/2.0/WS 1.2.3.4:28456Via: SIP/2.0/WSS [2001:0:63ba:74c:1806:7ea2:9aab:f892]:328024.2. SIP URI Transport ParameterThis document defines the value "ws" as the transport parameter value for a SIP URI [RFC3986] to be contacted using WebSocket protocol.Whether to select a plain or secure WebSocket connection depends onthe SIP URI schema ("sip" schema means plain WebSocket connectionwhile "sips" schema requires secure WebSocket connection).The updated augmented BNF (Backus-Naur Form) [RFC5234] for thisparameter is the following (the original BNF for this parameter canbe found in [RFC3261]):transport-param = "transport="( "udp" / "tcp" / "sctp" / "tls" / "ws"/ other-transport )The following are examples of SIP URI’s containing a "ws" transportparameter:Baz Castillo, et al. Expires March 16, 2012 [Page 6]Internet-Draft SIP over WebSocket September 2011 sip:alice@1.2.3.4:28456;transport=wssips:bob@[2001:0:63ba:74c:1806:7ea2:9aab:f892]:32802;transport=ws 4.3. Sending ResponsesThe SIP server transport uses the value of the top Via header fieldin order to determine where to send a response. If the "sent-protocol" is "WS" or "WSS" the response MUST be sent using theexisting WebSocket connection to the source of the original request, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections. If that connection is no longer open, the server MUSTNOT attempt to open a WebSocket connection to the Via "sent-by"/"received"/"rport".This is due the nature of the WebSocket protocol in which just the WebSocket client can establish a connection with the WebSocketserver. A WebSocket client does not listen for incomingconnections.Baz Castillo, et al. Expires March 16, 2012 [Page 7]Internet-Draft SIP over WebSocket September 2011 5. The WebSocket SIP SubprotocolThe term WebSocket subprotocol refers to the application-levelprotocol layered over a WebSocket connection. This documentspecifies the WebSocket SIP subprotocol for carrying SIP requests and responses through a WebSocket connection.WebSocket [I-D.ietf-hybi-thewebsocketprotocol] defines message units as application data exchange for communication endpoints, becoming a message boundary protocol. These messages can contain UTF-8 text or binary data. The WebSocket SIP subprotocol specified in thisdocument mandates messages of type UTF-8 text.The WebSocket client and WebSocket server send SIP messages to eachother. Each SIP message MUST be carried within a single WebSocketmessage and MUST be a complete SIP message, so a Content-Lengthheader field is not mandatory. Sending more than one SIP messagewithin a single WebSocket message is not allowed, neither sending an incomplete SIP message.This makes parsing of SIP messages easier on client side(typically web-based applications with an strict and simple APIfor receiving WebSocket messages). There is no need to establish boundaries (typically using Content-Length headers) betweendifferent messages. Same advantage is present in other message-based SIP transports as UDP or SCTP [RFC4168].Baz Castillo, et al. Expires March 16, 2012 [Page 8]Internet-Draft SIP over WebSocket September 2011 6. WebSocket Client UsageAs stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI[RFC3986] is given to the WebSocket client (typically within a web-based application) who resolves the URI destination and establishes a WebSocket connection with the corresponding server (by performing the handshake and negotiation procedures described in[I-D.ietf-hybi-thewebsocketprotocol]).The client application is supposed to be provided with SIP accountconfiguration values (as an AoR, outbound proxy and so on). Suchvalues are used by the client application when generating SIPmessages.After establishing the WebSocket connection, the client SHOULDdiscover the source IP and port from which the server has receivedthe TCP connection. Such IP and port are required for constructingthe client’s SIP local URI (to be used in Contact header during SIPregistration and SIP dialogs).The mechanism used by the client application in order to discover its source IP and port is currently out of the scope of thisspecification, although it might be defined in future revisions of this document.The client’s SIP local URI MUST be constructed as follows:o If the WebSocket connection is secure (given WebSocket URI has"wss" schema) the URI MUST have "sips" schema, "sip" otherwise.o The URI username is up to the application.o The URI hostport is determined by the local IP and port previously retrieved.o A "transport" parameter with value "ws" MUST be added to the URI. This SIP local URI MUST be used by the client as a registrationbinding (Contact URI in a REGISTER) and as a local target for SIPdialogs (Contact URI in a request or response) since this URI is the only adddress in which the client can be contacted, and just through the WebSocket server.Any new request sent by the client MUST contain the discovered local IP and port in the Via "sent-by" field. Via "sent-transport" fieldMUST be set to "WSS" if the WebSocket connection is secure, to "WS"otherwise.Baz Castillo, et al. Expires March 16, 2012 [Page 9]Internet-Draft SIP over WebSocket September 2011 Due to the nature of the WebSocket protocol, the client sends all the SIP requests to the WebSocket server it is connected to, so theWebSocket server behaves as a de facto outbound SIP proxy.In case the client application decides to close the WebSocketconnection (for example when performing "logout" in a webapplication) it is recommended to remove the existing SIPregistration binding (if present) by specifying an expirationinterval of "0" for that contact address in a REGISTER request asdescribed in section 10.2.2 of [RFC3261].6.1. WebSocket DisconnectionIn some circumstances the WebSocket connection could be terminated by the WebSocket server (for example when the server is restarted). If the client application wants to become reachable again it SHOULDreconnect to the WebSocket server and perform the SIP local URIdiscovery process again followed by a new SIP registration.The client MAY also remove the previous registration binding in theregistrar server, as such address is no longer reachable.When the WebSocket server is also the SIP registrar server, it MAY remove the SIP registration bindings associated to a WebSocketconnection after such connection has been closed. Such a decision is out of the scope of this specification and depends on the SIPnetwork topology.Baz Castillo, et al. Expires March 16, 2012 [Page 10]Internet-Draft SIP over WebSocket September 2011 7. WebSocket Server UsageHere we assume that a SIP proxy or UAS (User Agent Server) is alsoacting as a WebSocket server implementing the WebSocket subprotocoldescribed in this document. The server receives WebSocket connection attempts from clients. How the server authorizes or not thoseconnections is out of the scope of this specification. Once theWebSocket subprotocol defined in this document has been negotiated,both client and server can send SIP messages to each other.The server can only contact a SIP URI with the parameter"transport=ws" in case the destination address belongs to an existing WebSocket connection established from a WebSocket client. If not, a local transport error MUST be generated (which involves a 500 or 503 SIP response code).Such a case could happen when an existing SIP registration binding points to an already closed WebSocket connection which was notremoved.7.1. SIP Proxy ConsiderationsA SIP proxy implementing WebSocket transport can intercommunicateclients using SIP over WebSocket with other SIP clients or nodesusing any other transport.When the proxy bridges between WebSocket transport and any other SIP transport (including WebSocket transport) it MUST perform LooseRouting as specified in [RFC3261]. Otherwise in-dialog requestswould fail since WebSocket clients cannot contact destinations other than their WebSocket server, and non-WebSocket SIP nodes cannotestablish a connection to WebSocket clients. It is also recommended that the proxy follows recommendations in [RFC5658] and uses doubleRecord-Route technique in these cases.In the same way, if the SIP proxy implementing the WebSocket serverbehaves as an outbound proxy for REGISTER requests, it MUST add aPath header as described in [RFC3327]. Otherwise the WebSocketclient would never receive incoming requests from the SIP registrarserver after the lookup procedures in the SIP location service.Baz Castillo, et al. Expires March 16, 2012 [Page 11]Internet-Draft SIP over WebSocket September 2011 8. WebSocket Connection Keep AliveIt is recommended that the WebSocket client or server keeps theWebSocket connection open by sending periodic Ping frames asdescribed in [I-D.ietf-hybi-thewebsocketprotocol] section 5.5.2. The mechanisms of decision for a WebSocket endpoint to maintain, or not, the connection over time is out of scope of this document.In some cases due to transient network errors, the connection withthe WebSocket server could be lost without the WebSocket client being aware of it. The WebSocket client would only realize of the network failure when attempting to send new data over the WebSocketconnection.The authors of this specification have requested the W3C (WorldWide Web Consortium) to include a mechanism in the WebSocket API[WS-API] for instructing the WebSocket client to supervise theconnection by sending periodical Ping frames at the intervalrequested by the API user.Baz Castillo, et al. Expires March 16, 2012 [Page 12]Internet-Draft SIP over WebSocket September 2011 9. ExamplesThe flows depicted in this section describe the behavior of aninitial prototype which is currently under development.9.1. RegistrationAlice (SIP WS) WebSocket SIP Server| ||OPTIONS F1 ||---------------------------->||200 OK F2 ||<----------------------------|| ||REGISTER F3 ||---------------------------->||200 OK F4 ||<----------------------------|| |Alice is a WebSocket client running on a web browser. Aliceestablishes a plain WebSocket connection with a WebSocket server(also a SIP proxy/registrar) implementing the SIP subprotocol. Upon connection, Alice sends a SIP OPTIONS request including an empty"rport" parameter [RFC3581] in the Via header and obtains its source IP and port from the Via "received" and "rport" parameters in theresponse. Alice then forms its SIP local URI and constructs aREGISTER request.Message details (authentication and SDP bodies are omitted forsimplicity):Baz Castillo, et al. Expires March 16, 2012 [Page 13]Internet-Draft SIP over WebSocket September 2011 F1 OPTIONS Alice -> WebSocket SIP ServerOPTIONS sip: SIP/2.0Via: SIP/2.0/WS 1.2.3.4;branch=z9hG4bKasudf;rportFrom: sip:alice@;tag=ux8asodjTo: sip:Call-ID: 87djahs72kjsdCSeq: 1 OPTIONSMax-Forwards: 1Accept: application/sdpF2 200 OK WebSocket SIP Server -> AliceSIP/2.0 200 OKVia: SIP/2.0/WS 1.2.3.4;branch=z9hG4bKasudf;received=93.12.40.105;rport=19465From: sip:alice@;tag=ux8asodjTo: sip:;tag=jcx67hjmCall-ID: 87djahs72kjsdCSeq: 1 OPTIONSContent-Type: application/sdpF3 REGISTER Alice -> WebSocket SIP ServerREGISTER sip: SIP/2.0Via: SIP/2.0/WS 93.12.40.105:19465;branch=z9hG4bKasudfFrom: sip:alice@;tag=65bnmj.34asdTo: sip:Call-ID: aiuy7k9njasdCSeq: 1 REGISTERMax-Forwards: 70Contact: <sip:alice@93.12.40.105:19465;transport=ws>F4 200 OK WebSocket SIP Server -> AliceSIP/2.0 200 OKVia: SIP/2.0/WS 93.12.40.105:19465;branch=z9hG4bKasudfFrom: sip:alice@;tag=65bnmj.34asdTo: sip:;tag=12isjljn8Call-ID: aiuy7k9njasdCSeq: 1 REGISTERContact: <sip:alice@93.12.40.105:19465;transport=ws>Baz Castillo, et al. Expires March 16, 2012 [Page 14]Internet-Draft SIP over WebSocket September 2011 9.2. INVITE dialog through a proxyAlice (SIP WSS) SIP Proxy (SIP UDP) Carol| | ||INVITE F1 | ||---------------------------->| ||100 Trying F2 | ||<----------------------------| || |INVITE F3 || |---------------------------->|| |200 OK F4 || |<----------------------------||200 OK F5 | ||<----------------------------| || | ||ACK F6 | ||---------------------------->| || |ACK F7 || |---------------------------->|| | || Both Way RTP Media ||<=========================================================>|| | || |BYE F8 || |<----------------------------||BYE F9 | ||<----------------------------| ||200 OK F10 | ||---------------------------->| || |200 OK F11 || |---------------------------->|| | |Here the WebSocket server is also a SIP proxy and registrar for thedomain . Alice, a WebSocket SIP client, calls Carol’s AoR through a secure WebSocket connection. The WebSocket SIP server acts as a SIP proxy routing the INVITE to the UDP location of Carol. The proxy does Loose-Routing. Carol answers the call and terminates itlater.Message details (authentication and SDP bodies are omitted forsimplicity):F1 INVITE Alice -> SIP Proxy (transport WSS)INVITE sip:carol@ SIP/2.0Baz Castillo, et al. Expires March 16, 2012 [Page 15]Internet-Draft SIP over WebSocket September 2011 Via: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bK56sdasksFrom: sip:alice@;tag=asdyka899To: sip:carol@Call-ID: asidkj3ssCSeq: 1 INVITEMax-Forwards: 70Contact: <sips:alice@93.12.40.105:20565;transport=ws>Content-Type: application/sdpF2 100 Trying SIP Proxy -> Alice (transport WSS)SIP/2.0 100 TryingVia: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bK56sdasksFrom: sip:alice@;tag=asdyka899To: sip:carol@Call-ID: asidkj3ssCSeq: 1 INVITEF3 INVITE SIP Proxy -> Carol (transport UDP)INVITE sip:carol@77.123.45.23:5060 SIP/2.0Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKhjhjqw32cVia: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bK56sdasksRecord-Route: <sip:100.100.100.100;transport=udp>,<sips:100.100.100.100:9090;transport=ws>From: sip:alice@;tag=asdyka899To: sip:carol@Call-ID: asidkj3ssCSeq: 1 INVITEMax-Forwards: 69Contact: <sips:alice@93.12.40.105:20565;transport=ws>Content-Type: application/sdpF4 200 OK Carol -> SIP Proxy (transport UDP)SIP/2.0 200 OKVia: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKhjhjqw32cVia: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bK56sdasksRecord-Route: <sip:100.100.100.100;transport=udp>,<sips:100.100.100.100:9090;transport=ws>From: sip:alice@;tag=asdyka899To: sip:carol@;tag=bmqkjhsdCall-ID: asidkj3ssCSeq: 1 INVITEMax-Forwards: 69Baz Castillo, et al. Expires March 16, 2012 [Page 16]Internet-Draft SIP over WebSocket September 2011 Contact: <sip:carol@77.123.45.23:5060;transport=udp>Content-Type: application/sdpF5 200 OK SIP Proxy -> Alice (transport WSS)SIP/2.0 200 OKVia: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bK56sdasksRecord-Route: <sip:100.100.100.100;transport=udp>,<sips:100.100.100.100:9090;transport=ws>From: sip:alice@;tag=asdyka899To: sip:carol@;tag=bmqkjhsdCall-ID: asidkj3ssCSeq: 1 INVITEMax-Forwards: 69Contact: <sip:carol@77.123.45.23:5060;transport=udp>Content-Type: application/sdpF6 ACK Alice -> SIP Proxy (transport WSS)ACK sip:carol@77.123.45.23:5060;transport=udp SIP/2.0Via: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bKhgqqp090Route: <sips:100.100.100.100:9090;transport=ws>,<sip:100.100.100.100;transport=udp>From: sip:alice@;tag=asdyka899To: sip:carol@;tag=bmqkjhsdCall-ID: asidkj3ssCSeq: 1 ACKMax-Forwards: 70F7 ACK SIP Proxy -> Carol (transport UDP)ACK sip:carol@77.123.45.23:5060;transport=udp SIP/2.0Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKhwpoc80zzxVia: SIP/2.0/WSS 93.12.40.105:20565;branch=z9hG4bKhgqqp090From: sip:alice@;tag=asdyka899To: sip:carol@;tag=bmqkjhsdCall-ID: asidkj3ssCSeq: 1 ACKMax-Forwards: 69F8 BYE Carol -> SIP Proxy (transport UDP)BYE sips:alice@93.12.40.105:20565;transport=ws SIP/2.0Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001Baz Castillo, et al. Expires March 16, 2012 [Page 17]Internet-Draft SIP over WebSocket September 2011 Route: <sip:100.100.100.100;transport=udp>,<sips:100.100.100.100:9090;transport=ws>From: sip:carol@;tag=bmqkjhsdTo: sip:alice@;tag=asdyka899Call-ID: asidkj3ssCSeq: 1201 BYEMax-Forwards: 70F9 BYE SIP Proxy -> Alice (transport WSS)BYE sips:alice@93.12.40.105:20565;transport=ws SIP/2.0Via: SIP/2.0/WSS 100.100.100.100:9090;branch=z9hG4bKmma01m3r5Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001From: sip:carol@;tag=bmqkjhsdTo: sip:alice@;tag=asdyka899Call-ID: asidkj3ssCSeq: 1201 BYEMax-Forwards: 69F10 200 OK Alice -> SIP Proxy (transport WSS)SIP/2.0 200 OKVia: SIP/2.0/WSS 100.100.100.100:9090;branch=z9hG4bKmma01m3r5Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001From: sip:carol@;tag=bmqkjhsdTo: sip:alice@;tag=asdyka899Call-ID: asidkj3ssCSeq: 1201 BYEF11 200 OK SIP Proxy -> Carol (transport UDP)SIP/2.0 200 OKVia: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001From: sip:carol@;tag=bmqkjhsdTo: sip:alice@;tag=asdyka899Call-ID: asidkj3ssCSeq: 1201 BYE9.3. INVITE dialog through two proxiesBaz Castillo, et al. Expires March 16, 2012 [Page 18]Internet-Draft SIP over WebSocket September 2011 Alice (SIP WS) Proxy 1 (SIP UDP) Proxy 2 (SIP WSS) Bob | | | ||INVITE F1 | | ||-------------------->| | ||100 Trying F2 | | ||<--------------------| | || |INVITE F3 | || |-------------------->| || |100 Trying F4 | || |<--------------------| || | |INVITE F5 || | |-------------------->|| | |486 Busy Here F6 || | |<--------------------|| | |ACK F7 || | |-------------------->|| |486 Busy Here F8 | || |<--------------------| || |ACK F9 | || |-------------------->| ||486 Busy Here F10 | | ||<--------------------| | ||ACK F11 | | ||-------------------->| | || | | |Alice and Bob are WebSocket clients running on web browsers. Alicebelongs to SIP domain while Bob does to . Each domain has its own SIP proxy. Both proxies are also WebSocketservers. Alice calls Bob’s AoR through a WebSocket connection. Bob responds the INVITE with a 486 Busy Here. Communication throughproxies is made via UDP transport protocol.Message details (authentication and SDP bodies are omitted forsimplicity):F1 INVITE Alice -> Proxy 1 (transport WS)INVITE sip:bob@ SIP/2.0Via: SIP/2.0/WS 93.12.40.105:21324;branch=z9hG4bKmmuuqFrom: Alice <sip:alice@>;tag=lxtyrTo: Bob <sip:bob@>Call-ID: aslke3dkjCSeq: 1 INVITEMax-Forwards: 70Contact: <sip:alice@93.12.40.105:21324;transport=ws>Baz Castillo, et al. Expires March 16, 2012 [Page 19]。
WebSocket协议介绍
Client端要求
Client发起连接：
根据/Host/和/Port/打开TCP连接，如果/Secure flag/为true，则在TCP连接建立后，进行TLS连接建 立过程；
发送WebSocket HTTP Request：
参考RFC2616构造合法的HTTP Get Request：Request方法必须是Get，Version至少是HTTP1.1； Request-URI必须是/Resource Name/或者是由/Host/、/Port/、/Resource Name/组成的HTTP/s绝对路径；
Server端要求
建立Websocket协议信息 /subprotocol/：根据Request中的|Sec-WebSocket-Protocol|头域，结合Server侧实 际支持情况，选择本次连接使用的的子协议；如果Request未携带|Sec-WebSocketProtocol|头域或者Server不同意使用任意一个，则设置为null，返回Client时不携带 该头域，表示Server不同意Client指示的子协议； /extensions/：根据Request中的|Sec-WebSocket-Extensions|，结合Server侧对子 协议的实际支持情况，生成扩展集合，集合可能为null；
HTTP header中必须包含|Host|头域，由/Host/加可选的:/Port/组成； HTTP header中必须包含|Upgrade|头域，取值必须是”websocket”； HTTP header中必须包含|Connection|头域，取值必须是”Upgrade”； HTTP header中必须包含|Sec-WebSocket-Key|头域，该值为Client选择的16Byte随机数的Base64编码值； HTTP header中必须包含|Sec-WebSocket-Version|头域，取值13 HTTP header中可选包含|Sec-WebSocket-Protocol|头域，指示Client期望协商的由逗号分隔的一个或多个
SIP协议错误代码大全
1)100 Trying 之杨若古兰创作说明caller正在呼叫，但还没联系上callee. 180 Ringing 说明callee曾经被联系上,callee的铃正在响.收到这个信息后，等待200 OK2)181 Call is being forwarded说明call被从头路由到另外一个目的地3)182 Queued说明callee当前是不成获得的，但是对方不想直接拒绝呼叫，而是选择放在呼叫队列中4)183 Session progress用来警告caller频段(inband)错误.当从PSTN收到一个ISDN 动静，SIP gateway 发生183 Session progress .2xx successful Responses200 OK3xx Redirection Responses5)300 Multiple choices说明呼叫的地址被解析成多个地址，所有的地址都被提供出来，用户或用户代理可以从当选择联系哪个.6)301 Moved permanently说明指定地址的用户曾经永久不成用，在头中曾经用另外一个地址替换了.7)302 Moved temporarily说明指定地址的用户临时不成用，在头中曾经用另外一个地址代替了.8)305 Use proxy说明caller必须用一个proxy来联系callee.9)380 Alternative service说明call不成功，但是可选择其他的服务4xx Request Failure Responses10)400 Bad Request说明因为非法格式，请求不克不及被理解.11)401 Unauthorized说明请求须要用户认证.12)402 Payment required说明完成会话须要付费.13)403 Forbidden说明server曾经收到并能理解请求但不提供服务.14)404 Not Found说明server有明确的信息在指定的域顶用户不存在.15)405 Method Not Allowed说明请求中指定的方法是不被答应的.将返回一个答应的方法列表.16)406 Not Acceptable说明被请求的资本只对某些特殊的请求作出呼应，对目前头(header)中指定的请求不接受.17)407 Proxy authentication required和401 Unauthorized response类似.但是，它说明client必须首先在proxy上认证本人.18)408 Request timeout说明在timeout时间过期前，server不克不及发生呼应.19)409 Conflict说明因为和当前资本形态发生冲突，请求不克不及被处理.20)410 Gone说明请求资本在server上永久不成用，也没有转发的地址.21)411 Length required说明用户拒绝接受没有定义content长度的请求.22) 413 Request entity too large说明server拒绝处理请求，因为它太大，超出了server能处理的大小.23)414 RequestURI too long说明server拒绝处理请求，因为请求的URI太长，server不克不及解释它.24)415 Unsupported media说明server拒绝处理请求，因为body格式不被目的终端撑持25)420 Bad extension说明server不克不及理解在header中指出的扩展和谈.26)480 Temporarily unavailable说明callee曾经被联系上，但是临时不成用.27)481 Call leg/transaction does not exist说明server正在忽略请求，因为它是一个没有匹配legID的BYE或者是一个没有匹配事务的CANCEL.28)482 Loop detected说明server收到了一个包含它本人路径的请求.29)483 Too many hops说明server收到了一个请求，它须要的hop数超出了在header中答应的最大hop数.30)484 Address incomplete说明server收到一个地址不完好的请求.31)485 Ambiguous说明server收到一个请求，其中callee的地址是不明确的，也没有可能备用的地址供选择.32)486 Busy here说明callee曾经被联系上，但是它们的零碎不克不及承受额外的call.488（临时不克不及进行）.5xx Server Failure Responses33)500 Server internal error说明server或gateway发生不测错误从而不克不及处理请求.34)501 Not implemented说明server或gateway不撑持完成请求所需的功能.35)502 Bad gateway说明server或gateway从下流server收到一个非法呼应.36)503 Service unavailable说明因为超负载或保护成绩，server或gateway不克不及处理请求.37)504 Gateway timeout说明server或gateway没有从另外一个server(如location server)收到一个及时的呼应.38)505 Version not supported说明server或gateway不撑持在请求顶用到的SIP版本.6xx Global Responses39)600 Busy everywhere说明callee曾经被联系上，但是处于忙形态中，在这个时间不克不及接受call.40)603 Decline说明callee曾经被联系上，但是不克不及或不想加入call. 41)604 Does not exist anywhere说明server有正式的信息说明callee不存在于收集中.42)606 Not acceptable说明callee曾经被联系上，但是session描述的某些方面不被接受.。
Sip响应状态码对照详解
Sip响应状态码对照详解SIP应答消息状态码与功能类型状态码状态说明临时应答(1XX) 100 Trying 正在处理中180 Ringing 振铃181 call being forwarder 呼叫正在前向182 queue 排队181* session progress 会话进⾏会话成功(2XX) 200 OK 会话成功重定向(3XX) 300 multiple 多重选择301 moved permanently 永久移动302 moved temporaily 临时移动305 use proxy ⽤户代理380 alternative service 替代服务请求失败(4XX) 400 bad request 错误请求401unauthorized 未授权402 payment required 付费要求403 forbidden 禁⽌404 not found 未发现405 method no allowed ⽅法不允许406 not acceptable 不可接受407 proxy authentication required 代理需要认证408 request timeout 请求超时410 gone 离开413 request entity too large 请求实体太⼤414 request-url too long 请求URL太长415 unsupported media type 不⽀持的媒体类型416 unsupported url scheme 不⽀持的URL计划420 bad extension 不良扩展421 extension required 需要扩展423 interval too brief 间隔太短480 temporarily unavailable 临时失效481 call/transaction does not exist 呼叫/事务不存在482 loop detected 发现环路483 too many hops 跳数太多484 address incomplete 地址不完整485 ambiguous 不明朗486 busy here 这⾥忙487 request terminated 请求终⽌488 not acceptable here 这⾥请求不可接受491 request pending 未决请求493 undecipherable 不可辨识服务器失败(5XX) 500 server internal error 服务器内部错误501 not implemented 不可执⾏502 bad gateway 坏⽹关503 service unavailable 服务⽆效504 server time-out 服务器超时505 version not supported 版本不⽀持513 message too large 消息太⼤全局性错误(6XX) 600 busy everywhere 全忙603 decline 丢弃604 does not exist anywhere 不存在606 not acceptable 不可接受SIP应答代码(以下是详细内容)应答码是包含了，并且扩展了HTTP/1.1应答码。
rfc6238标准
RFC 6238（The WebSocket Protocol）是一项互联网标准，它定义了WebSocket 协议，用于在单个TCP 连接上进行全双工通信。
WebSocket 是一种网络通信协议，允许服务器和客户端之间进行实时双向通信，广泛应用于实时Web 应用、在线游戏、聊天应用等领域。
RFC 6238 主要包括以下内容：
1. 协议概述：介绍了WebSocket 协议的基本原理和目标，以及与HTTP 协议的区别。
2. 通信模式：定义了WebSocket 通信的基本模式，包括服务器到客户端（SOCKS）和客户端到服务器（CSOCKS）两种模式。
3. 消息格式：详细说明了WebSocket 消息的格式，包括起始握手、文本消息、二进制消息等。
4. 握手过程：定义了WebSocket 连接的建立过程，包括客户端发起握手、服务器响应握手和连接建立等。
5. 升级过程：介绍了如何将HTTP 连接升级为WebSocket 连接。
6. 安全性：简要介绍了WebSocket 的安全性，建议使用HTTPS 进行加密通信。
7. 异常处理：说明了如何处理WebSocket 通信过程中的异常情况，如连接断开、超时等。
8. 示例：提供了几个WebSocket 应用的示例，包括简单的文本聊天应用、二进制数据传输等。
RFC 6238 与其他WebSocket 相关标准（如RFC 6455、RFC 7988 等）共同为WebSocket 技术的实现和部署提供了规范。
遵循这些标准，开发人员可以构建稳定、安全的WebSocket 应用程序，提供实时双向通信功能。
sip 堆叠方式
sip 堆叠方式【最新版】目录1.SIP 的含义2.SIP 的堆叠方式3.SIP 堆叠方式的优点4.SIP 堆叠方式的缺点5.SIP 堆叠方式的应用正文1.SIP 的含义SIP（Session Initiation Protocol，会话初始化协议）是一种用于实现实时通信的应用层控制协议，主要用于创建、修改和释放一个或多个参与者之间的会话。
在网络通信中，SIP 起到了一个召集会议的作用，让参与者之间可以进行语音、视频等多媒体通信。
2.SIP 的堆叠方式SIP 堆叠方式是指在 SIP 协议中，如何将多个会话协议层叠起来，以实现对多个会话的控制和管理。
SIP 堆叠方式主要有以下两种：（1）单一堆叠：在一个会话中，只有一个 SIP 协议栈。
这种方式适用于简单的一对一或一对多通信场景。
（2）多层堆叠：在一个会话中，有多个 SIP 协议栈相互堆叠。
这种方式适用于复杂的多对多通信场景，例如视频会议、群聊等。
3.SIP 堆叠方式的优点（1）灵活性：SIP 堆叠方式可以根据不同的通信场景进行调整，满足多种通信需求。
（2）可扩展性：通过多层堆叠，可以实现大规模的实时通信，支持大量用户同时进行会话。
（3）稳定性：SIP 协议本身具有很好的容错性，即使在网络环境较差的情况下，也能保证会话的稳定性。
4.SIP 堆叠方式的缺点（1）资源消耗：多层堆叠会增加计算机的资源消耗，例如内存、CPU 等。
（2）安全性：由于 SIP 协议本身不提供加密功能，因此在一些对安全性要求较高的场景中，需要采用其他加密手段来保护通信内容。
5.SIP 堆叠方式的应用SIP 堆叠方式广泛应用于实时通信领域，如网络电话、视频会议、在线直播等。
SIP协议配置
目录第3章语音业务配置.......................................................................3-13.1 SIP介绍.............................................................................3-13.2 数据配置步骤......................................................................3-23.2.1 配置设备IP地址......................................................3-43.2.2 配置SIP服务器.......................................................3-43.2.3 配置用户..................................................................3-63.2.4 配置用户数图...........................................................3-73.2.5 配置SIP信令端口号................................................3-83.3 语音业务配置举例..............................................................3-93.3.1 配置准备..................................................................3-93.3.2 配置语音业务.........................................................3-10第3章语音业务配置IAD132E(T)支持基于SIP（Session Initiation Protocol）协议的语音业务。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Baz Castillo, et al.
Standards Track
[Page ransport for SIP
January 2014
Table of Contents 1. 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 4. The WebSocket SIP Subprotocol . . . . . . . . . . . . . . . . 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5.1. Via Transport Parameter . . . . . . . . . . . . . . . . . 5.2. SIP URI Transport Parameter . . . . . . . . . . . . . . . 5.3. Via "received" Parameter . . . . . . . . . . . . . . . . 5.4. SIP Transport Implementation Requirements . . . . . . . . 5.5. Locating a SIP Server . . . . . . . . . . . . . . . . . . 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 9.2. Usage of "sips" Scheme . . . . . . . . . . . . . . . . . 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10.1. Registration of the WebSocket SIP Subprotocol . . . . . 10.2. Registration of New NAPTR Service Field Values . . . . . 10.3. SIP/SIPS URI Parameters Subregistry . . . . . . . . . . 10.4. Header Fields Subregistry . . . . . . . . . . . . . . . 10.5. Header Field Parameters and Parameter Values Subregistry 10.6. SIP Transport Subregistry . . . . . . . . . . . . . . . 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12.1. Normative References . . . . . . . . . . . . . . . . . . 12.2. Informative References . . . . . . . . . . . . . . . . . Appendix A. Authentication Use Cases . . . . . . . . . . . . . . A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . A.2. Just Web Authentication . . . . . . . . . . . . . . . . . A.3. Cookie-Based Authentication . . . . . . . . . . . . . . . Appendix B. Implementation Guidelines . . . . . . . . . . . . . B.1. SIP WebSocket Client Considerations . . . . . . . . . . . B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 3 3 3 3 4 4 5 6 6 6 7 7 8 8 8 10 10 12 16 16 16 16 16 17 17 17 17 18 18 18 18 19 21 21 21 22 22 23 24
Baz Castillo, et al.
Standards Track
[Page 2]
RFC 7118
WebSocket as a Transport for SIP
January 2014
1.
Introduction The WebSocket protocol [RFC6455] enables message exchange between clients and servers on top of a persistent TCP connection (optionally secured with Transport Layer Security (TLS) [RFC5246]). The initial protocol handshake makes use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure. Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. The specification in this document enables use of SIP in these scenarios. This specification defines a WebSocket subprotocol (as defined in Section 1.9 of [RFC6455]) for transporting SIP messages between a WebSocket client and server, a reliable and message-boundarypreserving transport for SIP, and DNS Naming Authority Pointer (NAPTR) [RFC3403] service values and procedures for SIP entities implementing the WebSocket transport. Media transport is out of the scope of this document. Section 3 in this specification relaxes the requirement in [RFC3261] by which the SIP server transport MUST add a "received" parameter in the top Via header in certain circumstances.
The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) Abstract The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at /info/rfc7118. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.