我有一个java服务器任务,它占用内存.我怀疑它曾经超过MinHeapFreeRatio,但那是猜测.更有趣的是,GC将成熟生成减少到大约2%,但从不减少堆的分配内存.
Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 3221225472 (3072.0MB) NewSize = 268435456 (256.0MB) MaxNewSize = 268435456 (256.0MB) OldSize = 805306368 (768.0MB) NewRatio = 7 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 176160768 (168.0MB) Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 241631232 (230.4375MB) used = 71657320 (68.3377456665039MB) free = 169973912 (162.0997543334961MB) 29.65565312351675% used Eden Space: capacity = 214827008 (204.875MB) used = 47322984 (45.130714416503906MB) free = 167504024 (159.7442855834961MB) 22.028414602320392% used From Space: …
我了解NAT打孔,ICE和SIP VOIP调用的许多细节.关于这些主题,我已经回答了很多关于SO的问题.现在我有一个问题.
我试图理解在呼叫已经建立之后需要为SIP + ICE记录的RE-INVITE消息.
假设VOIP设备的拓扑结构通过SIP发信号并使用ICE(使用STUN/TURN)建立媒体连接.执行ICE连接检查后,两个端点都应确定最佳地址候选配对(IP,端口),并准备好在两个方向上流媒体.
但是我使用SIP和大量文档的经验表明,在被叫方发送200 OK消息以表明他处于应答状态后,调用者将发送一个带有SDP的RE-INVITE,其中包含通过连接性检查选择的特定地址候选者.
描述RE-INVITE与ICE的一些链接在这里和这里(步骤8).Rosenberg的教程(第30页)讨论了RE-INVITE"确保中间盒具有正确的媒体地址".我不确定为什么这很重要.
在收到RE-INVITE时,被叫方是否期望根据收到的新SDP重新配置其ICE堆栈以切换套接字或地址？或者RE-INVITE只是一种协议形式,正式承认呼叫已经建立？如果跳过RE-INVITE步骤并且双方都开始流媒体,那么可能出现什么问题？
我问的原因是因为我正在探索使用ICE而不是SIP的信令服务.我想弄清楚RE-INVITE是否需要模拟.
似乎 AudioContext.createMediaStreamDestination() 默认为单声道输出。此默认值正在更改，但有没有办法手动设置所需的输出通道数？
或者有没有其他方法可以在保留正确数量的频道的同时将流从 WebAudio 获取到 WebRTC？