1.2 主要内容和任务

​ 字幕横幅设置, 主席和成员可以设置会议字幕横幅。例如：字幕类型、内容、位置、效果。
​ 静音和扬声器设置，主席设置全局静音和取消静音操作，包括静音和扬声器设置，还有会议成员静音，会议主席能够对会议成员进行静音和扬声器设置
​

依赖关系
对其它网元、模块或功能的依赖：
终端修改（非必需）
MDC修改（必需） ccs>confmgr模块
UDC（非必需）

会议字幕横幅
收到会议主席/成员发起的设置会议字幕横幅Message消息，识别当前对接的是否为VDC会议系统，若不是，则返回会议系统不支持的操作结果；否则，转换成与VDC间的“设置会议横幅字幕”接口发送到VDC会议系统。
会议扬声器设置
收到会议主席发起的“静音/取消静音会议”Message消息，若携带了isQuiet字段，则识别当前对接的是否为VDC会议系统，若不是，则返回会议系统不支持的操作结果；否则，转换成与VDC间的“会议控制”接口发送到VDC会议系统。

2.1 功能需求分析

静音扬声器

会议主席可对会议指定成员禁言/取消禁言；会议成员调度员只可对自己进行禁言/取消禁言操作。另外，成员可自行本地闭音，即不再听取会议的音频。

主要业务流程如下：

1. 主席DC/成员在会议过程中指定成员静音/取消静音，向BCC发送Message（ConfMuteMember）请求；
2. BCC收到后转换成ZMQ请求转发ConfM处理；
3. ConfM根据body中携带的会议内部ID识别对应的会议系统；若为SMC，则按原流程处理；若为SMC，则按SMC“会场控制”的restful接口发送请求。若找不到会议信息，则向主席DC或成员返回静音/解除静音失败。
4. ConfM收到响应后向BCC转发响应，BCC转换成Message消息向主席DC或成员返回静音/取消静音的操作结果。

创会时会控ID修改为string类型，本地sdk对外接口修改，提供给DC使用，DC同步修改。检测其他SDK接口中是否有判断为全数字的限制

创会时会议密码修改为可选项，检查sdk接口中是否有必选判断，有去除判断

创建会议时增加会议速率参数

在创建会议时增加会议速率confrate参数，参数为可选参数。如果二开调用接口中携带了confrate参数，则在给MDC的创建会议message消息中填充此参数

esdk api、jssdk、restful接口都需要修改

取消发言人
在调用指定发言人，指定发言人为false时，在对接3.0场景下，发给mdc的message消息使用setfloor消息，其中参数Number为空字符串

2.2 消息格式说明

会议静音扬声器设置

会议字幕横幅设置

2.3 可维护性设计

主要查看的是ubp_confmgr.logs文件来定位问题，来定义错误发生在哪里是在从confmgr会议处理还是proxy代理处理。

ConfMgrService::ProcessConfMuteConfRequest:enter 为静音会议入口

ConfMgrService::ProcessConfMuteMemberRequest:enter 为静音会议成员入口

ConfMgrService::ProcessSetTextTipsRequest:enter 为字幕横幅入口

哪些环节需要记录什么日志、是否增加话统或性能监测项、错误码规划等等，提高问题定位效率

2.4 关键修改点

1.在ConfmgrServer中需要添加函数映射表

confReqFuncMap[EVT_TYPE_CONF_SET_TEXTTIPS_REQ]&ConfMgrService::ProcessSetTextTipsRequest;

2.绑定回调函数

BindNotifyCallback(EVT_TOPIC_SET_TEXTTIPS_RSP, &ConfMgrService::ProcessSetTextTipsResponse, this);

3.新增cmdMap对应的操作类的实例

cmdMap[EVT_TOPIC_SET_TEXTTIPS_REQ]=std::make_shared[HTML_REMOVED](smcClientMgr);

4.在proxy的smc3.0中需要新增字幕横幅处理类

5.在SMCrestAPI中添加字幕横幅设置VDC的接口

3.1 会议静音扬声器设计

接口定义
会议静音扬声器设置是复用已有的接口,新增isQuiet字段,有会议成员静音扬声器设置和会议静音扬声器设置接口需要新增VDC接口提供设置所有会议的横幅、字幕状态功能

会议静音扬声器设置接口
描述：
提供会控控制功能，包括设置主席、广播、点名、演示、全体静闭音、声控切换、设置会议多画面、一键呼叫、自由讨论等会控操作
请求路径
PATCH /conf-portal/online/conferences/{conferenceId}/status

请求消息:

MESSAGE sip: 99999510@3.2.40.42:19090;transport=udp;hweccap=0x8000 SIP/2.0
Call-ID: xx5gollo5imohlfl5hwbx59kyolymg9x@3.1.78.64
From: <sip:5702@huawei.com;noa=subscriber;srvattri=national>;tag=lbwfmoyx
To: <sip:99999510@huawei.com> //会议讨论,采用特殊的号码99999510.
CSeq: 1 MESSAGE
Contact: <sip:3.1.78.64:5060>;
Call-Info:<呼叫号码>;type=conference
Max-Forwards: 60
Content-Type: application/json
{
    "MsgType": "ConfMuteMember",
    "DcID": "12345",
    "OperationID": "1",
    "Content": {
        "confID": "998877",
        "memberInfos": {
            "Number": "12345",
            "isMute": "true",
            "isQuiet": "true", // 关闭扬声器
        },
        “confCasId”:”xxxxx”,
        "isWeLink": false
        }],
    }
}

