SIP

简介 这里我们把ACK的场景限定到INVITE收到200响应之后，UAC构造ACK消息的URI来自哪里？ 这里的时序图为 sequenceDiagram uac ->> uas: INVITE uas ->> uac: 200 uac ->> uas: ACK 我们要把这个问题讲清楚，不要臆造，并且必须提供RFC3261的原文作为参考。 RFC3261解读 📌 13.2.2.4 The UAC core MUST generate an ACK request for each 2xx received from the transaction layer ✏️ 这里说明，在UAC收到INVITE 200 OK后，必须回复ACK消息。 📌 12.2.1.1 Generating the Request The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. ...

天下苦 VOS 久矣。 此言非怒而发，乃久用之后，积怨成理也。 VOS3x、VOS5x，曾有其功。 当年软交换荒芜，SIP 规范未成体系，工程师多凭经验行事。VOS 以一套封装良好的系统，解“能跑”之急，立一时之功，不可不认。 然功成之后，不思进化； 市占既稳，便少革新。 天下之患，莫大于此。 一、垄断既久，问题反成常态 今之 VOS，已非“可选方案”，而成“默认答案”。 选型之时，不问架构，只问“是不是 VOS”； 排障之时，不查协议，只等“厂商回复”。 于是，奇景频出： SIP 行为异于 RFC，而曰“产品设计如此” 性能瓶颈不可测，而曰“经验上差不多” 复杂需求难以实现，而曰“VOS 不支持” 简单需求可实现，而曰“得加钱” 故障定位止于日志，而曰“已提交工单” 久而久之， 问题不再被解决， 只是被习惯。 二、用 VOS，工程师何其卑微 用 VOS 者，常有此感： 系统在跑， 却不知为何如此跑； 问题已现， 却不知从何而断。 工程师所做者，不过： 点配置 调参数 猜行为 等回复 软交换本该是工程， 却活成了玄学。 三、OpenSIPS / Kamailio：让系统“讲人话” 或问： “不用 VOS，又当用谁？” 曰：OpenSIPS，Kamailio。 二者之道，不在“省钱”，而在透明： SIP 即 SIP，不自创私货 路由即代码，行为白纸黑字 性能可压测，瓶颈可定位 出问题先看脚本，而非先写邮件 在此体系之中， 系统不再“猜你想要什么”， 而是“严格执行你所写之逻辑”。 这是工程， 不是占卜。 四、开源之苦，在前；开源之利，在后 诚然，OpenSIPS / Kamailio 不好上手。 学习曲线陡峭，踩坑在所难免。 ...

TL;DR 攻击者伪造DTLS ClientHello消息，在SIP服务器和客户端之间建立一个非预期的连接。导致正常链接被阻断。 影响软件 FreeSWITCH RTPengine asterisk FreePBX 漏洞白皮书 webrtc-hello-race-conditions-paper 表现 应答后呼叫无声 参考 https://github.com/EnableSecurity/advisories/tree/master/ES2023-03-rtpengine-dtls-hello-race https://github.com/EnableSecurity/advisories/tree/master/ES2023-02-freeswitch-dtls-hello-race https://github.com/EnableSecurity/advisories/tree/master/ES2023-03-rtpengine-dtls-hello-race

0 阅前须知 本文并不是教程，只是实现方案 我只是从WEB端考虑这个问题，实际还需要后端sip服务器的配合 jsSIP有个非常不错的在线demo, 可以去哪里玩耍，很好玩呢 try jssip 1. 技术简介 WebRTC: WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准 SIP: 会话发起协议（Session Initiation Protocol，缩写SIP）是一个由IETF MMUSIC工作组开发的协议，作为标准被提议用于创建，修改和终止包括视频，语音，即时通信，在线游戏和虚拟现实等多种多媒体元素在内的交互式用户会话。2000年11月，SIP被正式批准成为3GPP信号协议之一，并成为IMS体系结构的一个永久单元。SIP与H.323一样，是用于VoIP最主要的信令协议之一。 一般来说，要么使用实体话机，要么在系统上安装基于sip的客户端程序。实体话机硬件成本高，基于sip的客户端往往兼容性差，无法跨平台，易被杀毒软件查杀。 而WebRTC或许是更好的解决方案，只要一个浏览器就可以实时语音视频通话，这是很不错的解决方案。WebSocket可以用来传递sip信令，而WebRTC用来实时传输语音视频流。 2. 前端WebRTC实现方案 其实我们不需要去自己处理WebRTC的相关方法，或者去处理视频或者媒体流。市面上已经有不错的模块可供选择。 2.1 jsSIP jsSIP是JavaScript SIP 库 功能特点如下： 可以在浏览器或者Nodejs中运行 使用WebSocket传递SIP协议 视频音频实时消息使用WebRTC 非常轻量 100%纯JavaScript 使用简单并且具有强大的Api 服务端支持 OverSIP, Kamailio, Asterisk, OfficeSIP，reSIProcate，Frafos ABC SBC，TekSIP 是RFC 7118 and OverSIP的作者写的 下面是使用JsSIP打电话的例子，非常简单吧 // Create our JsSIP instance and run it: var socket = new JsSIP.WebSocketInterface('wss://sip.myhost.com'); var configuration = { sockets : [ socket ], uri : 'sip:alice@example.com', password : 'superpassword' }; var ua = new JsSIP.UA(configuration); ua.start(); // Register callbacks to desired call events var eventHandlers = { 'progress': function(e) { console.log('call is in progress'); }, 'failed': function(e) { console.log('call failed with cause: '+ e.data.cause); }, 'ended': function(e) { console.log('call ended with cause: '+ e.data.cause); }, 'confirmed': function(e) { console.log('call confirmed'); } }; var options = { 'eventHandlers' : eventHandlers, 'mediaConstraints' : { 'audio': true, 'video': true } }; var session = ua.call('sip:bob@example.com', options); 2.2 SIP.js sip.js项目实际是fork自jsSIP的，这里主要介绍它的服务端支持情况。其他接口自己自行查阅 ...