WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档

P2P网络技术-NAT的由来、类型以及优缺点

2019-12-06 13:54:29

本文将讲述WebRTC中使用的P2P技术,重点讲解NAT的由来、类型及优缺点。

##一、 IPV4协议和NAT的由来 IPv4即网际网协议第4版——Internet Protocol Version 4的缩写。IPv4定义了一个跨越异种网络互连的超级网,并为每个网际网的节点分配全球唯一的IP地址。如果把Internet比作一个邮政系统,那么IP地址的作用就等同于包含国家、城市、街区、门牌编号在内的完整地址。IP地址使用32bits整数表达一个地址,地址最大范围是2的32次方,约为43亿。在IP创始时期可被联网的设备来看,这样的一个空间很大,很难被短时间用完。然而,事实远远超出人们的设想,计算机网络在此后几十年迅速壮大,网络中断数量呈爆炸性增长。

更糟糕的是,为了路由和管理方便,43亿地址空间按照不同前缀长度分为A、B、C、D四类网络地址和保留地址。其中,A类网络地址127段,每段包括主机地址约1678万个。B类网络地址16384端,每段包括65536个主机地址。 IPv4网络地址划分 IP地址管理机构IANA向超大型企业/组织分配A类网络地址,一次一段。向中型企业或者教育机构分配B类网络地址,一次一段。这种分配策略使得IP地址浪费极为严重,很多被分配的地址并未被真实利用,地址消耗很快。二十世纪90年代初,网络专家们意识到这样分配下去,IPv4地址很快就会耗光。于是人们开始考虑IPv4的替代方案,并采取一系列措施减缓IPv4的消耗。在这种背景下,NAT(网络地址转换)应运而生。

NAT是一项神奇的技术,它的出现几乎使IPv4起死回生。在IPv4已经被认为行将结束历史使命之后近20年时间里,人们几乎忘了IPv4的地址空间即将耗尽这样一个事实。更不用说,在NAT产生以后,网络终端的数量呈加速上升趋势,对IP地址的需求剧烈增加。此足见NAT技术之成功,影响之深远。

 

More...

WebRTC中的RTP、SRTP、RTCP协议

2019-12-06 13:53:41

本文将讲述WebRTC中RTP、SRTP、RTCP协议。本文内容来自于超越RFC3550 - RTP/RTCP协议族分析

##一、前言 RF3550定义了实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对实时流媒体传输的基础协议,该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输,并不能提供可靠传输、流量控制和拥塞控制等服务质量保证,这需要RTCP协议提供这些服务。

RTCP协议负责流媒体的传输质量保证,提供流量控制和拥塞控制等服务。在RTP会话期间,各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息,参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用,通过有效反馈使使流媒体传输效率最佳化。

IETF的RFC3550定义了RTP/RTCP协议的基本内容,包括报文格式、传输规则等。除此之外,IETF还定义一系列扩展协议,包括RTP扩展,RTCP报文类型扩展,等等。本文对这些协议进行初步归纳总结,在分析RFC3550的基础上,�重点分析RTP系列协议,并以报文类型为主线分析RTCP系列协议。

 

More...

SDP协议详解

2019-12-06 13:52:45

本文将介绍WebRTC中的SDP协议,实际上SDP协议并不属于WebRTC专有协议。

一、SDP简述

ICE信息的描述格式通常采用标准的SDP,其全称为Session Description Protocol,即会话描述协议。SDP只是一种信息格式的描述标准,不属于传输协议,但是可以被其他传输协议用来交换必要的信息,如会话通知协议(SAP)、会话初始协议(SIP)、实时流协议(RTSP)、MIME 扩展协议的电子邮件以及超文本传输协议(HTTP)等。SDP协议是基于文本的协议,协议的可扩展性比较强,其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商,所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。

流媒体协议sdp信息,附带在describe报文中有rtsp服务端发出,主要目的,告之会话的存在和给出参与该会话所必须的信息,sdp会话完全是文本形式,采用UTF-8编码的ISO 10646字符集。

图1-SDP协议例子 SDP格式概览 图2-SDP协议例子续 SDP格式概览

sdp描叙符包括:

  • 会话名和目的
  • 会话激活的时间区段
  • 构成会话的媒体
  • 接收这些媒体所需要的信息(地址,端口,格式)
  • 会话所用的带宽信息
  • 会话拥有者的联系信息
 

More...

无需翻墙的 WebRTC 源码下载

2019-12-06 13:48:05

