7 장 목차
DESCRIPTION
7.1 멀티미디어 네트워킹 응용 7.2 스트리밍 저장 오디오 및 비디오 7.3 최선형 서비스를 최대로 활용하기 7.4 실시간 대화형 응용 프로토콜. 7.5 다양한 서비스 클래스 제공 7.6 QoS 보장. 7 장 목차. RTP 는 audio 와 video 데이터를 전송하는 패킷의 구조를 정의한다 . RFC 3550 RTP 패킷에 포함된 정보 페이로드 유형을 명시 패킷의 일련 번호 타임스탬프 (time stamp). RTP 는 종단 시스템에서 동작 - PowerPoint PPT PresentationTRANSCRIPT
7-1
7 장 목차
7.1 멀티미디어 네트워킹 응용
7.2 스트리밍 저장 오디오 및 비디오
7.3 최선형 서비스를 최대로 활용하기
7.4 실시간 대화형 응용 프로토콜
7.5 다양한 서비스 클래스 제공
7.6 QoS 보장
7-2
Real-Time Protocol (RTP)
RTP 는 audio 와 video 데이터를 전송하는 패킷의 구조를 정의한다 .
RFC 3550 RTP 패킷에 포함된
정보
페이로드 유형을 명시
패킷의 일련 번호 타임스탬프 (time
stamp)
RTP 는 종단 시스템에서 동작
RTP 패킷은 UDP 데이터그램으로 캡슐화된다 .
상호연동 : 만약 두 인터넷 전화가 RTP 로 동작된다면 두 전화는 서로 통화가 가능해 진다 .
7-3
RTP 프로토콜 스택
RTP 라이브러리는 UDP 를 확장한 수송 계층의 인터페이스를 제공한다 .
• port 번호 , IP 주소• payload 유형 ID• 패킷 일련 번호• 타임스탬프
7-4
RTP 예 RTP 위에서 64 kbps
PCM 으로 인코딩된 voice 를 전송한다고 하자 .
응용 계층은 인코딩된 데이터를 voice chunk(패킷 ) 로 구성한다 . 매 20 msec 마다 160
byte 의 voice 패킷
Voice 패킷 + RTP 헤더 = RTP 패킷
RTP 패킷으로 UDP datagram 으로 캡슐화
RTP 헤더는 각 패킷 마다 인코딩 유형을 표시한다 . 송신자는 통화 중에
인코딩 방법을 변경할 수 있다 .
RTP 헤더는 또한 일련 번호와 타임스탬프를 포함한다 .
7-5
RTP 와 QoS
RTP 는 패킷이 시간 내에 도착할 수 있는 어떤 방법도 제공해 주지 않는다 .(QoS 를 위한 어떤 방법을 제공하지 않는다 .)
RTP 헤더 정보는 오직 종단 시스템 만이 볼 수 있다 .( 망 중간의 라우터는 상관하지 않는다 .)
7-6
RTP 헤더 (1)
페이로드 유형 (7 bits): 현재 패킷에서 사용된 인코딩 유형을 표시송신자는 통화 중 인코딩 방법을 변경하였으면 이 필드로 수신자에게 알려줌
•Payload type 0: PCM mu-law, 64 kbps•Payload type 3, GSM, 13 kbps•Payload type 7, LPC, 2.4 kbps•Payload type 26, Motion JPEG•Payload type 31. H.261•Payload type 33, MPEG2 video
일련 번호 (16 bits): RTP 패킷을 전송할 때 마다 하나씩 증가패킷 손실을 발견하거나 퍀시 손실을 복구할 때 사용
7-7
RTP 헤더 (2)
타임스탬프 (32 bytes long): RTP 패킷의 첫번째 바이트를 샘플링할 때의 시간 오디오의 경우 , 타임스탬프 clock 은 매 샘플링 기간마다 1
씩 증가한다 . ( 예 , 8KHz 샘플링 시계는 매 125 usecs 마다 증가 )
응용 계층에서 160 개의 인코딩 샘플을 발생시키면 매 패킷 마다 160 씩 증가 . 타임스탬프는 송신 소스가 비활성화될 때까지 계속 증가한다 .
SSRC (32 bits long): RTP 스트림의 소스 (source) 를 명시한다 . RTP 세션의 각 스트림은 별도의 SSRC 값을 갖는다 .
7-8
Real-Time Control Protocol (RTCP)
RTP 와 협력하여 동작 RTP 세션의 참여자는
주기적으로 RTCP 제어 패킷을 모든 다른 참여자에게 전송한다 .
RTCP 패킷은 송수신 상태를 보고한다 . 응용 계층에 유용한 통계
정보를 보고 : • 송신한 패킷의 수• 손실된 패킷의 수• 패킷의 도착 시간의 변이 등등
이 정보를 사용하여 성능을 향상시키는데 사용할 수 있다 . 송신자는 피드백 정보에
의거하여 전송율을 조정할 수 있다 .
7-9
RTCP
각 RTP 세션마다 : 보통 하나의 멀티캐스트 주소를 갖음 모든 RTP /RTCP 패킷은 동일 멀티캐스트 주소를 사용
RTP, RTCP 패킷을 다른 포트 번호를 사용하여 구분된다 .
트래픽을 줄이기 위해 , 각 참여자는 상황에 따라서 RTCP 트래픽을 줄일 수 있다 .
7-10
RTCP 패킷들
수신 보고 패킷 : 손실된 패킷의 비율 ,
마지막 패킷의 일련 번호 , 평균 도착 시간 변이
송신 보고 패킷 : RTP 스트림의 SSRC,
현재 시간 , 송신한 패킷의 수 , 송신한 바이트의 수
소스 명시 패킷 : 송신자의 e-mail 주
소 , 송신자 이름 , RTP 스트림과 연관된 SSRC
SSRC 와 사용자 /호스트 이름 사이의 매핑
7-11
스트림들의 동기화
RTCP 는 RTP 세션 내에서 다른 미디어 스트림을 동기화시킬 수 있다 .
화상 회의에서 각 참여자는 video RTP 스트림과 audio RTP 스트림을 전송한다 .
Video, audio RTP 패킷의 타임스탬프는 동일한 샘플링 시계에 의해 만들어짐
각 RTCP 송신 보고 패킷은 RTP 패킷의 타임스탬프 패킷이 생성될 때의 시간
수신자는 audio 와 video를 재생할 때 동기화 시킴
7-12
RTCP 대역 조절
RTCP 트래픽은 세션 대역의 5% 이내로 제한
예 송신자가 2 Mbps 의 video
를 전송한다면 RTCP 트래픽은 100Kbps 로 제한하도록 시도한다 .
RTCP 트래픽은 수신자는 75% 를 송신자는 25% 를 사용한다 .
75 kbps 는 수신자들이 동일하게 분배하여 사용 : R 수신자라면 , 각 수신자는
75/R kbps 로 RTCP 트래픽을 전송
송신자는 25 kbps 속도로 RTCP 트래픽을 전송
참여자는 평균 RTCP 패킷의 크기를 할당된 전송율로 나누어서 얼마나 자주 RTCP 패킷을 전송할 지 결정한다 .
7-13
SIP: Session Initiation Protocol [RFC 3261]
SIP 의 장기적인 목표 :
모든 전화 통화의 호 (call), 화상 회의의 호는 인터넷을 통해 발생한다 .
사람들은 전화 번화가 아니라 이름 혹은 이메일 주소을 자신의 식별자 (identifier) 로 사용한다 .
상대방이 어디에 있든지 , 어떤 IP 주소를 사용하든지 상대방에 접속할 수 있다 .
7-14
SIP 서비스
호 (call) 를 설정할 때 , SIP 이 제공하는 것들 요청자는 자신이 호
(call) 를 설정하기 원한다는 것을 상대방이 알도록 한다 .
그래서 송신자와 수신자가 미디어 형태 , 코딩 방식에 대해 합의를 하도록 한다 .
호를 해제한다 .
상대방의 현재 IP 주소를 결정 상대방 식별 ID 를 현재
IP 주소로 매핑 호 관리 :
통화 중에 새로운 미디어 스트림을 추가
통화 중에 코딩 방식을 변경
또 다른 통화자를 초대 호를 이전 (transfer),
일시 정지
7-15
IP 주소를 이미 알고 있을 때 호 설정
Alice 의 SIP invite message: port 번호 , IP 주소 , 원하는 코딩 방식(PCM ulaw)
Bob 의 200 OK message: port 번호 , IP 주소 , 원하는 코딩 방식 (GSM)
SIP 메시지는 TCP 혹은 UDP 로 전송 ; 여기서는 RTP/UDP 로 전송 디폴트 SIP port 번호는 5060.
time time
Bob'stermina l rings
A lice
167.180.112.24
Bob
193.64.210.89
port 38060
Law audio
G SMport 48753
7-16
호 설정 codec 협상 :
Bob 은 PCM ulaw encoder 가 없다고 하자 .
Bob 은 606 Not Acceptable Reply 로 응답하면서 자신의 encoder 를 알려줌
Alice 는 그 중에서 encoder 를 선택하여 새로운 INVITE 메시지를 보낸다 .
호 거부 Bob 은 호 요청을
거부하면서 다음과 같은 이유를 알려준다 : “busy,” “gone,” “payment required,” “forbidden”
미디어는 RTP 혹은 다른 프로토콜을 사용하여 전달된다 .
7-17
SIP 메시지 예
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
Content-Type: application/sdp
Content-Length: 885
c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0
Notes: HTTP 메시지와 동일한 문법 (syntax) sdp = session description protocol Call-ID 는 호를 식별하는 유일한 값
Bob 의 IP 주소를 모른다면 중간에 SIP 서버가 필요하다 .
SIP 포트 번호 5060을 사용하여 SIP 메시지를 보내고 받는다 .
7-18
이름 변환과 상대방 위치 찾기
송신자는 상대방의 이름과 e-mail 주소 만을 갖고 있다면 ,
상대방의 현재 IP 주소를 알아야 한다 : 상대방은 이동 중 DHCP 프로토콜 사용 상대방은 여러 다른 IP
기기를 사용할 수 있다 .(PC, PDA, 차량 부착 기기 )
응답은 요청자가 누구인가에 따라 달라질 수 있다 : time of day (집 , 직장 ) 요청자 ( 친구 , 직장 상사 ) 수신자의 현재 상태 (
요청을 받았을 때 이미 음성 메일을 사용 중 )
SIP 서버 : SIP 등록자 서버 SIP 프록시 서버
7-19
SIP 등록자 (Registrar)
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 193.64.210.89
From: sip:[email protected]
To: sip:[email protected]
Expires: 3600
Bob 이 SIP client 를 시작하면 , client 는 SIP REGISTER 메시지를 to Bob 의 등록자 서버에 보낸다 .
(Instant Messaging 에서와 비슷한 기능 )
등록 메시지 :
7-20
SIP 프록시 (Proxy)
Alice 는 invite 메시지를 자신의 프록시 서버에 보낸다 . 상대방 (Bob) 의 주소를 포함 sip:[email protected]
Proxy 는 경로를 찾아서 수신자에게 SIP 메시지를 전달한다 . 여러 proxy 를 거쳐서 도달할 수 있다 .
수신자는 동일한 경로의 proxy 들을 거쳐서 응답 메시지를 전달한다 .
Proxy 는 SIP 응답 메시지를 Alice 에게 전달한다 . 응답 메시지는 Bob 의 IP 주소를 포함하고 있다 .
Proxy 는 local DNS 서버와 비슷한 기능을 수행한다 .
7-21
예
(6-8) SIP response 를 전달한다 . (9) 미디어는 두 client 사이에서 직접 전달된다 .
또한 이 그림에서는 나타나 있지 않지만 SIP ACK 메시지가 전달된다 .
SIP client217.123.56.89
SIP client197.87.54.21
SIP proxyum ass.edu
SIP registrarupenn.edu
SIPregistrareurecom .fr
1
2
34
5
6
7
8
9
송신자 : [email protected] 수신자 : [email protected]
(1) Jim 은 INVITE 메시지를 umass SIP proxy 에 보낸다 .(2) umass 서버는 이 메시지를 upenn SIP registrar 서버에 전달한다 .(3) Upen 서버는 이 메시지를 반송하면서 [email protected]로 요청하도록 지시한다 .(4) Umass proxy 는 INVITE 메시지를 eurecom registrar에 보낸다 .(5) Eurecom registrar 은 INVITE 메시지를 keith 의 SIP client 가 동작하고 있는 197.87.54.21 로 전달한다 .
7-22
H.323 과 비교
H.323 는 실시간 대화형 통신을 위한 또 다른 신호 프로토콜 (signaling protocol) 이다 .
H.323 은 그 자체가화상 회의를 필요한 모든 것을 규정한 완전한 통합 프로토콜 이다 .
신호 , 등록 , 수락 제어 , 전송 , 코덱 등
SIP 은 프로토콜의 한 요소 만을 규정 .
RTP 와 같이 동작하지만 반드시 RTP 를 사용해야 하는 것은 아니다 .
다른 프로토콜과 같이 결합해서 사용할 수 있다 .
H.323 은 ITU 에서 만듬 (telephony).
SIP 은 IETF 에서 만듬 : 많은 개념은 HTTP 에 기반을 두고 있다 . SIP 은 Web
지향적이고 , H.323 은 전화 지향적이다 .
SIP 은 KISS 원칙을 사용했다 .
Keep it simple stupid.
7-23
7 장 목차
7.1 멀티미디어 네트워킹 응용
7.2 스트리밍 저장 오디오 및 비디오
7.3 최선형 서비스를 최대로 활용하기
7.4 실시간 대화형 응용 프로토콜
7.5 다양한 서비스 클래스 제공
7.6 QoS 보장
7-24
인터넷에서 멀티미디어 서비스를 제공하기 위한 접근 방법
통합 서비스 접근 : 각 응용 서비스에 필요한
대역을 보장해 준다 . 모든 노드들에 근본적인
변화가 요구된다 . Integrated Services
호 수락 제어 (admission control)
RSVP( 신호 프로토콜
자유 방임 (Laissez-faire) 현재 그대로 사용 필요하면 대역을 더 제공 CDN, 응용 계층 멀티캐스트
차별 서비스 접근 : 약간의 변화 필요 Differentiated services
What’s your opinion?
7: Multimedia Networking 7-25
다양한 서비스 클래스의 구분 지금까지 ( 그리고 현재 인터넷에서는 ) 모든 트래픽들은
동일하게 처리되었다 . 즉 서비스 구별이라는 개념이 존재하지 않는다 .
하지만 네트워크에서 서비스 보장을 위해서는 서비스 간에 구별을 할 필요가 있다 . 트래픽을 서비스에 따라서 차별화 : 서비스 클래스
지정
0111
어떤 트래픽 그룹을 하나의 클래스로 정할 것인가 ?
서비스 클래스는 어떻게 결정할 것인가 ?
구별된 클래스는 어떻게 구분해서 처리할 것인가 ?
7: Multimedia Networking 7-26
다양한 서비스 클래스 : 시나리오
R1 R2H1
H2
H3
H41.5 Mbps linkR1 output
interface queue
7-27
시나리오 : FTP 와 audio(1) 예 : IP 전화 (1Mbps) 와 FTP 트래픽 (0.1Mbps) 이 1.5 Mbps
링크를 공유한다고 하자 . FTP 패킷들이 많이 도착할 경우 (burst) 라우터의 버퍼에서 대기해야
하고 , audio 패킷의 손실이 발생할 수 있다 . 따라서 라우터에서 패킷을 처리할 때 FTP 패킷 보다 audio 패킷을
우선적으로 처리할 수 있도록 하고 싶다 .
라우터가 두 트래픽을 구별하기 위해서 패킷에 표시를 할 필요가 있다 . 두 트래픽은 다른 서비스 클래스를 가지며 라우터는 이에 따라 패킷을 처리하는 순서를 결정한다 .
원칙 1
R1 R2
7-28
시나리오 : FTP 와 audio(2)
만약 audio 트래픽이 1Mbps 를 초과할 경우 어떤 일이 발생하겠는가 ? 감시 : 소스는 약속한 대역폭을 지키도록 한다 .
한 클래스는 약속을 이행하지 않는 다른 클래스로부터 보호를 받아야 한다 .
원칙 2
R1 R2
1.5 Mbps link
1 Mbps phone
packet marking and policing
7-29
무엇이 필요한가 ?
라우터에서의 패킷 스케쥴링 서비스 클래스에 따라 패킷 처리 속도가 달라짐
서비스 클래스는 몇 종류로 구분할 것인가? 3가지 , 4가지 , 100가지?
서비스 클래스를 구분하는 기준은? 요금?
서비스 클래스에 따라서 패킷의 표시 (marking)는 어떻게 할 것인가? 트래픽이 원래의 약속을 지키는지 감시(policing)는 어떻게 할 것인가? 패킷의 표시와 감시는 누가 할 것인가?
망 경계 라우터?
7-30
7 장 목차
7.1 멀티미디어 네트워킹 응용
7.2 스트리밍 저장 오디오 및 비디오
7.3 최선형 서비스를 최대로 활용하기
7.4 실시간 대화형 응용 프로토콜
7.5 다양한 서비스 클래스 제공
7.6 QoS 보장
7-31
QOS 보장
서비스가 필요로 하는 대역을 보장할 수 없으면 QoS를 보장할 수 없다 .
호 수락 (Call Admission): - 서비스는 필요 대역을 사전에 요구 - 망이 이 서비스의 요구를 받아들일 수 있으면 수락하고 QoS 를 보장한다 . 아니면 , 거부
Principle 4
R1R2
1.5 Mbps link
1 Mbps phone
1 Mbps phone
7-32
QoS 보장 시나리오
대역 예약 (Resource reservation) 호 설정 , 자원 예약 (RSVP) 트래픽과 요구하는 대역을 명시 서비스 당 수락 제어
QoS-sensitive scheduling
request/reply