响应消息:

MESSAGE sip:5701@3.2.40.42:19090;transport=udp;hweccap=0x8000 SIP/2.0
Call-ID: xx5gollo5imohlfl5hwbx59kyolymg9x@3.1.78.64
From: <sip: 99999510@huawei.com;noa=subscriber;srvattri=national>;tag=lbwfmoyx
To: <sip:5701@huawei.com>
CSeq: 1 MESSAGE
Contact: <sip:3.1.78.64:5060>;
Call-Info:<呼叫号码>;type=conference
Max-Forwards: 60
Content-Type: application/json
{

    "MsgType": " ConfMuteMember",
    "DcID": "12345",
    "OperationID": "1",
    "RetCode": 0,
    "RetMsg": "success",
        "Content": {
        "ConfID": "9888888",
        "memberInfos": {
        "Number": "12345",
        }
    }
}

​

3.2 会议成员静音扬声器设计

描述：
​ 提供更新会场状态功能，包括呼叫挂断、静闭音、开关扬声器、锁定视频源、调节音量、设置会场视频源等功能
​请求路径
​ PATCH/conf-portal/online/conferences/{conferenceId}/participants/{participantId}/status

3.3 会议字幕横幅设计

会议字幕横幅设置接口
描述:
提供设置所有会议的横幅、字幕状态功能
请求路径
POST /conf-portal/online/conferences/{conferenceId}/textTips

​

4.1 总结

在公司中完成一个版本的特性开发，了解了公司的这个特性的开发流程，从SE的特性澄清，开发的设计文档的编写和DT用例的设计，到特性的反向澄清，到编码流程，编码完的代码自测联调，再到最后的代码上库检视，这个流程的每一个部分都对我有很大的帮助，让我了解到开发不仅仅是编码这一件事情，恰恰编码是特性开发流程中最轻松的，在整个项目特性中编写的代码一般都会对接其他人写的代码，一起联通的来看，特性是否开发完成，这个期间会发生很多很多的BUG需要我们去看代码，打日志来调测，来分析和定位问题出现在哪里，还有作为以为FO，更重要的是对与自己相关特性的整个进度和其他模块的拉通磨合，带领着开发者朝着目标编码，还有在整个流程中最最重要的还是要设计出全面的DT用例来规划自己的代码，一个好的DT用例就能间接的体现编码后的代码的质量，一般DT越丰富和详细，代码都不会写出很多BUG，因为你的DT用例已经规范掉了这些间接的错误情况，在编码的时候就会考虑到很多的情况，还有设计关键类的时候也需要对类的种种规范进行考虑，因为如果在编码中没有对类和方法，属性等等编码做出规范，在提交MR的时候会对修改的代码过流水线门禁就会出现很多错误，例如巨大函数，使用宏定义，代码段最后有空格，无关的日志和注释，不能有代码注释和一个函数方法的圈复杂度不能过大，过深等问题。编码能力和业务掌握能力也是很重要的。对特性开发是有很大的帮助，有一个好的业务掌握能力对特性开发当中遇到了一起奇奇怪怪的问题能够快速的定位到错误情况

4.2 不足和改进

对全局进度的掌控不足
作为FO，需要对整个特性的开发节奏和其他模块的协作情况有清晰的掌控，但在实际过程中，有时对某些模块的进度拉通不够及时，导致联调阶段产生了一些阻塞情况。

改进措施：

• 定期与其他模块的开发者沟通，确保大家对进度和问题有一致的理解。
• 学习使用更高效的项目管理工具，将任务进展和依赖关系可视化，提升整体协作效率。

对问题定位的速度有待提升
在调测BUG时，定位问题的效率较低，部分问题分析时间较长，影响整体开发节奏。

改进措施：

• 强化对日志分析的能力，多熟悉代码的整体结构及常见问题模式，提升对问题的敏感度。
• 总结BUG案例，建立问题诊断的知识库，减少类似问题的重复分析时间。

编码规范的熟悉度不足
提交MR时，仍出现了一些常见的编码规范问题，例如圈复杂度过大、代码注释不当、冗余日志等，影响了代码的通过效率。

改进措施：

• 深入学习项目的编码规范，尤其是在设计类和方法时，严格遵循函数长度、复杂度等要求。
• 提交代码前，养成自查习惯，确保通过自动化工具的初步校验。

DT用例设计不够全面
尽管DT用例在一定程度上覆盖了大部分情况，但在极端场景和边界测试方面的考虑不够，导致部分BUG未能在自测阶段发现。

改进措施：

• 强化测试思维，结合历史问题和业务逻辑，设计更具针对性的用例。
• 学习优秀的DT用例编写方法，参考团队中经验丰富的同事的设计思路。

业务理解需要进一步深入
对部分复杂业务的理解深度不足，导致某些问题的解决效率较低，对上下游模块的影响也未完全考虑到。

改进措施：

• 主动参与需求澄清的过程，深挖业务逻辑，确保从需求到编码的全链路理解。
• 定期总结所学的业务知识，与团队分享，互相促进。