呼叫CAPS

原创 已于 2022-03-02 09:59:20 修改 · 2k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux #voip

于 2022-02-21 15:33:51 首次发布

背景

  • 评估SIP Server每秒建立呼叫数量，即CAPS（Call Attempts Per Sercond）。

模型

  • 使用SIPP：1s 20路，通话时长20s，并发100路，共呼叫5000路呼叫。则该模型对应的CAPS：5000除以呼叫持续时间（如下图：5000 / (4 * 60 + 20) ≈ 19.23）
  • ------------------------------ Scenario Screen -------- [1-9]: Change Screen --
  Call-rate(length)   Port   Total-time  Total-calls  Remote-host
20.0(20000 ms)/1.000s   50900    260.71 s         5000  192.168.129.142:50600(UDP)

-------------------------+---------------------------+--------------------------
  Successful call        |        0                  |     5000                 
  Failed call            |        0                  |        0                 
-------------------------+---------------------------+--------------------------
  Call limit reached (-m 5000), 0.000 s period  0 ms scheduler resolution
  0 calls (limit 100)                    Peak was 100 calls, after 5 s
  0 Running, 646 Paused, 0 Woken up
  0 dead call msg (discarded)            0 out-of-call msg (discarded)        
  1 open sockets                        

                                 Messages  Retrans   Timeout   Unexpected-Msg
      INVITE ---------->         5000      0         0                  
         401 <----------         5000      0         0         0        
         ACK ---------->         5000      0                            
      INVITE ---------->         5000      0         0                  
         100 <----------         5000      0         0         0        
         180 <----------         5000      0         0         0        
         183 <----------         0         0         0         0        
         480 <----------         0         0         0         0        
         481 <----------         0         0         0         0        
         488 <----------         0         0         0         0        
         500 <----------         0         0         0         0        
         503 <----------         0         0         0         0        
         200 <----------         5000      0         0         0        
         ACK ---------->         5000      0                            

              [ NOP ]              
       Pause [   5000ms]         5000                          0        
         BYE ---------->         5000      0         0                  
         200 <----------         5000      0         0         0        
------------------------------ Test Terminated --------------------------------


----------------------------- Statistics Screen ------- [1-9]: Change Screen --
  Start Time             | 2022-03-02   09:53:01.808513 1646185981.808513         
  Last Reset Time        | 2022-03-02   09:57:22.531012 1646186242.531012         
  Current Time           | 2022-03-02   09:57:22.531525 1646186242.531525         
-------------------------+---------------------------+--------------------------
  Counter Name           | Periodic value            | Cumulative value
-------------------------+---------------------------+--------------------------
  Elapsed Time           | 00:00:00:000000           | 00:04:20:723000          
  Call Rate              |    0.000 cps              |   19.177 cps             
-------------------------+---------------------------+--------------------------
  Incoming call created  |        0                  |        0                 
  OutGoing call created  |        0                  |     5000                 
  Total Call created     |                           |     5000                 
  Current Call           |        0                  |                          
-------------------------+---------------------------+--------------------------
  Successful call        |        0                  |     5000                 
  Failed call            |        0                  |        0                 
-------------------------+---------------------------+--------------------------
  Call Length            | 00:00:00:000000           | 00:00:05:054000          
------------------------------ Test Terminated --------------------------------