关于 WebRTC 的源码下载和 Demo 的编译运行,WebRTC 的官方文档已经有非常详细的说明。以 Linux 为例,过程大概是这样的:

  1. 下载并安装 depot_tools。这是 WebRTC 的代码下载及编译工具集,下载即是把源码 clone 下来,所谓安装只是把 depot_tools 的目录路径放进系统的环境变量 PATH 中即可。
  2. 准备目录

    1
    2
    $ mkdir webrtc
    $ cd webrtc
  3. 下载代码

    1
    2
    $ fetch --nohooks webrtc
    $ gclient sync
  4. 安装依赖。

  5. 编译运行。

安装依赖和编译运行具体可以参考 WebRTC 的官方文档。

 

More...

webrtc所有平台下载编译步骤详细说明

2019-12-06 13:47:20

1、安装depot tools

Windows:
国外下载:https://storage.googleapis.com/chrome-infra/depot_tools.zip
下载完把压缩包解压,然后把解压目录加入PATH环境变量
Linux(Android)/Mac(IOS):
安装git
国外:git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
国内:git clone https://source.codeaurora.org/quic/lc/chromium/tools/depot_tools
把depot_tools目录加入

PATH:export PATH=`pwd`/depot_tools:"$PATH"
 

More...

基于Licode的WebRTC全球分布式架构

2019-12-05 11:50:52

大家好,我是来自百家云的陈聪,今天我将为大家带来与Licode的WebRTC全球分布式架构相关的技术分享。之所以想为大家介绍这个架构,是因为我在使用WebRTC开源服务器时发现WebRTC并没有提供类似于分布式或集群的整体解决方案,希望百家云在此领域的探索能为大家带来有价值的帮助。

 

1. SFU

 

1.1 SFU简介

 

640?wx_fmt=jpeg

 

More...

Agora SOLO X™:兼容 WebRTC 标准的抗丢包语音编码器

2019-12-05 11:48:57
本文分享了声网Agora 首席音频工匠高泽华在 RTC 2018 实时互联网大会上,以《SOLO X™:兼容 WebRTC 标准的抗丢包语音编码器》为题的演讲。主要介绍了声网推出的抗丢包语音编码器 Agora SOLO™ 的算法特点,以及第二代编解码器 Agora SOLO X™ 的新特性与测试效果。以下为演讲实录。

去年,我们在 RTC 大会上分享了自主研发的抗丢包编解码方案 Agora SOLO™ ,主要是面向抗丢包网络,解决实时通信传输 last mile 的问题。

关于Agora SOLO™

有时,大家对丢包问题会有一些误解。很多人认为随着 4G 的普及和 5G 的建设,是不是丢包问题变得不重要了?我认为并不是这样,因为在现有网络条件下,不论是 server 到 server,还是 sever 到 last mile 都存在着大量的丢包问题。

我们谈到丢包就涉及到丢包的概念,到底什么叫做丢包?其实任何没有按时到达的包都是丢包。如果把一个包的延时拉到足够大,一般来说,我们可以通过无数次重传来解决丢包问题。如果这个包没有在规定的时间到达,都算丢包。而且,丢包也不一定是网络原因导致,有时候是由于系统的调度等原因造成。

举个例子。通常,Android 系统上播放线程、解码线程和收包线程都可以不是一个线程。Android 并不是特别实时的操作系统。一旦系统比较忙的时候,就容易产生收包线程和解码线程的冲突,导致丢包产生。而这种丢包是由于系统产生的。甚至在解码时,解码器完成解码后交给播放器播放,其中的 buffer 也会导致卡顿。

丢包也与带宽限制相关。如果带宽足够大,可以通过无数次重传来实现抗丢包效果。但如果带宽很有限,就不能完全依靠无限制的重传来实现抗丢包效果。

比如说,曾经联通做过这样的事情,流量包月,但每个月的带宽只能在 128kbps,满足你对网页和音视频的基本需求。在这种服务下,如果你开一些高性能或者大码率的信源通讯的时候就会产生带宽拥塞,带宽拥塞首先导致延时增加,下一步就会产生丢包。所以,实际上带宽和丢包也相关。

由于我们声网在全球布网,非洲、东南亚、中东和印度的网络状况与中国的网络状况相差还比较远。即使在中国的网络环境下,上海和偏远地区的网络状况也是不一样的。所以,并不是以后上了 5G 就不存在丢包问题了,相反,我认为随着网络的差异化会导致丢包的问题变得越来越普遍。

 

More...

要做到实时通信的质量监控,有哪些难点?

2019-12-05 11:43:05
本文整理自声网数据平台首席架构师何丰在 RTC 2018 实时互联网大会的演讲内容。他的演讲内容主要包括,如何以数据来衡量实时通信质量,质量透明化背后的数据挑战,以及声网面向开发者免费推出的通信质量诊断分析产品“水晶球”(Agora Analytics)的应用与技术难点。以下为演讲实录。

