Skip to content

Script (Update)

Jump to bottom
BrunoYoo edited this page Jun 26, 2023 · 12 revisions

Presentation Script Intro

안녕하세요, 1팀, Milestone 1 발표를 시작하겠습니다.

Hello, We're Team 1, We're going to present for Milestone 1.

Project description을 통해서 고객이 기대하는 것 아래와 같습니다.

Here's what the customer expects from the project description:

Network 에서 구동 되는 Video call / Conference call 기능을 가진 Windows app 이며, 제한된 대역폭과 불안정한 Network 환경에서도 안정적이고 고품질의 통신을 보장하는 것을 가장 중요하게 생각한다는 것을 알게 되었습니다.

Most important things we have analyzed are :

  • One is to Ensure quality voice and video communication that is also secure and reliable.
  • Other is to Ensure that the system back-end server and user application minimizes network bandwidth as necessary to maintain communication between the parties.

이를 바탕으로 저희는 Requirement / QA / ASR 을 도출하고 Design decision 을 내리기 위해서 Risk 를 도출하고 검증하기 위한 실험을 진행하면서 전체 Milestone및 역할 분담을 진행하고 있습니다.

Based on this point of view,

  • We have crafted the functional requirements, Quality Attributes, and Design Constraints.
  • We are conducting experiments to derive and verify risks while proceeding with overall milestones and role division for design decisions.

Architectural drivers

Let's talk a little bit about the architectural drivers.

(wiki 위치 변경 Use Case 위치로)

먼저, Microsoft Windows user application과 server application 에 기술 된 내용을 Use Case 및 User-Story를 통해 workflow를 분석해 보았습니다.
Microsoft Windows user application와 server application 은 각각 7개와 4개의 Use Case를 통해 Functional Requirements를 도출하였습니다.

  • First, we analyzed the workflow through Use Case and User-Story for the contents described in Microsoft Windows user application and server application.
  • Functional requirements were derived for Microsoft Windows user application and server application through 7 and 4 use cases, respectively.

(wiki 위치 변경 QA위치로)

QA 요구사항은 Performance 5개, Availability 3개, Modifiability 2개를 도출 하였습니다. QA 요구사항의 우선순위는 고객의 평가와 기술 난이도로 우선순위를 선정 하였습니다. 우선 순위가 가장 높은 QA 요구사항에 대해 말씀 드리겠습니다.

  • As for the QA requirements, 5 Performance, 3 Availability, and 2 Modifiability were derived.
  • The priorities of QA requirements were prioritized based on customer evaluation and technical difficulty.

(wiki 위치 변경 ASR로)

  • Let's talk about the highest priority QA requirements.

성능 1개와 가용성 2개입니다. 각 요구 사항을 만족하고 필요한 전술을 적용하기 위해 검토한 Risk와 실험에 대해 설명 드리겠습니다.

  • The highest priority of QA requirements are 1 performance and 2 availability.
  • We will describe the risks and experiments we went through to determine what tactics are needed to satisfy each requirement.

ASR / Architectural Approach / Risk assessment / Experiments

저희 1팀이 검토 한 ASR 솔루션의 주요 아키텍처 접근 방식(전술, 패턴, 디자인 전략)에 대해 설명 드리겠습니다.

  • We will explain What are the main architectural approaches (tactics, patterns, design strategies) in our solution.

