最新 | 最热门 | 最高评价

+0  基于 TCP UDP 协议的实时流媒体的实时性分析

Tag: 网络编程 | RTP | VoIP
ideawu 发于 2017年06月19日 20:31 | 点击: 1051 | 展开摘要
直播,电话通话,视频聊天都是实时流媒体的范畴。无论使用 TCP 还是 UDP,都会有延时。有个过时的观点是 UDP 更实时,但我不认为是这样。

实时流媒体的延时主要有几个因素:发送方缓冲,接收方缓冲,网络延时。缓冲包括网络缓冲,录制缓和冲播放缓冲。假设发送方缓冲是 10ms,接收方缓冲都是 50ms,网络延时是 100ms,那么就有至少 160ms 的播放延时。接收方缓冲比发送方多,是为了解决所谓的 jitter,网络延时不均匀导致的播放断续。

如果使用 UDP,如果丢包

查看全文: http://www.udpwork.com/item/16311.html

+0  SIP INVITE 会话建立过程

Tag: 网络编程 | SIP | VoIP
ideawu 发于 2017年06月19日 19:05 | 点击: 839 | 展开摘要
运行于 UDP 之上的 SIP,因为 UDP 是不可靠传输的,所以 SIP 协议本身要自己实现可靠传输。对于如何可靠传输,SIP 的 RFC 文档没有要求实现独立的传输层,而是将可靠传输隐含于交互过程本身。如果像 TCP/IP 协议那样分层,特点是清晰。而将可靠传输隐含于交互,则可控程度更高,当然也更复杂。

所以,RFC 中创造了一些概念,如 Transaction 等等,对于有经验的程序员来说,这完全没必须,反而造成困扰。对于程序员,用几句简单的过程描述就可以解决。如下。

查看全文: http://www.udpwork.com/item/16309.html

+0  自建一个电话呼叫中心要多少钱?

Tag: IT技术和评论 | SIP | VoIP
ideawu 发于 2017年06月18日 00:46 | 点击: 1440 | 展开摘要
我十分看不惯任何行业的潜规则行为。自建一个电话呼叫中心的报价是多少钱?没有人敢公开报价。我明说吧,自建一个电话呼叫中心,只需要3万元左右,而且还能更省钱。

这个报价是针对小型企业的,也就是广大人民群众。至于大型企业,它们自己去定制,钱不是问题。

3万元建一个电话呼叫中心,包括什么?包括硬件设备,软件。软件是硬件设备上免费赠送的,不要钱!有了这个呼叫中心,你可以有语音导航功能(也就是按0转人工客服),还有人工客服排队,电话录音。够用了,中小企业没那么多花哨的需求。

其它的

查看全文: http://www.udpwork.com/item/16306.html

+0  SIP tag 和 Call-ID 的区别

Tag: 网络编程 | SIP | VoIP
ideawu 发于 2017年06月16日 19:29 | 点击: 765 | 展开摘要
SIP 的一次通话,可以通过 From, To, Call-ID 三元组来区分。但是,为什么 From 和 To 不用固定的地址,而要在地址后面加上 tag=随机数 呢?

tag 的目的是为了解决自己给自己打电话的问题(Hairpinning)。如果你自己给自己打电话,那么你应该有两个 Session,但是,如果 From 和 To 是固定的,你就无法区别这两个 Session 哪个是 caller 哪个是 callee。发送 INVITE 时,caller 会在 From

查看全文: http://www.udpwork.com/item/16305.html

+0  SIP报文Via和Contact的区别

Tag: 网络编程 | SIP | VoIP
ideawu 发于 2017年06月16日 18:54 | 点击: 3605 | 展开摘要
Via 是网络层的信息,SIP 报文将通过网络层发往这两个地址。Contact 是业务上的地址。那么问题是,应该发往哪个?

正确的做法是,请求响应模式中的响应发往 Via。如果解析 DNS 之后能直连 Contact,那么之后的报文(无论是否是请求响应模式)发往 Contact。

请求如果经过多个代理,每个代理都增加自己的 Via,变成 Via 列表。最终节点回复响应时,带有全部 Via 列表,根据最后一个 Via 获知要发送的目的网络地址。每个代理转发响应时,把最后一个

查看全文: http://www.udpwork.com/item/16304.html

+0  音频编码的一些笔记

Tag: Computer System | IT技术和评论 | RTP | SIP | VoIP
ideawu 发于 2017年06月15日 14:59 | 点击: 921 | 展开摘要
名词解释

采样率/Sampling Rate/Sampling Frequency: 表示原始音频,每秒需要多少个值来表示(1秒时间内采样多少次)。

采样位数/Sampling Bit Depth/bits per sample(bps): 用多少比特来存储一个采样值。

采样比特率/Sampling Bit Rate: 指原始音频每秒需要多少比特来表示,显然等于 Rate x Bits。

帧长/Frame Duration/Frame Lenght: 表示每帧(数据块

查看全文: http://www.udpwork.com/item/16301.html

+0  WebRTC C/C++ API 示例代码 – 播放和录音

Tag: C语言编程 | GIPS | VoIP | WebRTC | 视频聊天 | 语音引擎 | 语音聊天
ideawu 发于 2013年08月10日 00:28 | 点击: 2770 | 展开摘要
WebRTC 的音频引擎封装了音频设备的统一接口, 使用者不用关心代码是 Windows, Mac OS X, Linux , iOS 或者 Android 等平台. 这也是一件非常棒的事情, 这个封装如果抽取出来, 就是一个优秀的跨平台音频接口(Audio API).

这里提供一个示例, 讲解如何使用 WebRTC 的 C/C++ API 进行录音和播放声音. 首先, 引入头文件:

#include "webrtc/modules/audio_device/includ

查看全文: http://www.udpwork.com/item/10362.html

+0  WebRTC源码架构浅析

Tag: C语言编程 | P2P/Network | GIPS | VoIP | WebRTC | 视频聊天 | 语音引擎 | 语音聊天
ideawu 发于 2013年08月05日 00:24 | 点击: 3646 | 展开摘要
Google 在2010年花了6千8百万美元收购了大名鼎鼎的 Global IP Sound/Solutions (GIPS) 公司, 得到了它的 VoIP 相关技术的专利和软件. 第二年, Google就把这些软件开源了, 不过, 不是作为独立的软件, 而且也和原来的软件功能大不一样, 而是作为所谓的 WebRTC 方案的一部分.

GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web

查看全文: http://www.udpwork.com/item/10341.html

+0  给互联网圈子的朋友们介绍下运营商网络

Tag: 读后感 | VoIP | 电信网络 | 移动网
gnawux 发于 2013年04月12日 09:39 | 点击: 1397 | 展开摘要
按:事情从“微信收费”一说起来的,看到Shell发了一篇blog,深感电信和互联网两个领域互相不知根知底啊,作为前兼职3G讲师,来简单介绍一点吧。首先,这篇blog和微信一事的关系仅限于此段,我个人认为这纯粹是某公司的炒作,看了移动的宁宇的博客,我更确信这一判断;其次,这篇文章不涉及所有运营商网络,运营商网络各有不同,我主要说说我更熟悉的移动网领域,尤其是 GSM/GPRS/EDGE/WCDMA(部分地包含TD),如果没有特殊说明,不包含固话网和CDMA/CDMA2000。嗯

查看全文: http://www.udpwork.com/item/9659.html
|<<<1>>>| 一共1页, 9条记录