출처: 행정안전부
행정·공공기관 영상회의시스템 상호연계 기술 표준규격 요약한 글입니다. 출처는 행정안전부이며 행정·공공기관 영상회의시스템 상호연계 기술 표준규격에 대한 글을 다루고 있습니다. 행정·공공기관 영상회의시스템 상호연계 기술 표준규격 내용에 대한 전문이 필요하신 분은 하단으로 가시면 행정·공공기관 영상회의시스템 상호연계 기술 표준규격 다운로드 및 확인하실 수 있습니다.
행정·공공기관 영상회의시스템 상호연계 기술 표준규격(행정안전부고시 제2021-83호, 2021. 12. 13.,
행정안전부 홈페이지에 오신것을 환영합니다.
www.mois.go.kr
행정·공공기관 영상회의시스템 상호연계 기술 표준규격(행정안전부고시 제2021-83호, 2021. 12. 13., 일부개정)
행정·공공기관 영상회의시스템 상호연계 기술 표준규격
[시행 2021. 12. 13.] [행정안전부고시 제2021-83호, 2021. 12. 13., 일부개정]
1. 적용범위
이 표준은 행정·공공기관에서 영상회의시스템 도입 시 고려해야하는 연계 구성 및 기능, 그리고 이기종간의 상호 연동을 위한 표준 규격에 대해 규정한다.
본 ‘행정·공공기관 영상회의시스템 간 연동 표준’은 영상회의를 위한 영상회의시스템의 연동 기술규격으로써 전송장비가 갖추어야 할 필수 기능, 영상회의 전송장비 기능의 연동 범위, 연동 프로토콜 및 메시지 규격을 포함한다.
또한, 행정·공공기관과 영상회의 연동이 필요한 행정·공공기관 외 영상회의시스템도 이 표준을 모두 준수하여야 한다.
2. 적용근거
2.1 법률적 근거
이 표준의 구체적인 법률적 근거는 다음과 같다.
· 전자정부법 제50조(표준화)
· 전자정부법 제52조(정보통신망의 구축)
· 행정 효율과 협업 촉진에 관한 규정 제58조(영상회의시스템의 구축 및 연계·운영)
2.2 참조표준
이 표준은 다음의 표준을 참조하여 관련 조항을 구성하였다.
· TTAK.KO-08.0034/R1, 스마트워크를 위한 영상회의시스템 간 상호연동 : SIP 통신 세부 기술규격
· W3C Recommendation, WebRTC 1.0 : Real-Time Communication Between Browsers W3C Recommendation
· TTA 표준해설서, 웹에서의 실시간 비디오, 오디오, 데이터통신 프로그래밍을 위한 W3C WebRTC 표준해설서
이 표준에 언급되지 않은 영상회의시스템의 기능은 위의 표준에서 제시하고 있다.
3. 용어정의
이 표준의 목적을 위하여 다음의 용어와 정의를 적용한다.
3.1 영상회의(Video Conferencing)
지리적으로 멀리 떨어져 있는 사람들 간 직접 대면하지 않고서도 일대일 또는 다자간 회의를 실시간으로 진행하는 것으로 이때 회의는 영상 및 음성을 이용하거나 콘텐츠를 화면으로 공유하는 것을 말한다.
3.2 영상회의시스템
영상회의를 진행할 수 있도록 영상장비, 음향장비, 전송장비 등으로 구성된 정보시스템을 말하며 하드웨어 기반 및 소프트웨어 기반으로 구현된 시스템을 포함한다.(호처리 서버, 다 자간 영상회의시스템, 코덱단말 및 이와 유사한 기능을 수행할 수 있는 장비 및 소프트웨어 포함)
3.3 코덱단말
영상회의 서비스를 이용하기 위해 코덱 기능과 호 처리 기능을 제공하는 단말 장치를 말한다.
3.4 영상회의 단말
코덱단말, 다 자간 영상회의시스템, 소프트웨어 영상회의시스템인 경우 고유의 SIP ID를 부여해야 하는 영상회의 SW가 설치된 사용자PC 또는 셋톱박스도 포함한다.
3.5 호처리 서버(SIP서버)
IETF(Internet Engineering Task Force)에서 제정된 SIP(Session Initiation Protocol) 이용하여 SIP 장비의 등록, SIP 장비 간 호 처리 및 호 연결을 중계하는 Proxy 기능을 포함한다.
3.6 영상회의 서버
서버-클라이언트 방식으로 구현된 SW 영상회의시스템으로 응용서버 및 미디어 서버로 구성된다.
. 응용 서버 : SW가 설치된 사용자 PC와의 호 연결 및 해지 등의 시그널링 프로토콜 관리, 회의예약·개설·참여·종료 등의 영상회의의 기능을 제공
. 미디어 서버 : 영상 회의에서 사용하는 음성, 영상, 이미지와 같은 멀티미디어 정보를 관리·제공하는 서버로 코덱 단말들 간 미디어를 조합(mixing)하여 전달하는 기능 등을 수행
3.7 다 자간 영상회의시스템(MCU, Multipoint Control Unit)
다수의 코덱단말들이 참여할 수 있는 가상의 영상회의 세션을 개설하고 참석 단말들의 영상들을 지정된 화면배치(Layout)를 이용하여 선택적으로 조합한 뒤 참여 단말들에게 재전송하는 장치를 말한다.
3.8 호 처리 프로토콜(SIP, Session Initiation Protocol)
인터넷상에서 통신하고자 하는 전화, 인터넷 콘퍼런스, 인스턴스메시지 등 지능형 단말들이 서로를 식별하고 그 위치를 찾고, 그들 상호간에 멀티미디어 통신 세션을 생성하거나 삭제 변경하기 위한 절차를 명시한 응용 계층의 시그널링 프로토콜을 말한다.
3.9 미디어 전송신호 중계 기능(RTP Proxy, Realtime Transport Protocol Proxy)
영상회의 단말 간 송수신되는 영상 및 데이터의 전송신호를 중계하는 서비스를 말한다.
3.10 화면공유
컴퓨터 화면을 통해 보여지는 디지털 콘텐츠(문서, 동영상, 웹 등)를 상대방이 동일하게 볼 수 있도록 전송하는 기능을 말한다.
3.11 중앙 집중형
하나의 영상회의 서버 또는 SIP 서버에 등록된 코덱단말의 영상 회의 세션에 관련된 모든 기능을 통합 관리하는 방식을 말한다.
3.12 분산 처리형
지역 또는 기관의 영상회의 트래픽을 분산하여 구축된 영상회의 서버 또는 SIP 서버에서 처리하고 지역 간 통신이 필요한 경우에만 중앙 서버를 경유하도록 하는 방식을 말한다.
3.13 도메인 간 상호접속 프로토콜(SIP Trunk)
SIP 서버에 등록된 영상회의 단말이 다른 SIP 서버에 등록된 영상회의 단말을 호출하는 경우 이들 SIP 서버 간 IP 정보를 이용한 연동 환경을 제공하기 위한 기능을 말한다.
3.14 연동장비
통신 프로토콜을 달리하는 두 개의 네트워크 통신 계층 간에 이종 프로토콜의 연결된 영상회의 단말별 변환기능을 수행하는 장치를 말한다.
3.15 WebRTC
WebRTC(Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API이다. W3C에서 제안하고 있으며, 음성 통화, 영상 통화, P2P 파일 공유 등에 적용할 수 있다. WebRTC 관련 상세 용어에 대한 상세 설명은 W3C Recommendation Section 3 혹은 TTA 표준해설서 5.(3)을 참조한다.
4. 영상회의시스템의 구성 및 연계
4.1 영상회의시스템 구성
영상회의시스템은 그림 1과 같이 4개의 분야로 구성되고 각 분야별 구성은 기관의 구축 규모 및 운영 특성에 따라 최적화 하여 재구성 할 수 있으며 각 분야별 주요 기능은 다음과 같다.
전송장비는 압축한 각종 정보(영상, 음성, 데이터)를 SIP 통신을 이용하여 멀리 떨어져 있는 상대방에게 전달하는 기능을 수행하며 SIP서버, 다자간 영상회의시스템, 영상회의서버, 코덱단말 등이 해당된다.
영상장비는 영상 또는 콘텐츠를 촬영하거나 표출하는 기능을 하며 웹캡 등의 카메라, 프로젝터· TV·모니터와 같은 디스플레이가 해당된다.
음향장비는 마이크, 스피커, 헤드셋 등 말하며 영상회의 참석자의 음성을 입력하거나 출력하는데 사용한다.
제어장비는 15인 이상의 중·대형 영상회의실에 주로 사용되며 영상회의시스템을 구성하는 영상·음성·전송장비 등을 통합적으로 제어하는 장비를 말하며 비디오매트릭스, 비디오 스위처, 오디오믹서, 전원 공급 장치, 통합제어시스템 등이 해당된다.
그림 1 – 영상회의시스템 기본 구성도
4.2 영상회의 연계 구성도
영상회의시스템 간 연계구성은 그림 2, 그림 3과 같이 연계범위 및 규모에 따라 영상회의 통신 및 미디어 세션을 관리하는 시스템을 중앙 집중형과 분산 처리형으로 구성할 수 있으며 영상회의 통신세션 및 미디어세션은 각급기관에서는 영상회의시스템의 이용 빈도 등을 고려하여 Proxy 등을 이용하여 적절하게 구성할 수 있다.
그림 2 – 영상회의 통신 세션 연계 구성
그림입니다. 원본 그림의 이름: image1.png 원본 그림의 크기: 가로 1367pixel, 세로 522pixel
그림 3 – 영상회의 미디어 세션 연계 구성
또한, 기관의 영상회의 통신망에 따라 보안이 요구되는 범위 내에서 그림 4와 같이 각급기관에서 운영하는 영상회의시스템과 연결할 수 있다.
이때 인터넷망에서 운영하는 영상회의시스템은 정부 내 영상회의시스템과 연결 시에는 인터넷이 차단되는 등의 보안 조치를 하여야 한다.
그림입니다. 원본 그림의 이름: image1.png 원본 그림의 크기: 가로 1326pixel, 세로 682pixel
그림 4 – 영상회의 통신망 연계 구성도
4.3 호출번호 관리방안
영상회의시스템의 호출번호는 E.164에서 제시하는 번호체계인 Number Structure for Network’<NOTE> * cc(3 digits)+IC(1~4 digits)+SN (Max (12-x) Digits)를 준용하며 이때, SN은 분야별 총괄기관을 두어 관리한다.
<SIP ID 사용 예 : 범정부 영상회의 통합 연계분야의 호출번호 체계>
호출번호의 예)
1
1
0
1
0
0
0
0
0
1
①
②
③
④
① 영상회의 단말 구분 : 영상회의사용자(1), MCU(8), 호처리서버(9)
② 네트워크 위치 : 업무망(1), 인터넷망(6)
③ 기관분류 : 중앙부처, 지방자치단체, 공공기관
④ 개체코드 : 영상회의 단말 등록 시 순차적으로 할당되는 SIP ID
4.4 WebRTC의 동작 구성도
그림입니다. 원본 그림의 이름: image1.png 원본 그림의 크기: 가로 1308pixel, 세로 633pixel
그림 5 – 전체적인 WebRTC 동작 구성도
멀티미디어 세션 파라미터를 협상하는 프로토콜은 WebRTC에서 규격으로 권고하는 SDP(Session Description Protocol)를 사용한다. SDP는 IETF RFC 8866으로 표준화된 기술로 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 콘텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜이며, 이름 그대로 Session의 Description을 담당하는 프로토콜로 생성할 세션의 타입 정보를 전송한다.
또한, 다양한 사용자 네트워크 환경에서의 서비스 제공을 위해 STUN과 TURN과 같은 네트워크 연결 기능을 포함한다.
5. 전송장비의 연동 기술규격
이 절에서는 영상회의시스템 간 연동을 위해 전송장비에서 갖춰야 할 필수기능을 5.1절의 표 1에서 제시하고 전송장비의 연동세션 연결 및 미디어 전송, 영상 및 음성코덱, 화면공유, 암호화 등 기능구현 시 고려해야 할 세부 사항을 정의한다.
5.1 전송장비의 기능
기능명
기능설명
적용대상
영상회의 단말
호처리 서버
호출
다른 코덱단말과 연결 또는 연결요청을 응답 할 수 있는 인터페이스
필수
필수
응답
연결 요청에 대해 연결을 수락 또는 거부할 수 있는 인터페이스 및 기능
필수
필수
종료
연결 종료 요청 및 상대방이 연결 종료 요청 시 처리할 수 있는 인터페이스
필수
필수
통신 환경설정
영상회의 통신에 필요한 IP, DNS, Proxy, 도 메인, 통신포트, 프로토콜 등 네트워크 환경
설정 기능
필수
필수
영상/음성
코덱설정
코덱단말에서 지원하는 영상 및 음성코덱을 설정하는 기능
필수
화면공유
영상 전송과 별개로 상대방과 콘텐츠를 다른 영상 채널로 송수신하는 기능
필수
인증서 관리
장비인증 및 암호화 통신 등에 필요한 인증서 등록. 삭제 등 인증서 관리 기능
필수
필수
암호화
인증서를 활용하여 메시지 및 미디어 등 영상회의 통신을 암호화하는 기능
필수
필수
대역폭 관리
전송장비에서 미디어 전송 시 영상회의 통신망을 고려한 통신 속도 협상이 이뤄질 수 있도록 하는 대역폭에 대한 선별적 관리 기능
필수
장비등록
유효성이 검증된 인증서가 탑재된 영상회의 단말을 호처리 서버에 등록하는 기능
필수
표 1 – 주요기능
5.2 세션 연결방식
전송장비 간 세션 연결은 TLS 방식으로 IETF RFC3261에서 규정한 SIP 프로토콜을 사용하고 양방향 통신을 해야 한다.
다만, SIP 프로토콜을 지원하지 않는 전송장비인 경우 SIP 프로토콜 연동기능을 통해 세션을 연결할 수 있도록 해야 하며 이때 연동기능과 코덱단말간의 전송절차는 인용 표준인 TTA.KO-08.0034, 스마트워크를 위한 영상회의시스템 간 상호연동‘을 따른다.
더불어 이들 전송장비는 ‘4.3 영상회의시스템 호출관리방안’에서 정의한 번호체계가 적용되어 운영되어져야 한다.
5.3 음성코덱
G.711 코덱을 필수 음성 코덱으로 정의하고 OPUS 코덱, G.722, AMR, AMR WB코덱은 선택적으로 지원할 수 있다
5.4 영상코덱
H.264 Main Profile을 필수적으로 지원하고 VP8/9, H.263은 선택적으로 지원할 수 있다. 이때 대역폭 손실을 고려한 제품별 영상품질 보정기술은 이기종간 연동 시 화면 떨림 현상 등으로 나타날 수 있으므로 사용자가 선택하여 적용할 수 있도록 해야 한다.
코 덱
속 성
속 성 값
H.264VGA
payload type
Dynamic(96-127)
frame size
640 x 480
clock rate
90000
frame rate
3~30
H.264 720P
payload type
Dynamic(96-127)
frame size
1280 x 720
clock rate
90000
frame rate
3~30
H.264 1080P
payload type
Dynamic(96-127)
frame size
1920 x 1080
clock rate
90000
frame rate
3~30
표 2 – 영상코덱 종류
5.5 미디어 전송방식
음성 및 영상 데이터 전송은 sRTP 프로토콜을 이용하여 UDP 통신으로 전달하고 ‘IETF RFC3550’, ‘IETF RFC3551', 'IETF RFC6184'에 따라 처리되어야 한다. 이때, 영상 및 음성의 전송은 송신하는 영상회의 단말의 통신 속도 협상에 따라 비트율(bitrate)에 맞춰 전달해야 한다.
5.6 화면공유
화면공유는 기관의 연계운영 정책에 따라 TCP 또는 UDP 방식을 선택적으로 적용 할 수 있어야 하며 음성 및 영상 스트림과 별도의 미디어 스트림으로 H.264 코덱을 이용하여 전송 되어져야 한다.
이때 사용하는 프로토콜은 'IETF RFC8855', 'IETF RFC8856'에서 규정한 BFCP를 통해 제어하며 영상회의 단말 간 화면공유는 동시에 하나의 스트림만 가능하도록 해야 한다.
5.7 암호화 전송
암호화 전송은 영상회의시스템 간 신호방식 연동 및 미디어 전송 부분에 적용되며, TLSv1.2이상, sRTP를 기본으로 하고, 이때 사용하는 암호화 알고리즘은 암호키 길이가 128bit이상인 국내·외 표준 알고리즘을 권고한다.
기본 암호화 전송 외에 별도 보안규정 또는 지침에 의거 추가적인 암호화가 필요한 경우는 연계되는 기관에 각각 동일한 암호화 장비를 도입하여 운영하며, 인터넷망에서 운영되는 영상회의시스템과 연동 시 국가기관에서 안전성을 검증한 암호모듈을 사용하여야 한다.
5.8 장비등록
영상회의 단말이 호처리 서버에 등록 및 호 연결을 시도하는 과정에 앞서 반드시 인증서버와의 연동하여 인증서에 대한 유효성 검증을 Handshake단계에서 수행하여 신뢰성을 확보해야 한다.
영상회의 단말은 국가에서 지정된 인증기관으로부터 발급받은 공개키(PKI) 기반의 기기용 인증서를 우선 적용하며, 관리방안은 구현에 국한된 내용으로 본 규격에서 제약하지 않는다.
5.9 WebRTC 연동 방식
WebRTC는 HTML5 웹페이지에서 별도의 프로그램이나 플러그인 설치 없이 실시간으로 비디오, 오디오, 데이터 통신이 가능한 환경을 제공한다. WebRTC 표준의 프로토콜 스텍은 다음과 같다. WebRTC 표준규격에는 연결을 협상하기 위한 시그널링 메커니즘을 규정하고 있지 않지만, 본 표준에서는 기존 표준과의 호환성 및 구현 용이성을 위해 WebRTC의 시그널링 메커니즘으로 SIP를 사용한다.
그림입니다. 원본 그림의 이름: image1.png 원본 그림의 크기: 가로 1332pixel, 세로 672pixel
그림 6 WebRTC 프로토콜 스택
6. 연동 프로토콜
이 절에서는 영상회의시스템 간 영상회의를 위한 프로토콜의 적용범위 및 동작 절차, 메시지 규격에 대해 기술한다.
"프로토콜 적용범위"에서는 SIP 프로토콜을 이용한 연동이 필요한 범위를 정의하고, "프로토콜 동작 절차"에서는 프로토콜 규격을 포함한 메시지 처리 절차를 정의한다.
6.1 프로토콜 적용범위
영상회의 연동 프로토콜은 그림 7, 그림 8에서 제시한 대로 영상회의 단말간의 영상회의 통신세션 연결 구간 및 여러 대의 호 처리 서버 운영 시 호 처리 서버 간을 포함한 단말간의 통신세션에 모두 적용되어야 한다.
그림 7 - 영상회의 단말 간 연동
그림 8 - 다수의 영상회의 서버 간 연동
6.2 통신 프로토콜
영상회의 통신에 사용되는 프로토콜은 SIP, RTP, BFCP 등이 있으며, 각 프로토콜별로 사용하는 TCP 또는 UDP 포트를 정의한다.
6.2.1 SIP 전송 프로토콜
SIP메시지는 TLS를 이용하여 전달되어야 하며 포트 번호가 명시되지 않은 경우 TCP 5061 포트를 사용하는 것을 기본으로 한다.
6.2.2 RTP 전송 프로토콜
RTP 세션은 각 미디어 스트림을 전송하기 위해 설정되며, 일반적으로 UDP 1024 ~ 65535 포트를 사용한다. SDP를 이용하여 협상된 결과에 따라 미디어를 전송하기 위해 사용하며, SIP 서버에서 RTP 세션에 사용할 UDP Port 범위를 설정할 수 있다.
6.2.3 BFCP 전송 프로토콜
BFCP 전송 프로토콜은 특정 미디어 세션에 미디어를 송신할 수 있는 권리로서 영상회의 단말에서 공유되는 자원들에 대한 관리를 위해 사용되며 TCP 또는 UDP를 이용하여 전달하고 ‘IETF RFC4582’, ‘IETF RFC4583'에 따라 처리 되어야 한다.
TCP를 이용하는 경우에는 영상회의 단말 간에만 화면 공유가 적용되어 미디어 전송에 필요한 포트를 모든 기관에서 허용해야하는 제약이 있으며 UDP인 경우는 RTP Proxy기능, 방화벽 투과기능 등을 활용하여 연계 가용성을 확보할 수 있다.
6.3 연동 프로토콜
그림 9 – 연동 프로토콜 절차
6.4 프로토콜 동작 절차
6.4.1 TLS 세션 연결
그림 10 – TLS 세션 연결 절차
○ 정의
영상회의 단말이 영상회의 연동에 필요한 SIP 프로토콜을 암호화 하여 전송하기 위한 TLS 세션을 구축하는 절차이다.
○ 동작절차
① 영상회의 단말은 호처리 서버에게 영상회의 단말이 지원하는 TLS 버전과 Cipher Suite 정보를 전달하여 연결을 요청한다.
② 호처리 서버는 영상회의 단말로부터 수신한 TLS 버전과Cipher Suite 정보와 일치하는 호처리 서버의 TLS 버전과Cipher Suite 정보를 전달한다.
③ 호처리 서버는 초기 TLS Handshake 단계 검증을 위하여 영상회의 단말에게 X.509 인증서를 제공한다.
④ 호처리 서버는 영상회의 단말에게 초기 협상이 완료되었음을 통보하고 단말에게 인증서를 요청한다.
⑤ 영상회의 단말은 SIP 서버가 요청한 인증서 또는 인증서 Chain을 전달한다.
⑥ 영상회의 단말은 암호화 모드를 지정하고 지정된 암호화 모드로 변환을 요청하는 메시지를 전달한다.
⑦ 호처리 서버는 영상회의 단말로부터 수신 받은 암호화 모드로 변경을 요청하는 메시지를 전달한다.
⑧ 호처리 서버는 영상회의 단말과 암호화 세션을 활성화할 준비를 완료하고 암호화 통신을 시작한다.
6.4.2 SIP 등록
그림 11 – SIP 등록절차
○ 정의
영상회의 단말은 호처리 서버 등록절차를 수행하여 호처리 서버에 접근할 수 있도록 확인 과정을 거친 후 영상회의 서비스를 제공할 수 있어야 한다.
○ 동작절차
① 영상회의 단말은 TLS 전송방식을 이용하여 암호화 형태로 SIP 등록을 요청한다.
REGISTER sips:SIP서버도메인 SIP/2.0
Via: SIP/2.0/TLS
등록단말IP:5061;branch=z9hG4bKnashds7 Max-Forwards: 70
From: 등록단말_SIP_ID
<sips:등록단말_SIP_ID@SIP서버도메인>;tag=a73kszlfl To: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인>
Call-ID: 1j9FpLxk3uxtm8tn@SIP서버도메인 CSeq:
1 REGISTER
Contact: <sips:등록단말_SIP_ID@등록단말IP> Content-Length: 0
메시지 1 - Register
② 호처리 서버는 nonce 값을 추가 생성하고 영상회의 단말에 전달하여 재등록하도록 요청한다.
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 등록단말IP:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인>;tag=a73kszlfl
To: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인>;tag=1410948204 Call-ID: 1j9FpLxk3uxtm8tn@SIP서버도메인
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="SIP서버도메인",
qop="auth",
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
메시지 2 – 401 Unauthorized
③ 영상회의 단말은 호처리 서버와 세션 인증을 위하여 호처리 서버로부터 받은 nonce 정보를 추가하여 호처리 서버로 재등록을 시도한다.
REGISTER sips:SIP서버도메인 SIP/2.0
Via: SIP/2.0/TLS
등록단말IP:5061;branch=z9hG4bKnashd92 Max-Forwards: 70
From: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인>;tag=ja743ks76z
To: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인> Call-ID: 1j9FpLxk3uxtm8tn@SIP서버도메인
CSeq: 2 REGISTER
Contact: <sips:등록단말_SIP_ID@발신단말IP>
Authorization: Digest username="등록단말_SIP_ID", realm="SIP서버도메인" nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", uri="sips:SIP서버도메인", response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
메시지 3 - Register
④ 호처리 서버는 영상회의 단말에서 수신된 추가정보를 이용하여 암호화 통신이 되도록 처리하고 영상회의 단말에 암호화 통신 준비가 완료되었다고 전달한다.
SIP/2.0 200 OK
Via: SIP/2.0/TLS 등록단말IP:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
From: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인>;tag=ja743ks76zl
To: 등록단말_SIP_ID <sips:등록단말_SIP_ID@SIP서버도메인>;tag=37GkEhwl6 Call-ID: 1j9FpLxk3uxtm8tn@SIP서버도메인
CSeq: 2 REGISTER
Contact: <sips:등록단말_SIP_ID@발신단말IP>;expires=3600
Content-Length: 0
메시지 4 – 200 OK
6.4.3 SIP 호 연결
그림 12 – SIP 호 연결 절차
○ 정의
6.4.2에서 등록 절차가 끝난 영상회의 단말 간에 호 연결이 이루어지는 절차로 연결하고자 하는 영상회의 단말 간 SIP 메시지를 상호 확인한다.
○ 동작절차
① 발신 영상회의 단말이 호처리 서버에게 수신 영상회의 단말 정보가 포함된 헤더와 SDP에 지원이 가능한 미디어 정보를 포함하여 INVITE 메시지로 호출 요청 한다.
② 발신 영상회의 단말의 호출요청을 받은 호처리 서버는 수신 영상회의 단말에게 호출요청 메시지를 전달한다.
INVITE sips:bob@SIP서버도메인 SIP/2.0
Via: SIP/2.0/TLS 발신단말IP:5061;
branch=z9hG4bK74bf9
Max-Forwards: 70
From: 발신단말_SIP_ID
<sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567 To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>
Call-ID: 12345600@SIP서버도메인
CSeq: 1 INVITE
Contact: <sips:발신단말_SIP_ID@발신단말IP>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=
c=IN IP4 SIP서버도메인
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
메시지 5- Invite
③ 호출 요청을 전달 받은 수신 영상회의 단말은 호처리 서버가 발신한 영상회의 단말에게 호 연결을 시도하고 있음을 전달하도록 100 Trying 메시지를 전송한다.
④ 호처리 서버는 호 연결을 시도하고 있는 수신 영상회의 단말이 보낸 100 Trying 메시지를 발신 영상회의 단말에게 전달한다.
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 발신단말IP:5061;branch=z9hG4bK74bf9
;received=192.0.2.103
From: 발신단말_SIP_ID <sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567
To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>
Call-ID: 12345600@SIP서버도메인
CSeq: 1 INVITE
Content-Length: 0
메시지 6 – 100 Trying
⑤ 호처리 서버로부터 연결 요청을 받은 수신 영상회의 단말은 INVITE 메시지에 포함되어 있는 발신 영상회의 단말의 호출정보를 이용하여 호 연결을 시도하고 있음을 발신 영상회의 단말에 알린다
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS SIP서버도메인:5061; branch=z9hG4bK83749.2
;received=192.0.2.54
Via: SIP/2.0/TLS 발신단말IP:5061; branch=z9hG4bK74bf9
;received=192.0.2.103
Record-Route: <sips:SIP서버도메인;lr>
From: 발신단말_SIP_ID <sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567
To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>;tag=7654321
Call-ID: 12345600@SIP서버도메인
CSeq: 1 INVITE
Contact: <sips:수신단말_SIP_ID@수신단말IP>
Content-Length: 0
메시지 7 – 180 Ring
⑥ 호처리 서버로부터 호출 요청을 전달 받은 수신 영상회의 단말은 호 연결을 수락하고 호처리 서버에게 200 OK 응답 메시지를 보낸다. 이때 200 OK의 응답 메시지에는 발신 영상회의 단말로부터 전달받은 미디어 정보 중 수신 영상회의 단말이 지원할 수 있는 미디어 정보를 SDP에 포함해야 한다.
SIP/2.0 200 OK
Via: SIP/2.0/TLS 발신단말IP:5061; branch=z9hG4bK74bf9
;received=192.0.2.103
Record-Route: <sips:SIP서버도메인;lr>
From: 발신단말_SIP_ID <sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567
To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>;tag=7654321
Call-ID: 12345600@SIP서버도메인
CSeq: 1 INVITE
Contact: <sips:수신단말_SIP_ID@수신단말IP> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp Content-Length: ...
v=0
o=bob 2890844527 2890844527 IN IP4 수신단말IP
s=
c=IN IP4 수신단말IP
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
메시지 8 – 200 OK
⑦ 수신 영상회의 단말로부터 호 연결 수락을 전달받은 호처리 서버는 발신 영상회의 단말에게 200 OK 메시지를 전달한다.
⑧ 호처리 서버로부터 수신 영상회의 단말의 200 OK 메시지를 전달 받은 발신 영상회의 단말은 ACK 메시지를 호처리 서버를 통해 수신 영상회의 단말에 전송한다. 이때 ACK 메시지에는 200 OK 메시지에 포함하여 전달된 수신 영상회의 단말의 미디어 정보를 이용하여 통신하겠음을 알린다.
ACK sips:수신단말_SIP_ID@수신단말IP SIP/2.0
Via: SIP/2.0/TLS 발신단말IP:5061; branch=z9hG4bK74bfX
Route: <sips:SIP서버도메인;lr>
Max-Forwards: 70
From: 발신단말_SIP_ID <sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567
To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>;tag=7654321
Call-ID: 12345600@SIP서버도메인
CSeq: 1 ACK
Content-Length: 0
메시지 9 – ACK
6.4.4 미디어 전송 세션 연결
6.4.3절의 호 연결 절차로 정상적으로 호 연결이 된 경우 영상회의 단말은 미디어 송수신을 위한 별도의 경로를 생성하고 영상회의 단말 간 직접 미디어 통신을 진행한다. 단, 기관의 영상회의 연계구성에 따라 Proxy를 이용하는 경우에는 6.4.5를 따른다.
6.4.4.1 RTP 세션
그림 13 – RTP 세션 연결 절차
○ 정의
6.4.3절의 호 연결 절차로 정상적으로 호 연결이 된 경우 미디어 송수신을 위한 RTP 경로를 생성하고 영상회의 단말 간 직접 미디어 통신을 진행한다.
○ 동작절차
① SIP 통신을 이용하여 각 영상회의 단말이 서로의 네트워크 위치를 확인하고 실시간 미디어 통신을 위한 RTP 경로 정보를 확인한다.
② 각 단말이 생성된 RTP 세션을 이용하여 실시간 미디어 통신을 시작한다.
6.4.4.2 sRTP 세션
그림입니다. 원본 그림의 이름: CLP000036d82d77.bmp 원본 그림의 크기: 가로 734pixel, 세로 388pixel
그림 14 – sRTP 암호화 절차
○ 정의
TLS 암호화 통신에서 생성된 세션키를 이용하여 실시간 미디어 통신을 암호화하는 절차이다.
○ 동작절차
① TLS 세션에서 생성된 암호키를 이용하여 RTP 미디어를 암호화 처리 한다.
② 암호화 처리되어 수신된 sRTP 미디어를 송신 단말과 동일한 암호 알고리즘과 세션키로 복호화한다.
6.4.5 Proxy를 이용한 미디어 전송 세션 연결
그림 15 – RTP Proxy 세션 연결 절차
○ 정의
RTP Proxy 기능을 이용하여 영상회의 단말 간 미디어 통신이 지정된 Proxy 서버를 경유하도록 한다.
○ 동작절차
① SIP 통신 과정 200 OK 응답메세지에 다음과 같이 연결해야할 Proxy 정보를 SDP에 추가하여 RTP Proxy 기능이 제공되도록 해야 한다.
v=0
o=수신단말 정보 1570975231 1570975231 IN IP4 10.60.230.62
s=-
i=수신단말 모델명
c=IN IP4 RTPProxy IP주소 /*Connection Information ( RTP Prox y 서버 주 소) */
b=AS:4000
t=0 0
m=audio 55054 RTP/AVP 102 103 104 9 8 0
a=rtpmap:8 PCMA/8000/1
a=rtpmap:0 PCMU/8000/1
a=sendrecv
a=nortpproxy:yes/*RTP Prox y 활성화*/
메시지 10 – 200 OK 내 SDP
② 200 OK 메시지 내 RTP Proxy를 경유하여 단말 간 실시간 미디어 통신이 이루어진다.
6.4.6 BFCP 세션 연결
그림 16 – BFCP 세션 연결 절차
○ 정의
IETF RFC4583에 정의된 BFCP를 이용하여 화면공유 기능을 제어하고 기존 화면공유 세션이 종료되기 전에 다른 영상회의 단말에서는 화면공유 세션을 생성할 수 없도록 해야 하고 이때의 화면공유 세션은 1개로 제한한다.
○ 동작절차
① 화면을 공유하고자 하는 영상회의 단말은 SDP 내의 미디어 스트림 속성에서 Main Video외 화면공유 스트림 속성으로 별도 생성하고 상대방에게 전달한다.
② 단말 간 영상은 Main Video 스트림과, 화면공유 스트림으로 각각 전송한다.
③ 수신 단말에서는 화면을 공유하는 영상회의 단말에서 전송된 SDP내의 미디어 속성을 참조하여 화면공유 스트림을 별도로 처리하고 표출될 수 있도록 해야 한다.
m=video 16446 RTP/AVP 97 98 99 34 31
c=IN IP4 10.58.9.86/*Connection Information ( RTP Prox y 서버 주소) */
b=TIAS:6000000
a=label:11
a=content:main/*Main video stream 속성*/
m=video 16448 RTP/AVP 97 98 99 34 31
c=IN IP4 10.58.9.86
b=TIAS:6000000
a=label:12
m=application 5070 UDP/BFCP */*BFCP 해당 SDP로 TCP/TLS/BFCP도 가능*/
c=IN IP4 10.58.9.86
a=floorctrl:c-s
a=floorid:2 mstrm:12
a=confid:1
a=userid:8
a=nortpproxy:yes/*rtpprox y 기능 활성화*/
메시지 11 – 200 OK 내 SDP
6.4.7 SIP 세션 연결 해제
그림 17 – SIP 연결 해제 흐름도
○ 정의
송수신 영상회의 단말 간 영상회의가 끝나면 영상회의 단말에서 종료 메시지를 상대에게 종료하여 영상회의 통신을 종료한다.
○ 동작절차
① 영상회의를 끝내고자 하는 단말에서 BYE 메시지를 상대 단말에게 전송한다.
BYE sips:수신단말_SIP_ID@수신단말IP SIP/2.0
Via: SIP/2.0/TLS 발신단말IP:5061; branch=z9hG4bK74bW4
Route: <sips:SIP서버도메인;lr>
Max-Forwards: 70
From: 발신단말_SIP_ID <sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567
To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>;tag=7654321
Call-ID: 12345600@SIP서버도메인
CSeq: 2 BYE
Content-Length: 0
메시지 12 – BYE
② BYE 메시지를 수신한 영상회의 단말에서 200OK를 이용하여 통신이 종료됨을 확인한다.
SIP/2.0 200 OK
Via: SIP/2.0/TLS 발신단말IP:5061; branch=z9hG4bK74bW4
;received=192.0.2.103
From: 발신단말_SIP_ID <sips:발신단말_SIP_ID@SIP서버도메인>;tag=1234567
To: 수신단말_SIP_ID <sips:수신단말_SIP_ID@SIP서버도메인>;tag=7654321
Call-ID: 12345600@SIP서버도메인
CSeq: 2 BYE
Content-Length: 0
메시지 13 – BYE 200 OK
6.4.8 호처리 서버 간 연결
그림 18 – SIP Trunk 구성
○ 정의
다수의 호처리 서버가 존재하고 각각의 호처리 서버에 등록된 영상회의 단말 간에 영상회의 통신을 할 경우에는 호처리 서버 간 연동기능인 SIP Trunk를 통해 메시지를 전달해야 하며 관련 정보는 호처리 서버 내 SIP Trunk 대상의 호처리 서버IP 목록을 참조한다.
○ 동작절차
① 각 호처리 서버에서는 발신한 영상회의 단말로부터 전달 받은 수신 영상회의 단말 정보를 이용하여 수신 영상회의 단말이 등록되어 있는 호처리 서버로 메시지를 전달한다.
이때 SIP 서버1은 SIP Trunk 대상의 호처리 서버 IP주소를 참조하여 수신 단말의 URI를 생성한다.
INVITE sip:수신단말_SIP_ID@수신단말IP SIP/2.0
Via: SIP/2.0/TLS SIP서버도메인 _ 2_IP:5061;branch=z 9hG4bK721e4.1
Via: SIP/2.0/TLS SIP서버도메인 _ 1_IP:5061;branch=z 9hG4bK2d4790.1;
received=192.0.2.111
Via: SIP/2.0/TLS 발신단말IP:5061;branch=z 9hG4bK74bf9;
received=192.0.2.101
Record-Route: <sip:SIP서버도메인_2;lr>, <sip:SIP서버도메인_1;lr>
Max-Forwards: 68
From: 발신단말_SIP_ID <sip:발신단말_SIP_ID@SIP서버도메 인_1>;tag=9fxced76sl
To: 수신단말_SIP_ID <sip:수신단말_SIP_ID@SIP서버도메인_2>
Call-ID: 2x Tb9vx Sit55XU7p8@SIP서버도메인_1
CSeq: 1 INVITE
Contact: <sip:발신단말_SIP_ID@발신단말IP>
Content-Type: application/sdp
Content-Length: 151
메시지 14 – SIP Prox y 경유시 INVITE
② INVITE 이후의 100 Trying, 180 Ringing, 200 OK, ACK 등의 메시지 처리에 있어서도 INVITE와 같은 방식으로 Via 구문에 경유 SIP 서버의 정보를 포함하여 통신한다.
6.4.9 WebRTC를 이용한 네트워크 연결
STUN 서버는 서로 연결하고자 하는 Peer들이 NAT나 방화벽 뒤에 존재하는지 검사하고 이들의 공인 IP 주소를 Peer들에게 전달하는 역할을 수행한다.
STUN 방식으로 통신 설정을 시도했지만 실패하고 Peer가 서로를 찾지 못 했을 경우 TURN 서버가 Peer 간의 모든 정보를 중계하여 준다. 이때, TURN은 Peer 간에 발생하는 모든 미디어에 대한 미디어 프록시 서버 역할을 수행한다.
ICE는 STUN과 TURN 방식을 활용하여 검출된 여러 네트워크 경로 중 하나를 선택하여 Peer 간 연결을 수행한다.
그림입니다. 원본 그림의 이름: CLP00007a7c26e3.bmp 원본 그림의 크기: 가로 1920pixel, 세로 1080pixel
그림 19 NAT 환경에서의 STUN/TURN 구성
6.4.10 WebRTC를 이용한 보안 통신
그림입니다. 원본 그림의 이름: CLP000069604b1d.bmp 원본 그림의 크기: 가로 850pixel, 세로 518pixel
그림 20 브라우저간 키교환
WebRTC에서 사용되는 SRTP(Secure Real-time Transport Protocol)는 IETF RFC 3711 표준화를 기반으로 하며 RTP 데이터를 암호화하는 역할을 한다. RTP에서 사용하는 데이터인 미디어, 오디오, Sharing screen에 사용된다. WebRTC에서 DTLS (Datagram Transport Layer Security)는 IETF RFC 6347과 RFC 8261 표준화를 기반으로 하며 RTP를 제외한 나머지 데이터의 통신과정에서 사용한다.
7. 메시지 규격
7.1 메시지 표현방식
SIP 통신의 메시지 표현방식은 텍스트 기반의 프로토콜로 RFC2279에 따라 UTF-8 Character Set을 사용한다.
7.2 메시지 구성
SIP 메시지는 요청/응답 메시지 형태로 구성되며 메시지의 구조는 start-line, message-header, message-body로 구성된다.
이중 start-line는 요청/응답 메시지에 따라 달라진다.
SIP-message = Request | Response
Generic-message = start-line
* message-header
CRLF
[message-body]
start-line = Request-Line | Status-Line
메시지 15 – 메시지 구조
7.2.1 Message-Header
SIP Message-Header는 통신세션을 제어하기 위한 설정 값들이 표시되며 통신경로, 송수신자 정보 등으로 구성한다.
항 목
설 명
Record-Route
송신된 메시지가 경유하는 프록시 서버의 URI를 기록함
Via
Request Response가 전달될 경로를 포함하며, 트랜잭션의 매칭에도 사용됨
From
발신 단말의 URI 정보
To
수신 단말의 URI 정보
Contact
요청 메시지를 보내는 자신의 주소정보
Call-ID
SIP 호 식별자
CSeq
동일 Call-ID를 이용한 Request 간의 순서를 명확하게 하거나 Request와 Response의 대응을 위해서 이용
User-Agent
전송장비의 모델명, 제조사, 펌웨어 버전정보 등 각종 정보
Max-Forwards
목적지 까지 가는데 transit 할 수 있는 최대 hop 수
Allow
SIP메시지를 보내는 발신 단말이 수신 가능한 메소드의 리스트를 지정한다.
Content-Type
메시지의 BODY의 포맷을 명시
표 3 – SIP 메시지 헤더 항목
7.2.2 Message-Body
미디어 세션 연결을 위하여 협상에 필요한 정보를 RFC 4566에서 정의한 SDP(Session Description Protocol)를 이용하여 Message-Body에 포함된다.
SDP는 미디어 세션을 제어하기 위해 SIP에 의해 사용되는 텍스트 기반 프로토콜로 미디어 정보, 전송 어드레스, 파라미터 정보를 포함한다.
항 목
설 명
v
세션 기술 프로토콜의 버전을 제공한다.
o
발신자의 이름, 세션 식별자, 세션의 버전 번호, 네트워크 타입, 어드레스 타입 및 송신 장치의 IP 주소가 식별된다.
s
Session name
c
Connection Data로 Network Type, Address-Type, Connection-address 표기
t
세션의 시작 및 정지 시간. 짧은 시간제한과 세션 시작이 0의 시간을 중지합니다.
m
미디어에 의해 사용되는 프로토콜, 및 미디어 포맷에 대한 설명을 포함하여 미디어에 대한 세부 사항을 포함하는 하나 이상의 라인으로 이루어지는 미디어 정보로 하나의 세션에 서 여러 유형의 미디어를 관리하는 경우 여러 미디어 라인이 필요하다.
a
미디어 속성 및 방향 정의
표 4 – SDP에 포함하는 미디어 세션 연결에 필요한 항목
7.3 요청 메시지
요청 메시지는 Method Name, Request URI, Protocol 버전이 포함되어 있는 Request-Line을 첫줄에 명시한다.
예: Request-Line = Method SP Request-URI SP SIP-Version CRLF
7.3.1 Method
요청 메시지는 기본적으로 REGISTER, INVITE, ACK, CANCEL, BYE, OPTIONS 등 6개로 필수적으로 구성되어져야 한다.
메시지 이름
설 명
REGISTER
SIP 단말 등록에 필요한 정보를 포함하여 서버로 전송
INVITE
호출 대상 정보를 서버를 경유하여 상대 단말에 전송
ACK
호출요청에 대해 응답을 확인하였다는 정보를 상대 단말에 전송
CANCEL
상대 단말을 호출하고 연결 전에 취소
BYE
호 연결을 종료하기 위해 서버를 경유하여 상대 단말에 전송
OPTIONS
서버의 환경 및 추가 사항을 파악하기 위해 사용
표 5 – 요청 메시지의 종류
7.3.2 Request-URI
Request URI는 SIP 또는 SIPS URI와 형태가 같으며, 사용자 또는 서버에게 요청의 대상을 전달하기 위해 사용한다.
예: sips:user@host:port;uri-parameters?headers
7.3.3 SIP 버전
요청과 응답 메시지는 모두 SIP 버전 정보를 포함하여야 한다. SIP 메시지를 전송하는 단말은 필수적으로 SIP 버전을 메시지에 포함시켜야 하며, 이때 버전 정보를 대소문자 등에 영향을 받지 않는다.
7.3.4 응답 메시지 구성
응답 메시지는 Protocol, 상태, 응답구문이 포함되어 있는 Request-Line을 첫줄에 명시한다.
예 : Status-Line = SIP-Version, 응답메시지 상태, CRLF
응답 메시지는 요청 메시지와 다르게 첫 줄에 3자리 숫자로 구성된 상태 코드와 프로토콜 버전이 포함된다. 상태코드는 서버 또는 단말의 인식을 위한 3자리 정수로 구성되며, 사용자가 상태 파악을 하기 위한 코드에 대한 정보가 포함된다.
분류
상태코드
코드설명
1xx
정보용
응답
100
호출 대상 장비로 연결을 시도 중임
180
상대 단말에서 신호가 울리는 중
183
세션이 진행 중임
2xx
성공응답
200
세션 요청이 성공적으로 이루어졌음
4xx 요청실패
400
메시지 오류
401
인증 요구 또는 부적절한 인증정보가 포함
403
허용되지 않은 메소드
404
사용자를 찾을 수 없음
408
요청시간 초과
422
Session-Expires 값이 최소값 보다 작음
423
Contact Address의 등록기한이 너무 짧은 경우
481
세션이 중단됨
483
SIP 헤더 내 Max-Forword가 “0”이 됨
486
수신자가 통화중임
487
호 연결 종료 및 취소에 의해 호 연결 요청이 종료됨
5xx 서버오류
5xx
서버 오류로 처리 불가
6xx 전체실패
6xx
처리 불가
표 6 – 메시지 세부 상태코드
부 칙
이 고시는 고시한 날부터 시행한다.