첫 번째, 시스템이 오디오 및 비디오 지연이 눈에 띄게 지연되거나 저하되지 않고 통화 품질을 유지하기 위한 성능 요구 사항을 달성하기 위해 우리는 다음 두 가지 질문을 해보았습니다. 제한된 대여폭 내에서 여러 사용자의 효율적인 통신을 위해 star topology를 사용할 수 있는가 ? 또한, 네트웍 대여폭과 참가자 수를 고려하여 비디오 품질을 동적으로 변경 가능한가 ? 두 가지 질문에 대한 답을 얻기 위해 네트워크 대역폭과 비디오 품질 간의 상관 관계를 찾는 테스트를 진행 중입니다. (테스트 페이지로 진입) 이 테스트의 목적은 네트워크 대역폭이 감소함에 따라 비디오 해상도를 낮출 때 비디오 품질(끊김, 왜곡)이 유지되도록 합니다. 이 테스트의 결과는 성능 요구 사항을 만족하기 위해 사용할 Manage work requests 전략으로 간주 됩니다.

  • First, System shall maintains call quality without causing noticeable delay or degradation of audio and lag of video, If the capacity of network reduced. To achieve this requirement, we asked the following two questions.
    • Can star topology be used for efficient communication of multiple users within a limited bandwidth ?
    • Also, is it possible to dynamically change the video quality considering the network bandwidth and the number of participants?
  • We are conducting tests looking for a correlation between network bandwidth and video quality to answer two questions. (Move on Test Experiments 2)
  • The objective is to ensure that video quality(choppy, distorted) is maintained when reducing video resolution as network bandwidth decreases.
  • The results of our tests are what we expect:
    • video quality (stuttering, distortion) is maintained when video resolution is reduced as network bandwidth decreases. (back to ASR)
  • Therefore, The results of this test consider the _**Manage work requests tactics **_to be used to meet performance requirements.

두 번째, 시스템이 오디오 및 비디오 지연이 눈에 띄게 지연되거나 저하되지 않고 통화 품질을 유지해야 하는 가용성 요구 사항을 달성하기 위해 다음 질문을 해보았습니다. UDP 수신기 모듈에서 네트워크 지터 감지 및 수신 버퍼 변경이 가능한가 ? (테스트 페이지로 진입) 질문에 답을 얻기 위해 구체화 한 테스트는 수신기가 지터 버퍼를 사용하여 네트워크 지터 문제를 개선할 수 있는지 확인 것입니다. 테스트 결과를 통해 네트워크 지터에 저항하는 수신기의 적절한 지터 버퍼 크기를 조정 할 수 있을 것으로 기대 합니다.

  • Second, System shall maintains call quality without causing noticeable delay or degradation of audio and lag of video, If the amount of network jitter increases.
  • we also asked the following question.
    • Is it possible to detect network jitter and change receiving buffer in UDP receiver module? (Move on Test Experiments 3)
  • To answer this question, A test we've elaborated is to see if the receiver can use a jitter buffer to improve network jitter issues.
  • We expect that the test results will allow us to properly size the jitter buffer in the receiver to resist network jitter. (back to ASR)
  • Therefore, we plan to utilize the Monitor tactic to properly size the jitter buffer.

세번째, 시스템이 네트워크에서 패킷/데이터 손실이 증가하는 경우 오디오 및 비디오 지연이 눈에 띄게 지연되거나 저하되지 않고 통화 품질을 유지해야 하는 가용성 요구사항을 달성 하기 위해 다음 질문을 해보았습니다. 패킷 손실을 감지하고 이전에 수신한 패킷을 복제하여 손실을 개선/복구 가능 한가 ? 입니다. (테스트 페이지로 진입) 저희가 구체화 한 테스트는 수신기가 중복/재정렬을 사용하여 패킷 손실 문제를 개선할 수 있는지 확인 하는 것입니다. 데이터 수신 모듈의 관점에서 네트워크 패킷 손실을 감지하는 방법으로 요구 사항을 만족할 것으로 기대 합니다.

  • Last, System shall maintains call quality without causing noticeable delay or degradation of audio and lag of video If the amount of packet/data loss increases in network.
  • we asked the following question.
  • Is it possible to detect packet loss and improve or recover hat loss by duplicating previously received packet ? (Move on Test Experiments 4)
    • The test we implemented is to see if the receiver can use duplication/reordering to improve packet loss issues.
    • From the point of view of the data receiving module, we expect that the method of detecting network packet loss will meet the requirements. (back to ASR)
  • We also plan to utilize the Monitor tactic to improve or recover that loss by duplicating previously received packet.