caps、erl、自动机、平均呼叫时长和媒体资源的关
笔者从事电信媒体开发多年，愿意将多年的开发经验分享给同行
12-26 1308
不觉间从事电信软件有12年之久了，其中常见一些术语，刚入门的同事经常问我caps erl 自动机及媒体资源相关的问题。尤其是产品或市场的会问呼叫caps和资源对应关系，以此来确定报价。
全面解析C语言多媒体开源框架GStreamer
dvlinker的技术专栏
07-17 1万+
本文根据此次项目实践，对GStreamer多媒体框架做一个相对全面的总结。
vos3000外呼系统怎样控制呼叫速率（caps） 值
weixi_kelaile520的博客
04-29 2642
需要对客户送达和送给供应商的每秒呼叫次数进行控制 caps：即每秒的呼叫处理能力 例如：caps值为1000ms 速率为100 意思是1秒内允许呼叫的个数为100 例如：caps值为10000ms 速率为10 意思是10秒内允许呼叫的个数是10 VOS设置：在VOS3000“对接/落地网关” < 补充设置 < 其它“勾选”速率限制”并设定呼叫线数和时间周期，速率控制即为caps值的控制如下图设置 备注：该功能仅限VOS3000/VOS5000拥有。 ...
【通信】话务量的计算方法
guansir的专栏
04-13 1万+
1、话务量 话务量反映了电话负荷的大小，与呼叫强度和呼叫保持时间有关。呼叫强度是单位时间内发生的呼叫次数，呼叫保持时间也就是占用时间。 单位时间内的话务量等于使用相同时间单位的呼叫强度与呼叫保持时间之乘积，其单位为爱尔兰（ Erlang）。例如：呼叫强度=1800次/小时，呼叫保持时间=（1/60）小时/次，则话务量=1800次/小时 X （1/60）小时/次=30 Erl。 设：n =
CAPS
记事本
02-07 1481
CAPS (Call Attempts Per Second)每秒建立呼叫数量。 CAPS乘以3600就是BHCA（忙时呼叫量）了。 BHCA是忙时呼叫量的缩写，主要测试内容为：在一小时之内，系统能建立通话连接的绝对数量值。测试结果是一个极端能力的反映，它反映了设备的软件和硬件的综合性能。BHCA值最后体现为CAPS（每秒建立呼叫数量）
tps & caps
mezheng的专栏
04-16 4193
tps 　　每秒事务处理量 - 性能测试的术语介绍 　　TPS(Transaction Per Second) 　　每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。 　　改善：是指从现有的设备、材料、劳动力及产品的制造方法里发现浪费，运用现场的智慧来消除浪费。 　　现场的改善一般式指作业的改善。
okcc呼叫中心的cps高好不好？
OKCC_kelaile520的博客
07-18 522
例如，假设一套语音通信系统的呼叫平均时长为30秒，CPS为300，假设所有的呼叫都被接通，那么这个系统的呼叫并发承载能力将为30×300=9000并发，考虑到并不是所有呼叫都是均匀恒定的发生，在此基础上，系统的最高并发再增加50%都是合理的，那么一个CPS为300的通信系统，表现出来能够达到万线并发。也即，一个CPS为100的系统，即可撑起一套千线并发的电销系统，不同电销场景会有所出入，但总体相差不会太大，这个也与我们实际的实践生产经验相差不大。因此，片面追求CPS性能，并没有特别强的实际意义。...
vos3000外呼系统如何实现 呼叫速率（caps） 值控制
weixi_kelaile520的博客
01-08 776
理解呼叫速率（CAPS）概念 在VOS3000外呼系统中，呼叫速率（CAPS）指的是单位时间内允许发起的呼叫数量。它是衡量外呼系统呼出效率和资源分配的一个重要指标。 通过系统设置调整CAPS值 线路配置方面 线路带宽限制：如果使用的是基于网络的SIP线路等，要考虑线路的带宽。在VOS3000中，可以根据线路的实际带宽能力来设置呼叫速率。例如，一条10Mbps的SIP线路，根据语音编码格式（如G.711编码下每个呼叫大概需要64kbps的带宽），计算出理论上可支持的最大呼叫数量，然后在系统的线路
Jmeter服务器性能压测之—QPS/RPS/TPS/RT/并发数/并发连接数/并发用户数/线程数/吞吐量等概念详解
热门推荐
qq_35603268的博客
11-18 2万+
关于这几个词的概念，在优快云上看了很多文章，解释和计算公式也是五花八门，发现没有一篇解释的既全面又便于理解的，索性参考别人的文章再结合自己的理解，整理一下分享给大家，如有理解错误还望纠正。 先大概介绍下这几个词的概念，再结合jmeter压测数据理解： 一、QPS： Queries Per Second（每秒查询率），每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡...
VB:读取及设定NumLock/CapsLock/ScrollLock的值
miaozk2006的专栏
12-15 1128
若只是要取得这三个按键 (NumLock / 只要呼叫 GetKeyState API 就可以了！若是要设定这三个按键的状态，则要呼叫 GetKeyboardState 及 SetKeyboardState 二个 API！ 程序代码： 　 '在表单的声明区中，加入以下的声明及模组：Private Declare Function GetKeyState Lib "user32" ...
C语言多媒体开源框架GStreamer详解
dvlinker的技术专栏
07-26 548
全面解析C语言多媒体开源框架GStreamer
CAPS & BHCA
weixin_30266829的博客
07-26 1200
定义BHCA：Busy Hour Call Attempts（忙时试呼次数），在一小时之内，系统能建立通话连接的绝对数量值。BHCA为忙时最大试呼次数，与话务量无关。Busy Hour Call Attempts represent the number of times a telephone call is attempted during the busiest hour of the...
vos来控制轮询和计费解决单并发高频呼叫
cibazhanji2176的博客
06-05 2669
无线语音网关，卡槽轮询外呼，主要解决的是由高频呼叫引起的不言而喻的问题。 虽然现在有一些语音网关厂商推出了一些带有轮询功能或者32*128卡槽轮询设备。 但硬件管理功能有一定的局限性。 如何设置，做一个描述： 1，vos中，创建与卡资费相同的费率。 2，创建结算账户，绑定费率。充值给结算账户，充值金额或折算分钟数，与卡的余额一致。 3，单卡槽注册模式，32个卡槽。创建32个落地。每一个落地绑定对应的结算信息。 4，通过vos落地拨打数量统计，落地结算账户余额，调整落地优...
sipp命令 各参数含义
fudacaitao的博客
02-26 1884
sipp -sn uac 172.31.89.4:5060 -r 1 -rp 3000 -inf data.csv -p 7098 -i 172.31.89.242 -s 8001 -sf uac_onecall.xml –m 1000 –l 900 各个参数说明： 172.31.89.4:5060：远端地址和端口（在脚本中用[remote_ip]，[remote_port]引入） -r 1 -rp 3000：每三秒钟发一个呼 -inf data.csv：引入数据配置文件 -p 7098：本地端口（在
使用sipp对FreeSwitch进行测试（Linux环境，会议模式）
castle07的专栏
04-18 5598
一、下载与安装 到http://sourceforge.net/projects/sipp/files/sipp/下载sipp的源码。我下载的是sipp3.2版本。SIPp是用C++写的，因此系统必须支持G++才可成功编译。 SIPp支持四种不同的安装模式： 1) 没有TLS支持与密码验证支持： a) # tar -xvf sipp-1.1rc6.tar.gzb)
QPS/TPS/并发量/系统吞吐量的概念
诚
02-02 7031
  我们在日常工作中经常会听到QPS/TPS这些名词，也会经常被别人问起说你的系统吞吐量有多大。这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数；   QPS: Queries Per Second，每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，...
电信系统常用计算
笔记本+学习园
11-26 2072
电信系统常用计算 Version 1.02008-9-17 处理能力指标   处理能力指标表现为：系统用户数，忙时试呼次数BHCA，每秒呼叫数CAPS，系统容量Capacity，并发呼叫数等；   用户话务模型的描述指标：用户话务量，用户发起呼叫的频度；爱尔兰（Erl），指用户在单位时间里完成的通话时长，1erl指一小时内用户
Sipp工具实现呼叫中心的性能测试
zquAM
08-07 5342
近期要完成一个涉及呼叫的项目，需要支持访客直接联系客服的功能。 对于测试来说，也需要测试呼叫转发的性能，访客直接拨打接入号，由callserver这边添加路由转发到客服这边。 考虑过使用sipp与winsip两个工具，sipp的话可以自己定制流程，winsip的话可能适合配置型，但是也有很多流程可以配置的，由于以前项目也用过sipp来测试sip消息收发，呼叫也确定使用sipp来测试性能，当然，...
channel通道
wang11876的博客
07-03 181
通道是什么，通道就是goroutine之间的通道。它可以让goroutine之间相互通信。每个通道都有与其相关的类型。该类型是通道允许传输的数据类型。(通道的零值为nil。nil通道没有任何用处，因此通道必须使用类似于map和切片的方法来定义。Golang 的 channel 将 goroutine 隔离开，并发编程的时候可以将注意力放在 channel 上。在一定程度上，这个和消息队列的解耦功能还是挺像的。
解释下 行 62397: 03-08 15:04:15.131867 4296 4672 I BluetoothInCallService: BluetoothInCallService = com.android.bluetooth.telephony.BluetoothInCallService@38bdc84 行 62398: 03-08 15:04:15.131962 4296 4672 I BluetoothInCallService: processChld 1 行 62399: 03-08 15:04:15.132103 4296 4672 I BluetoothInCallService: ringingCall hashcode: 177724520 行 62400: 03-08 15:04:15.132338 4296 4672 I BluetoothInCallService: Active: Call [id: TC@42, state: ACTIVE, details: [id: TC@42, state: ACTIVE, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, 1, UserHandle{0}, hdl: tel:18756305546, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_SUPPORTS_VT_LOCAL_RX CAPABILITY_SUPPORTS_VT_LOCAL_TX CAPABILITY_SUPPORTS_VT_LOCAL_BIDIRECTIONAL CAPABILITY_SUPPORTS_VT_REMOTE_RX CAPABILITY_SUPPORTS_VT_REMOTE_TX CAPABILITY_SUPPORTS_VT_REMOTE_BIDIRECTIONAL CAPABILITY_CAN_PAUSE_VIDEO CAPABILITY_REMOTE_PARTY_SUPPORTS_RTT], props: [Properties: PROPERTY_HIGH_DEF_AUDIO]]] Ringing: Call [id: TC@43, state: RINGING, details: [id: TC@43, state: RINGING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, 1, UserHandle{0}, hdl: tel:18136655845, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_RESPOND_VIA_TEXT CAPABILITY_MUTE CAPABILITY_SUPPORTS_VT_LOCAL_RX], props: [Properties:]]] Held: null chld: 1 行 62434: 03-08 15:04:15.136505 26054 26054 D InCall : Call - TelecommCallListener onStateChanged call=Call [id: TC@42, state: DISCONNECTING, details: [id: TC@42, state: DISCONNECTING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, 1, UserHandle{0}, hdl: tel:18756305546, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_SUPPORTS_VT_LOCAL_RX CAPABILITY_SUPPORTS_VT_LOCAL_TX CAPABILITY_SUPPORTS_VT_LOCAL_BIDIRECTIONAL CAPABILITY_SUPPORTS_VT_REMOTE_RX CAPABILITY_SUPPORTS_VT_REMOTE_TX CAPABILITY_SUPPORTS_VT_REMOTE_BIDIRECTIONAL CAPABILITY_CAN_PAUSE_VIDEO CAPABILITY_REMOTE_PARTY_SUPPORTS_RTT], props: [Properties: PROPERTY_HIGH_DEF_AUDIO]]] newState=10 行 62435: 03-08 15:04:15.136588 26054 26054 D InCall : Call - updateFromTelecommCall: Call [id: TC@42, state: DISCONNECTING, details: [id: TC@42, state: DISCONNECTING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, 1, UserHandle{0}, hdl: tel:18756305546, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_SUPPORTS_VT_LOCAL_RX CAPABILITY_SUPPORTS_VT_LOCAL_TX CAPABILITY_SUPPORTS_VT_LOCAL_BIDIRECTIONAL CAPABILITY_SUPPORTS_VT_REMOTE_RX CAPABILITY_SUPPORTS_VT_REMOTE_TX CAPABILITY_SUPPORTS_VT_REMOTE_BIDIRECTIONAL CAPABILITY_CAN_PAUSE_VIDEO CAPABILITY_REMOTE_PARTY_SUPPORTS_RTT], props: [Properties: PROPERTY_HIGH_DEF_AUDIO]]] 行 62436: 03-08 15:04:15.136617 26054 26054 I InCall : Call - setIsAnswering: false 行 62437: 03-08 15:04:15.136634 26054 26054 I InCall : Call - setIsDowngradeVideoCall: false 行 62438: 03-08 15:04:15.136824 26054 26054 D InCall : Call - oldVideoCall: android.telecom.VideoCallImpl@7391459, currentVideocall: android.telecom.VideoCallImpl@7391459 行 62439: 03-08 15:04:15.136849 26054 26054 I InCall : Call - setPlayingVideoCrbt, mVideoCrbtMode:0 mLastVideoCrbtMode:0 行 62440: 03-08 15:04:15.136870 26054 26054 I InCall : InCall - isRelayCall=false, isCallRelayed=false, isOfflineCall=false, mNotifyCallRelayed=false
最新发布
03-15
<think>嗯，用户给了一段Android系统的日志，需要解释里面各行是什么意思。首先，我需要仔细看看这些日志的结构和内容。看起来这些日志涉及蓝牙通话服务和电话状态的变化。 用户提供的日志行有从62397到62440，每行都包含时间戳、进程ID、线程ID、日志级别、标签和具体信息。我需要分步骤分析每一部分。 首先看行62397到62400，这些是来自BluetoothInCallService的日志。BluetoothInCallService可能与蓝牙设备处理来电有关。比如62397行显示服务实例被创建，62398行处理CHLD命令，CHLD是GSM规范中的呼叫保持和多方通话控制命令，参数1可能代表某种操作，比如接听或挂断。然后62399行提到ringingCall的哈希码，可能是指当前响铃的通话实例。62400行详细列出了当前的通话状态，包括活跃通话、响铃通话和保持通话的情况。这里Active状态的电话是TC@42，处于ACTIVE状态，而Ringing的是TC@43，Held为null，说明没有保持中的通话。这可能是用户有来电时，系统处理多个通话的状态。 接下来是行62434到62440，这些来自InCall服务的日志。62434行显示TC@42的状态变为DISCONNECTING，即正在断开连接。这可能是因为用户接听了新来电（TC@43），导致当前通话（TC@42）被挂断或结束。然后InCall模块更新了通话状态，检查了视频通话的降级情况，但结果显示没有变化。最后几行涉及视频通话的CRBT（彩铃）模式，但当前设置为0，可能没有启用。 用户可能需要了解这些日志的含义，尤其是在处理蓝牙通话时遇到的问题，比如通话切换、挂断或接听问题。需要解释每个日志行的关键部分，比如进程、服务、状态变化，以及可能的用户操作对应的系统反应。同时，要指出可能的异常情况，但根据日志来看，似乎都是正常的状态变更，没有明显的错误。用户可能是开发者或测试人员，遇到通话问题需要排查日志，所以需要详细解释每个部分的意义，帮助他们理解系统行为。</think>### 日志逐行解析及系统行为分析 --- #### **行 62397-62400（蓝牙通话服务模块）** ```log 行 62397: BluetoothInCallService = com.android.bluetooth.telephony.BluetoothInCallService@38bdc84 行 62398: processChld 1 行 62399: ringingCall hashcode: 177724520 行 62400: Active: Call [id: TC@42, state: ACTIVE ... Held: null chld: 1 ``` 1. **BluetoothInCallService 实例化** - `@38bdc84` 是对象内存地址，表示蓝牙通话服务模块已初始化。 - 用途：管理蓝牙设备与电话通话的交互（如耳机接听/挂断）。 2. **`processChld 1` 操作** - `CHLD` 是 GSM 规范中的 **呼叫保持控制命令**，`1` 表示执行「挂断当前通话并接听新来电」操作。 - 典型场景：用户通过蓝牙耳机接听新来电时触发。 3. **通话状态记录** - **活跃通话**：`Call [TC@42, state: ACTIVE]`，号码 `18756305546`，支持高清音频（`PROPERTY_HIGH_DEF_AUDIO`）。 - **响铃通话**：`Call [TC@43, state: RINGING]`，号码 `18136655845`。 - **保持通话**：`Held: null` 表示无保持中的通话。 --- #### **行 62434-62440（通话状态变更）** ```log 行 62434: Call [TC@42, state: DISCONNECTING ... newState=10 行 62435: updateFromTelecommCall: Call [TC@42, state: DISCONNECTING ...] 行 62436: setIsAnswering: false 行 62439: setPlayingVideoCrbt, mVideoCrbtMode:0 ... ``` 1. **通话断开流程** - `TC@42` 状态从 `ACTIVE` 变为 `DISCONNECTING`（状态码 `10`），表示通话正在终止。 - 原因推测：用户接听了新来电 `TC@43`，系统自动挂断原通话 `TC@42`。 2. **状态同步与资源释放** - `updateFromTelecommCall` 更新通话状态，`VideoCallImpl@7391459` 表示视频通话对象未变化。 - `setIsAnswering: false` 表明当前未处于接听新来电的瞬时状态。 3. **视频彩铃（CRBT）状态** - `mVideoCrbtMode:0` 表示未启用视频彩铃功能。 --- ### 关键行为总结 1. **场景还原** - 用户设备通过蓝牙接收到新来电 `18136655845`（`TC@43`）。 - 系统挂断当前活跃通话 `18756305546`（`TC@42`），触发 `DISCONNECTING` 流程。 - 通话控制通过 `BluetoothInCallService` 与底层服务 `TelephonyConnectionService` 协作完成。 2. **技术细节** - **CHLD 命令**：$$ \text{CHLD=1} \Rightarrow \text{保留当前通话并接听新来电} $$ - **视频能力**：`CAPABILITY_SUPPORTS_VT_*` 表明设备支持双向视频通话。 --- ### 异常排查建议 若遇到通话异常（如蓝牙无法挂断），需关注： 1. **状态同步延迟**：检查 `DISCONNECTING` 是否最终变为 `DISCONNECTED`。 2. **蓝牙服务绑定**：确认 `BluetoothInCallService` 与电话服务的绑定状态。 3. **CHLD 兼容性**：部分蓝牙设备可能不支持完整的 `CHLD` 指令集。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值