我们是提供实时音视频服务的。我们希望让开发者们使用实时通信服务,就像使用水、电一样方便。用户的设备接入了我们的云服务后,就可以直接与全球其它国家和地区的用户进行实时的语音或视频互动。

在声网的实时通信云服务上,已经有很多种应用,比如直播与社交,像参加本次大会的 MeetMe 就是美国目前最大的约会社交平台;再比如教育,有很多教育类产品为国内学生与海外老师搭建了实时互动的教学平台;再比如游戏,此前游戏比较流行一起打怪升级,现在很多手游已经集成实时通信的功能,开始变得社交化。在前不久,我们已经开始为小天才儿童手表提供了实时语音、视频的服务,实际上也是 RTC 技术应用于 IoT 领域的一个典型案例。

一、为什么开发者需要实时通信服务的质量监控与质量透明?

 

More...

WebRTC内置debug工具,详细参数解读

2019-12-05 11:42:27

 

More...

如何在Janus中抓取WebRTC流量?

2019-12-05 11:40:35

本文是Janus 项目作者 Lorenzo Miniero撰写的, 2019 年 10 月 25 日他将来到北京 RTC 2019 大会,在「WebRTC Workshop」工作坊中分享WebRTC 服务端开发及 Janus 开发的技巧,并与听众小范围深入交流,名额有限,现在即可报名:2019.rtcexpo.org/(申请限时免费票,还可获得 Workshop 代金券~)

本文摘要:抓取WebRTC流量看起来相对简单,大多数情况下确实是这样:你只需要在其中一人的机器上安装类似tcpdump或wireshark的抓包工具,然后查看产生的文件,大多数情况会是.pcap或.pcapng文件。这些活动对于诊断连接问题或其它与WebRTC相关的问题很有用:实际上,wireshark可以自动检测出STUN,DTLS之类的标准协议,这些是WebRTC PeerConnections所关注的。

本文关键是什么?

抓取WebRTC流量的唯一问题就是,媒体内容会被加密。当检查了STUN连接或DTLS握手之后,这不是一个问题,但是当你想要查看RTP或RTCP包的时候,这将会成为一个问题,它将会被加密成SRTP和SRTCP。实际上,尽管SRTP标题没有被加密,你可以任何形式抓取流量,但是SRTP负载不是,意味着你不能查看它的内容。

大多数情况下你不需要查看内容。正如期待的那样,你依然可以查看加密RTP包的标题,也就是最常被用到的信息。不管怎样,对于RTCP并不能这样说:实际上,一条RTCP信息可能实际上包含不止一个包,并且不存在一个共享的标题。除此之外,查看RTP负载可能会有效。

这意味着抓取加密流量是可行的,但是为了诊断目的抓取无加密数据效果可能更好。不幸的是,无其它帮助下这是不可能的:实际上,WebRTC情况下浏览器经常发送加密数据,即使有一些允许你抓取无加密数据进行测试,但是你还是需要依靠其它工具来获取媒体流,才能进行这项工作。

 

More...

last
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
next
  • 分类目录

    • WebRTC概念与基础 (225)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (12)
    • WebRTC服务端开发 (23)
    • WebRTC网络与通信 (26)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
  • 最新文章

    • 音视频相关的书籍,多媒体技术
    • SFU级联解决方案——Jitsi
    • SFU级联解决方案——Licode
    • Janus源码分析(6)——Streaming分析
    • janus Streaming插件推流指南
    • 流媒体服务器 
    • WebRTC+libwebsockets+Janus的秒开实践
    • 基于WebRTC的直播CDN
    • 不需要SFU实现WebRTC联播实践  
    • webrtc 开启Simulcast功能
    • Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
    • WebRTC源码分析rfc4588 RTP重传有效载荷格式
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • 自研WebRTC网关服务器架构的实践之路
    • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  
    • janus的videoroom插件
    • WebRTC+libwebsockets+Janus的秒开实践
    • Janus源码分析(7)——videoroom分析
    • Janus源码分析(5)——echotest分析
    • Janus源码分析(4)——信令交互过程
    • WebRTC+libwebsockets+Janus的秒开实践
    • 前向纠错码(FEC)的RTP荷载格式
    • WebRTC 开发实践:从一对一通话到多人会议
    • Distord如何使用WebRTC处理250万用户同时进行的音频交流
    • 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
    • 基于WebRTC技术的多人音视频解决方案
    • 谁是最好的WebRTC SFU?
    • WebRTC媒体服务器
    • 使用Janus作为对讲服务器的后台框架和业务流程
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.