마지막으로, 이외에 Risk는 현재 팀원 대부분 VoIP System에 대한 기술적 배경과 경험이 많이 부족한 상황입니다. 해당 기술을 이해하기 위해 멤버들 간 깊이 있는 토론과 공부를 병행 하고 있습니다. 시간적인 제약을 극복하기 위해 활용 가능한 라이브러리 (GStreamer Library)를 검토 중에 있고 공부하고 있는 중입니다.

  • In addition, there are some restrictions on the technical background and experience of the team members in order to meet the project schedule.
  • In-depth discussions and research are taking place among members to understand the VoIP technology and GStreamer Library.

Project Plan

(wiki Project Plan 위치로 ) 여러가지 Risk 를 해결하기 위한 선택과 실험, 공부를 근거로 Windows Application 이고, 사용자 계정 기반으로 Direct call 와 Video conference기능을 제공하며, GStreamer open source를 사용해서 개발 일정을 최적화하며, System을 구성하는 Media server와 Client 간 Video/Audio 전송 STAR TOPOLOGY 를 사용함고 동시에, 네트워크 상황에 따라서 송수신 품질을 다양화함으로서 제한된 대역폭 내에서 많은 사용자들의 원활한 Video/Audio call 을 보장하고, Network 에서 발생할 수 있는 Packet drop 이나 Jitter 를 빠르게 판단하고, 이를 대처하여 사용자로 하여금 인지 가능한 Delay 나 Lagging을 최소화하는 Software를 개발하기 위한 계획을 수립하였습니다.

(wiki Project Plan 위치로 ) As described above, based on selection, experimentation, and research to address the various risks :

  • Provides Windows Application and back-end server,
  • Provides direct call and video conference functions based on user account,
  • Optimize our development schedule using GStreamer open source,
  • Use STAR TOPOLOGY to transmit video/audio between media servers and clients that make up the system,
  • Ensure smooth video/voice calls for many users within a limited bandwidth by diversifying the quality of transmission and reception according to network conditions.
  • Quickly determine possible packet drops or jitter on the network,
  • Without causing noticeable delay or degradation of audio and lag of video.
  • We plan the Project Plan.

개별 팀원들이 소규모 그룹을 이루어 독립적/병렬적으로 실험과 초기 개발을 진행하기 적절한 수준에서 Role을 분배하고, Module 을 지정하여, 모듈별 개발/검증/통합에 적절한 방법으로 구현 요소를 분리하여, 매주 수행해야 할 업무들과 그 업무들의 Dependency 와 통합 방안을 1차로 마련하여 아래와 같이 기록하였습니다.

  • Each team member forms a small group and divides roles at the appropriate level to carry out experiments and initial development independently/in parallel. (Move on Module View)
  • Specify the module and separate the implementation elements in a way suitable for the development/verification/integration of each module,
  • prepared a plan of tasks and dependencies and integrations to be performed each week as following : (Move on Road map)

Final 지금까지 설명 드린데로 아키텍처 접근 방식이 동인과 명확하게 관련되어 있다고 판단 합니다. 아직 좀 더 구체화 되지 않은 동인들 역시 지속적으로 토론하여 업데이트 할 예정입니다. 지금까지 1팀 발표 였습니다. 질문과 피드백 부탁 드리겠습니다.

  • From what we've explained so far, We think the architectural approach is obviously driver related. We will continue to discuss and update drivers that have not yet materialized.
  • So far, it has been one team presentation. Questions and feedback are welcome. Thanks

Final script

Introduction / Project Plan (Overview)

Hello, Let me start the Team1 presentation of Milestone 1.

At the top of the page, we have listed our understanding Milestone 1 approach To summarize, We understand that the customer wants a VoIP and video communication system that runs in a network environment utilizing user accounts, and they want stable and high-quality communication, even in limited bandwidth and unstable environments.

Based on this, we have derived requirements and ASRs, and made design decisions and various risks , and planned experiments to resolve these descisions and risks.

And then we made an overall / initial architecture and a plan and role for each team members based on our decisions.

Architecture Drivers

Ok. First, I will talk about the how we derived the architecture driver.

In order to derive the requirements without omission, we analyzed the use-case based on the project description, we also used the method of assuming and drawing UI Workflow for User-stories.

Then we derived 27 functional requirements, several design constraints, and 10 QAs. QA requirements consist of 5 performance, 3 availability, and 2 modifiability items.

We prioritized the items based on our understanding of the customer values and the technical difficulties for our team members, and we decided that 1 performance/2 availability QAs as ASRs. sine they are the most important items for determining the architecture

We derived tactics and design decisions to satisfy these ASRs, and at the same time, we reviewed the risks, and we made some solutions and experiments to verify these decisions and risks.

ASR / Architectural Approach / Risk assessment / Experiments

I will explain in more detail about the ASRs and Risks we have derived, and our team's architecture approach.

<1>

First, in order to meet the performance requirements, the system should maintain call quality when network capacity reduced. we asked the following two questions.

Can we use a star topology for efficient communication of multiple users within a limited bandwidth? Also, can we dynamically change the video quality considering the network bandwidth and the number of participants?

To answer the two questions, we made a experiment to find the correlation between network bandwidth and video quality. The purpose of this experiment is to keep the communication quality (cut, distortion) by reducing the video resolution as the network bandwidth decreases. (we think the results of this experiment are considered a Manage work requests strategy for performance requirements.)

<2>

Second, in order to meet the availability requirements that the system should maintain call quality if the amount of network jitter increases. we asked the following question. Is it possible to detect and change the receive buffer in the UDP receiver module for network jitter? To answer the question, we have specified the experiment to check if the receiver can improve the network jitter problem using a jitter buffer. We expect to be able to adjust the proper jitter buffer to reduce the network jitter.

<3>

Third, in order to meet the availability requirements that the system should maintain call quality if the amount of packet drops. we asked the following question. Can we improve/recover the packet loss by detecting them and duplicating the packets that were previously received? So we have specified the experiment to check if the receiver can improve the packet loss problem using duplication/reordering method.

<4>

Finally, about Risks, most of our team members are currently don't have technical background and experience in VoIP System. In order to understand the relevant technology, we are doing in-depth discussions and studies. Also we are considering to use and integrate GSTreamer library for development conveniences and shedule.

As we explained we planned four different experiments to verify each of our design desicon for ASRs and technical risks. Under the assumption that we can prove these decisions risks through these experiments, we have established the project overall plan at this point.

Project Plan (Detail)

I will summarize our project plan. Based on the our decisions, experiments, and studies to solve various risks, We made a development plan for the System which is.

  • Windows Application with direct call and video conference functions utilizing user accounts,
  • Optimizes development schedule using GStreamer open source,
  • Uses star topology for video/audio transmission between media servers and clients
  • Guarantees higher video call quality within limited bandwidth by changing the video quality according to the network situation,
  • Quickly detect packet drops or jitter and recover them to minimizes the delay or lagging that the user can experiance. .

To do that. as you can see in the module view, We have divided the system basically into Client and Server, and divided the jobs into UX, Media and Session. Members role was divided into Media Module, Session Module, and UX instead of Server-client .In order to develop and integrate independently,

We believe that our team's approach is clearly related to the Architecture driver, and we still have some open risk and we know we may have to change our strategy to meet ASR from the result of several experiments.

That would be all of our team's Milestone 1 presentation. There is not enough time and there are many worries, but I would like to say that we are working hard to successfully complete the project. we would like to welcome any questions or feedbacks now. Thank you Sir!

Appendix.

We still have significant concern of whether to use STAR Topology or Peer to Peer. We decided to use STAR Topology at the moment considering the consistent client behavior and better session management, and higher video resolution for more users within a limited bandwidth. Also Dan commented system should gurantee the maximum 10 participants.

However, from an evaluation point of view, we will test with 4 people, and for the laptop's limited camera resolution, the peer-to-peer method may be a better choice. We believe this can be changed after we get the results of the experiment.

Clone this wiki locally